I’ve implemented a navigation stack for screens in the game.

It used to be that when I would press “Play” in the main menu, the active screen would be changed to the episode selection screen. After pressing “back” there, it would say “open main menu” to return. All screen transitions were hardcoded in both ways like that.

Now when I press “Play”, it pushes the next screen onto the navigation stack. The “Back” button on the next screen doesn’t need to know where to go back to. It just tells the navigation controller to “pop” from the stack. The connection is now only one way and that makes it much easier to add new screens or change the order they are presented.

There are a few special cases, such as cutscenes, which effectively disappear once they are done. Other than that, the system is really simple and it only took an hour or so to implement, including the debug window shown above.

I did some more loading optimizations.

Last time I managed to make nice improvements by using multiple threads. As I’ve been adding more and more assets, the load time has crept up again since then. 

This time I did two things.

Instead of decoding all PNGs and cropping them on each start, I do it once and write the result to disk as cache. Next time I just compare timestamps and load the processed image directly. This is much, much faster. The final release will have only the processed images in a PAK file.

Second, I profiled the startup sequence and found that a lot of time was spent building fonts. In particular, it was the Material Icons font, which isn’t even used when the game is run normally – it’s only for editor icons! I wanted to keep dynamic loading for the other fonts so I just replaced the few icons I actually needed with prerendered bitmaps and got rid of the icon font.

Loading times are really quick again which makes iteration much more pleasant.

New graphics for a static enemy unit that’s actually been in the game for a while.
Do not touch. It gets angry!

The sentry turret is a big chunk of solid cold steel. When it smells danger, it gets mad. We don’t know how it works. The aliens probably don’t know it either. They just place these things around their camp site to keep them safe. Except they don’t, of course, because you brought grenades with you. Right? Right!?

Nobody likes seeing advertisements but making them can be fun. I really enjoyed creating these billboards for the game.

I have LOTS of ideas for advertisements. Hopefully I’ll find some time to do them.

For now I went with the classics.

Finishing the episode selection screen. Made a new Blender cover template, where each episode has its own scene and a single export command puts everything in the game.

Dots below the posters represent levels, filled ones are completed.

With the code & pipeline set up, I can focus on the content.

The missions in the first game were kind of all over the place. This time I’d like each episode to have a central theme with specific objectives to be completed over the course of 3-5 missions.

Q&A

• Is there going to be an stealth mission? Haha, no, sir. We’re going loud.
• Escort mission? Forget it.
• How about a mission with a farmer driving a tractor and you sitting in the trailer and shooting things? Why not.
• Do you need to get said farmer some beers? Yes!

Another small task off my plate: utility poles.

After putting together a quick moodboard, I started modeling the basic design and created a few different variations. I quite like the wood texturing on those.

However, when I saw them in the game I realized there was something missing. Wires! The poles look so lonely without them…

I could

• Pre-render sets of poles with wires included. This would reduce variety and the textures would be much larger.
• Pre-render wires separately, place them in the editor. Less memory usage but the size and direction is still fixed. Also extra precision work required for placement.
• Dynamic wires.

I decided to make the wires dynamic.

The first thing I needed was to define anchor points for each pole to attach the wires. I did this in Blender by adding Empty objects and giving them custom names.

The Blender export script then looks for those objects and writes their projected positions into a XML metadata file.

The game loads the metadata, the pole rendering code looks for the nearest neighbour poles, tries to match their anchor points and renders the wires.

All of this took about 3 hours, one of which I spent hunting down a problem with the anchor locations. It turned out I had changed their parent nodes in the Blender hierarchy and the parent inverse offset was wrong.

Another small task done: road signs. I went looking online for good textures or vector shapes of US road signs and found a great resource here. Picked a few that I liked and put them on 3D models. I had to do the rounded corners and UV maps for each sign separately to match the curves precisely. Not that anybody will ever notice at this scale. It’s just something that had to be done. Quite a tedious process, but good for podcast listening.

I made the first draft of an application icon for the game. A small but rewarding task which got me the following:

1. Some idea about the icon itself
2. Blender export pipeline
3. Script that scales the icon into all required dimensions & writes icon metadata

Now I can tweak the model & lighting (as one does), push a button and get a fresh set of app icons for each platform.

Icons for my other games:

The logo animation is a rather small feature and it’s been a while since I put it in, but I still love it when I see it.

It’s designed to resemble a gun being reloaded – a clip goes in and one bullet is loaded into the chamber. Based on AK47.

I’m glad I took the time to do it early on. Devastro 2 code is derived from Superforce so it was important to make a clear step away.

Adding more variety and detail to the saucers. Finally.

The original Devastro had only one type of saucer. Granted, it came in two colors, but it was the same shape. It was based on a photo of a physical object (something from the kitchen I think).

For Type Raiders, I made several different 2D silhouettes in Adobe Illustrator, processed the .ai files with Python to turn them into 3D meshes and then rendered those using a Java-based renderer called Sunflow. That worked quite well, thankfully.

Now I’m using Blender for everything. Making the silhouettes, generating 3D meshes and rendering. I use PBR materials to give the saucers a scratched, banged up look.

It’s work in progress but I’m already quite happy with these.

The new Blender “cloth brush” tool was handy for making realistic looking, sloppily rolled out rugs. They too, as the saucers, look a bit used. God knows what liquids have been spilled on them throughout the universe…

♫ Turn every invasion
into a special occasion…
…with rugs!

So let’s take one more look at the entire saucer lineup:

Oh look, a Fisher Price™ Saucer! Not 100% sure what to do with it yet but it’s going in. I can

1. treat it as a regular saucer
2. use it for the “final boss” battle
3. hide it somewhere as an easter egg