Dev Diary #19: Blowin' stuff up in 2016!

We've achieved a significant milestone: every weapon and special ability in the game is now implemented! The last one, which I teased in last month's dev diary, is what I like to call COMET BUDDY:

This little guy bounces between targets in a chaotic dance of seek-and-destroy. It's got a time limit, but it gains a tiny bit more time for each kill, which positions it for strong crowd control (with long, satisfying combos!) while keeping its power in check against bosses.

We also updated that nasty ol' placeholder art for the plasma cannon (left) and star mines (right):

We added a new kind of enemy attack:

This missile homes in on the warning reticle position and detonates upon arrival (no collision necessary), causing damage in an area-of-effect around that spot. The warning reticle indicates the area-of-effect – the faint outer circle – so you know how far away you need to get in order to reach safety. These get really interesting when there are multiple enemies involved!

I wrote a new track for the fifth-and-final stage (which we haven't shown yet):

This is still a work-in-progress. I like the intense feel at the start, and I'm really happy with the tone shift that happens about a minute in. But I'm kinda iffy on the high-energy main part, from about 1:30 on. Coming into it feels nice but the feel of that section is probably too dance-y right now, and since this track is scoring the ULTIMATE FINAL BATTLE I think it probably needs to feel more cinematic there.

I finally bit the bullet and implemented proper load screens, complete with some ambient animation on each planet and a nice animated loading progress spinner:

(We'll actually have five stages, not four. We just haven't made the last one yet.)

It's not that we have significant loading times by any means – we're averaging just a couple seconds per level right now – but there were a few considerations:

  • Once the level assets are loaded, we do a "preallocation" phase which pre-instantiates a bunch of copies of all the things that will appear in the stage (bullets, enemies, pickups, etc.) and holds them disabled in an object pool. This causes visual hitching in the background animation during the first few seconds of the stage. By moving this phase into a load screen, we can present the actual beginning of the stage much more smoothly.
  • All of our (many, large) texture atlases are currently stored uncompressed on disk. That reduces load times but greatly inflates the build size. I'm looking into writing a build step to convert those atlases to PNGs and apply pngcrush (or some reasonable equivalent) to get the install size down to something sensible (it's about a gigabyte right now). That will increase load times by a few seconds since the atlases will now need to be decompressed in memory, and a proper loading screen will help smooth out that experience.

(Load screens will also be a nice opportunity to inject a little bit of story text. Not that this game has that much story – it's a shoot-em-up, after all – but it is quite nice to have just a little bit of context going into each stage.)