Currently I’m working on the dialogs for the game. After watching some footage from Call of Duty: Black Ops Cold War, I knew I had to have subtitles just like that.

Here’s how it works: if a subtitle comes to an empty screen, it goes to the top line. The second one will go to the line below. Any following subtitles push the existing ones up; the top one disappears. After a short delay any subtitle simply fades out.

Getting this right was quite a challenge. It took me over 3 hours to figure out all the edge cases and make the animations robust enough to handle them. I had a lot of fun making this and I’m happy to have such a nice little system in the game.

Until recently, all the map tiles were created in Photoshop (or Pixelmator, or Affinity Photo, let’s not get into that now) and exported as flat images. Multiple combinations of ground × road × water × dirt all had to be done up front and each new one took additional memory and disk space.

I created a new meta tile system that improves this. Each tile now consists of multiple layers which are combined at runtime.

The first “naive” implementation simply draws all the layers on top of each other, which isn’t super efficient but I have an improved version in the works which uses multiple texturing units and a shader which combines them in a single pass.

Using the new tile editor I can create any combination of water / ground / road layers I need and the game and level editor will start using it immediately.

You can now pick up some special items and deliver them to designated locations to trigger an action.

There are currently two items you can pick up:

• 6-pack of Cola
• Fuel canister

Here’s how it works: walk over an item to pick it up. You will see it float above your head because obviously that’s how humans carry things. While carrying an item you cannot shoot but you can drop it anytime, do your business and pick it back up. The goal is to deliver it to an area which “accepts” it and triggers some action. It can spawn new objects, start dialogs or simply change the state to “mission completed”.

In Superforce, it was safe to assume that the game would run at a constant rate of  60 frames per second. This was thanks to

• predictable hardware and software environment
• fast, simple rendering and game update logic

The game logic could thus be directly locked to the framerate. This assumption is not valid for Devastro 2. I have no idea what machines it will run on. I don’t even know if VSYNC works on all of them.

There’s a great article called “Fix your timestep” which describes a good way to decouple game updates from rendering.

After making a few changes in my code, I have indeed fixed my timestep. Toggling VSYNC causes a big FPS increase and yet gameplay keeps running normally.

I was not able to fully implement the last step from the article, which is interpolation. It would require more substantial changes to the game and I just didn’t have time for that. I may or may not do that later as the… next step.

I might add interpolation for the camera position, which could smooth things out even more without too much work.

New feature: cinematic mode.



Sometimes a quick non-interactive event will run in the game. I want to make it clear to the player when this happens. Adding the black bars still seems like a reasonable way to do it.

There’s also some new code for camera panning & zooming between different targets and smoothly blending those transitions with mouse look.

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.