Space shooter!


#1

I’m working on a straight forward space shooter a la Tyrian.
"A shmup without the stress of so many bullets"™.
For Android initially. Sprites are from Dan Cook, Tyrian game.

Super early gameplay recorded on Samsung Galaxy S7:

Highlights:

  • Particles. I like particles. The engine sprays smoke and fire based on your speed.
  • More particles when the player dies!
  • Parallax background. Simple yet effective.

What more is needed to be done:

  • Figure out a smart way to handle different screen sizes. Right now it’s 720x1280, but some have wider/narrower screens and I’m not sure how to do that yet.
  • Gui! Will be tricky since I’m neither gfx artist nor designer, so programmer art will be mixed into it.
  • Gameplay! Right now there is none basically. So:
    – Thought out progress system.
    – Enemy wave system.
    – Level handling.
    – Use for the pickup cash, maybe weapons upgrades.
    – Many enemy types that fire stuff at you.
    – Hazards, spikes/structures flying towards you for you to dodge.
    – Bosses - even nastier enemies!
  • Sounds/music
  • Menu system with janitorial stuff like sound/music on/off, maybe clear your progress-button or something.
  • Ad’s. Interstitial and video ads at the right moments. Realistically I’m not expecting more than a couple of downloads, looking at the competition in Google Play Store. But I can still use it as a motivator and trick myself into it believeing it’ll pay itself back eventually :smiley: . Also, promote the game itself.
  • A name/splash screen for the game.

What I’d like to do as well if there’s time:

  • Shaders! I really want a crt/scanline type of shader going on but that stuff is still voodoo to me and I’m a bit lost in the render script handling. I found one on github but that didn’t work/compile to Android sadly.
  • More of a narrative.
  • Star system map to show level progress.
  • Different environments - not only fight in space, maybe on different planets as well. Tyrian tilesets has tons of ground level stuff I could possibly use as a new looping background.
  • Some sort of homing missiles for either the player or the enemies.

Wish the day had 48 hours instead! I have this idea for iterative development. Make the game read the enemy waves/events for a level from a json file served from a web server. That way I could have a gui on my server for designing this json data and design new levels and try out while commuting to/from work.


#2

Shiny! Looking forward to seeing more.

Figure out a smart way to handle different screen sizes.

Use rendercam!

so programmer art will be mixed into it

Don’t let that stop you. If you have a real game at the end you can consider investing in paying for some better assets. Most important thing is doing the follow through to finishing the game.

Render target based shaders are not so hard but also something you can do last.

Check out the games at http://mking.com/ would be good inspiration for your style of game.


#3

I actually am using rendercam. And it helped me set up the 4x scaling quite simply. I also managed to make a copy of that renderscript to adjust predicates; adding a “tiletop” layer that goes above the particle predicate so I can control the experienced z-value of particles.

What I don’t have figured out (and the consequences thereof) is allow the game to go fullscreen in both 16:9 and 16:10 for example. And deciding which part that should always be visible, and which to cut in what resolution etc. Needs some thought work on my part (which is tricky in the late hours with baby screaming :smiley: )


#4

Done a bit of work on the background parallax thingie.
Basically it is just three layers: background stars, nebula clouds and foreground stars. They move in different speed in that order. Background slowest, foreground fastest. Nebula in between.

The nebula clouds however are actually two layers which shift/swap their opacity presence over time. You can see in this video how it shifts eventually from the blue-ish nebula to more of a green/yellowish kind.

