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.