(youtube sadly mushes up the quality pretty bad, for slightly better quality I have an mp4 of the same clip: http://waikiki.macklin.se/livefolder/defolddevlog3.mp4)
It’s a really simple technique that gives a really nice effect!

Also I’ve added a cooler death explosion for the player, with a camera zoom in and time slowdown.
Rendercam made it easy to set the scale for a zoom in, but it’ll be trickier to do a gradual zoom in over time. But probably doable.

Also, at the start you might catch the built in coin magnet!


#5

Wow, the explosion for the player is really neat!

Thanks for sharing the dev diary. I have been working on something similar on and off for a while and don’t get much progress due to various distractions. Seeing your project really motivates me a lot!


#6

Remember that you can go.animate() script properties defined using go.property(). You should be able to do something like this:

go.property("zoom", 1)

function update(self, dt)
	rendercam.zoom(self.zoom)
end

function on_message(self, message_id, message, sender)
	if message_id == hash("zoom_to") then
		go.animate("#", "zoom", go.PLAYBACK_ONCE_FORWARD, message.to, go.EASING_LINEAR, 2)
	end
end

#7

From my testing it seems that rendercam.zoom(x) continuously zooms on each update pass into infinity, the value passed in.

Not like “zoom up until x and stay there even if called again with that same value”. So a zoom(1) for example, in update, would zoom out forever. It then becomes trickier to interpolate and do math stuff to get a nice easing.
Or I could do an animation with go.PLAYBACK_ONCE_PINGPONG from 0 to -1 to 0 to zoom in a bit, but then it’d be a lot of trial and error to figure out the exact second length for that animation to end up at my desired zoom level.

I wish the zoom worked more like a “zoom to this value” than a continuous zoom.
Or a new function, zoomTo :slight_smile:

Edit: aaaaand that’s what I have set_ortho_scale for, which I was already using in my player explosion. Once again, I have scientifically proven that working late lowers perceptiveness :man_scientist:


#8

. . . Scientifically proving that testing on tired users can result in valuable feedback? :smiley: I suppose “set_ortho_scale” is probably not what people will think to look for (unless they have experience writing camera code). I will see about making this stuff a bit more intuitive. It would be pretty convenient if you could just animate zoom directly.


#9

Still hackin’ away at this game whenever I find the hours…

New gameplay clip!

What’s new here?

  • Homing missiles! (did you spot the missile collision at 0:34?)
  • Annoying enemies!
  • Smart bomb - when all else fails!

Probably more stuff I don’t remember changing. Still, lots to do, trying to get my focus on what really matters - the actual gameplay and feel.
Need variety in enemies and hazards to make it interesting and challenging.


#10

Looks great! I like how you can deflect the homing missile with your bullets!


#11

Things I’ve done lately in the game:

  • More enemy types. I have 7 different “fighter” enemy types (the ones you see in the videos). Will add bosses and more intermediate and different types of enemies for more variation.
  • Weapon progression plan, and implemented the three main weapons and their 10 levels. Takes some time to plan upgrade costs and the damage/rate of fire increases they provide, but a simple spreadsheet certainly helps that kind of planning.

Currently struggling with GUI, coming up with a design for it.


#12

Working on the GUI, here’s a rough design that might be final in the end.

  • Done a lot of work on handling screen sizes/resizing and translating the movement that differs on depending sizes.
  • Tweaked input handling, as double tapping the screen sends a bomb but I had some accidental double taps (had to make sure to consume the input to avoid that).
  • UI took a lot of work as well to integrate into the game, but what you see in the screenshot is based on real game data (except dummy no. 9999 for money) - if I pick up coin, it counts up to new value.
  • Pausing works! Setting timescale, bringing up other collection via proxy etc, lots going on there.

Revised my to-do list:

Gameplay

  • Progression system for levels
  • Progression for upgrades/weapons (plans are half laid out here)
  • More enemy types and bosses. This is probably the most important part gameplay-wise, and I need to find a good balance/challenge, interesting shmup-style bullet patterns etc.
  • Hazards/environment stuff. Asteroids!
  • Achievements

Janitorial

  • Sound/music on/off handling
  • Sound system in general (hoping for good news on FMOD extension + Android later on). My artistic vision here kind of needs fine grained control over the audio, like pausing/resuming etc.
  • Menu systems for start menu, paused state, options, buying upgrades
  • Ads integration
  • Skinning for Android
  • Analytics
  • Rate my game function
  • Web tool to generate levels/waves of enemies for faster iteration/testing
  • Investigate google play services integration, for achievements tied to that, maybe?

Theme/setting

  • The actual sounds and music
  • Start screen
  • Oh… how about a name for the game
  • Narrative, voice over, story (yes this is possibly a dramatic shmup)
  • Different backgrounds for different levels
  • Maybe like an overworld map, but that’s more like a nice-to-have since god knows how much time that’ll take

Shaders

  • CRT/scanline type of shader. Done some testing before, seems to either steal performance or not work on Android, so it’s a big maybe, but would be nice to have.
  • Grading. My game looks so dull, and I’m thinking of ‘cheating’ by following the grading shader tutorial and finding a nice color/contrast that way.
  • Displacement. Now this would probably be super tricky (at least for me). I would love to have a way to simulate heat waves by displacing pixels. For example, behind the ship’s engine. Any tips?

And probably 20 things more along the way I haven’t though about.


#13

Sunday was fairly productive as I got 9 new enemy types done, each with different behaviour.
One of them you’ll see in this new video clip! But that’s not all…

(watch with audio!)

Thanks to all the help from @dapetcu21 I’ve managed to get FMOD up and running, and damn… I think I’m in love! Maybe a little bit with dapetcu but mainly FMOD. It’s amazing how easy you can do advanced reactionary audio.

What you see in the clip is just a placeholder M-16 autofire sound with a release tail, but my time scale slowdown in game connects directly to FMOD and syncs the pitch with the time scale. So cool!

dapetcu, I feel bad for asking even more, but if you get the Android version running I for one will be a happy camper :slight_smile:


#14

Lately it’s been hard finding time for working on the game, if I’m lucky I get 1 hour of seemingly drunken (out of tiredness) coding per evening/night, but having to prioritize family and work makes it tricky.

But still work is being done, and there’s no stopping in sight!

What’s been done lately?

  • Implemented color grading from the shader tutorial https://www.defold.com/tutorials/grading/ - was slightly tricky first with rendercam to get it working but I found replies regarding that mix in the rendercam thread which solved it. I haven’t actually chosen any specific color grading, it still renders the original colors, but it’s all prepared which is nice.
  • Improved enemy explosion handling. I have a single particle system that does the explosions. When I use my smart bomb, many enemies die at the same time, so I have to queue up the explosion positions and wait for EMITTER_STATE_POSTSPAWN before triggering the next explosion. When having lots of small enemies on the screen, it looks funky how the sequentially explode taking a few seconds in total. Simple solution… add a couple more particle components and have the round robin the queue :slight_smile:
  • More enemy types done! Small simple enemies but they’ll hopefully add some flavor to the gameplay.
  • Improved enemy bullet spawning which now is a lot easier to give direction/rotation etc. Will be needed for the boss enemies to spawn crazy amount of bullets in nice patterns.
  • @sicher and @britzl nudged me to implement enemy drifting/bobbing, as to not stay totally still position-wise. Not all my enemies are stationary, but those that are, are very still. Easiest solution was to implement this in my individual enemy scripts. Example:

enemy.script:

function init(self)
	self.parent_drifter = factory.create("/spawner#enemydrifter", vmath.vector3(0,0,0))
	msg.post(".", "set_parent", {parent_id = self.parent_drifter})
	-- more code..
end

function final(self)
	go.delete(self.parent_drifter)
end

“enemydrifter” is a simple empty game object which has the following script:

local timer = require "system/timer"
local MAX_MOVE_LENGTH = 8
local MIN_ANIM_TIME = 0.2
local MAX_ANIM_TIME = 6

local function move_randomly_x(self)
	local anim_time = math.random(MIN_ANIM_TIME, MAX_ANIM_TIME)
	go.animate(".", "position.x", go.PLAYBACK_ONCE_PINGPONG, math.random(-MAX_MOVE_LENGTH,MAX_MOVE_LENGTH),	go.EASING_INOUTSINE, anim_time)
	self.repeater_x = timer.once(move_randomly_x, anim_time, self)
end

local function move_randomly_y(self)
	local anim_time = math.random(MIN_ANIM_TIME, MAX_ANIM_TIME)
	go.animate(".", "position.y", go.PLAYBACK_ONCE_PINGPONG, math.random(-MAX_MOVE_LENGTH,MAX_MOVE_LENGTH),	go.EASING_INOUTSINE, anim_time)
	self.repeater_y = timer.once(move_randomly_y, anim_time, self)
end

function init(self)
	move_randomly_x(self)
	move_randomly_y(self)
end

function final(self)
	timer.cancel(self.repeater_x)
	timer.cancel(self.repeater_y)
end

This is how it looks in game:

This solution is nice and simple, it does however not let me rotate the enemies. Because x/y is at 0/0, so rotating would instead move the ship as it’s far “outside in the circle”. But several enemies handle their own rotation within themselves so it’s not a big need.


I’ve been toying with the idea of implementing a primary weapon that doesn’t fire but provides a bullet shield for a short period of time. I’d like to slow down and deflect enemy bullets but I think it’ll be hard to do something cooler than just flipping their velocity to go the other way. But that might be interesting gameplay-wise - having to switch between shooting and shielding at hectic times.

However the main work being done is actually on my web based level editor! Nothing to show yet, but once it’s up and running I’ll put up a video of the workflow in action, might be fun to see.


#15

Alright so here’s a simple workflow example for how my level editor will help me test out level concepts during my daily commute!

Been hard to find time to work on this lately but I’m finally at a stage where it’s something usable. Still needs improvements, have to implement waypoint support for example. But it’s all minor details so it’s close to usable.

Web based editor > level/wave def data into MongoDB > available via JSON > loaded by game. Quite simple but effective stuff. Let me know if you have any questions about the video!


#16

Taking a break from all the “janitorial” stuff of the game I had to try my hands on making a boss. Here’s a preview of the boss “Emerald” fight!


#17

Still alive!

Want to spend your hard earned space bucks on something?
(work in progress)