It has been more than 3 years since I wrote my original blog post announcing my remake of Total Invasion II, and naturally some things have changed since then. I am still working on the game, but unfortunately my progress has been quite slow due to my transition out of college and into a job in the software industry. My current place of work leaves me with little energy to work on this project, but like an immortal snail sent to kill you I am working at a steady pace towards my goal.

First of all, I will outline the current direction for the project before going into the specifics:

The project is now being titled Total Invasion 22, because it's Total Invasion 2...2! This game will be fundamentally different in many ways, so calling it something like Total Invasion II 2.0 would not accurately describe it. In fact, I have already released an update to the original Total Invasion II on 1/7/2024 that modernized it a little bit, adding things like customizable controls, Linux support, and small graphical and balancing enhancements. It turns out that I had made about 90% of this update back in 2022, but when I decided to go the remake route I completely forgot about it, even though it was so close to being a complete update.

On the other hand, Total Invasion 22 will be almost a different game. It will have many of the same levels as Total Invasion II, but they will be refurbished and the game will play differently. There will also be a complete overhaul of the graphics, music, and sound to make it more polished. Physics, movement, AI attack patterns, and weapon behavior will all be revisited. My plan is to release a demo for free, with source code, around July 29th of this year, the 10 year anniversary of Total Invasion II. This will include a few levels from the first episode of the game. Once the demo version is refined enough, I will continue working on the rest of the game, adding the remaining levels from Total Invasion II as well as a 4th episode of new levels. I am hoping to release the full game on Steam for a modest price. I'm not expecting to pay any bills off of this game's revenue, but I'd like to see how far my game can go when I give it my full effort. Though, given my current development speed I have no clue how long it will take me to get to that point.

Where is the project now?

Currently, I have almost all of the engine and gameplay code implemented to play the level E1M3 from Total Invasion II. I need to add some polish, some menu and options systems, finish some more art assets, and implement one more weapon and I will be able to have a fully fledged vertical slice of the game. I am going to set up an automated script to help convert Total Invasion II maps into the new format and then make manual adjustments. From that point, I will mostly be implementing the last few enemies and weapons, and redoing the other episodes' graphics, sounds, and music. My hope is that the hardest part of the project is now behind me and I will now be able to focus on the gameplay.

Boring technical gobbledygook

Many times I have questioned my decision to make my game from scratch, that is, without a game engine. The experience has been very enjoyable for me. I prefer to make games this way, using libraries here and there but handling all of the architecture decisions by myself. However, it has taken a very long time. I have spent months going back and reworking some of my core engine systems like collision detection and audio, which I would not have had to do in an existing engine. Still, if I had stuck to something like Godot I would not have felt as motivated to finish. Working on a large project in a game engine can be a frustrating experience, because you have to deal with all of the decisions, assumptions, and technical debt that the game engine has. In my own codebase, if I want to parse metadata from my sprite files, I can just do that in a very straightforward way, without dancing around the engine's asset pipeline and pouring through documentation and source code trying to figure out how to fit it in. My other 3D project War Priest was made using the Urho3D game engine, but it still took years to make and is now much harder to work on due to the engine being taken over by Russians and then abandoned for some reason...? Well, anyways, the tradeoff of using an engine may not have been that big. Instead of reworking the collision detection for the 6th time I would have been banging my head on the desk trying to find workarounds for several game engine bugs.

I also overcomplicated the project in several ways. I made a fully featured level editor, which is really nice, but my game's levels are laid out in such a simple way that I could have found a solution that did not require me to put in so many dev hours. Writing it in C++ also hurt my development speed a lot. Having to maintain an editor separate from my game's code also meant that I had to implement some things twice. Though, this editor is getting a lot of attention on Github and Itch.io, more attention than many of my games have gotten, so maybe this will become the legacy I am known for. It also came in handy for my recent game jam entry Helljumper.

Some of my architecture decisions also made things complicated, like attempting to write an ECS from scratch several times before finally giving up because it wasn't neccessary at all. My usage of low-level OpenGL with GLFW wasn't all that necessary, and I could've used something like Raylib, Sokol, or SDL to speed up my process a lot as well. I eventually made better decisions like using Miniaudio for my sound system, which did a lot for me but gave me enough control.

Collision detection by far took the most time. Most of the gameplay takes place on a 2D plane, but I made a fully 3D collision detection system. I hate working with physics engines, because they often cause subtle and hard to track down issues when a game object is moving in a non-physical way, such as with character controllers. Unfortunately, the Golang ecosystem is not popular for game development, so the only significant library for collision detection without physics is one called resolv, but it is only for 2D. I haven't tried it, but it might have simplified my work quite a bit if I did. There are only a couple of game objects that would need to consider movement on the vertical axis, so I could have made some workarounds for that. I also implemented triangle-mesh collision detection for my system, but I could have gone for something simpler. However, I think the experience of writing my own collision detection was very valueable. I may be able to use what I've learned to make my own library for 3D collision detection someday so other developers won't have to keep dealing with this.

As I mentioned, my game engine is written in Golang. This language has really good developer ergonomics with a focus on having a minimal but flexible set of features. I feel really productive in this language and it is one of the reasons I have been able to stay motivated to work on this project. However, it is not the ideal choice for writing a game engine. While Go is focused on being performant and reducing heap allocations as much as possible, it is not really a systems level language. It does not give you much control over things like memory allocation, struct layout, etc. which can make it harder than necessary sometimes to tune performance. Go's performance has been fairly good in most scenarios, though, especially because my coding architecture is very mindful about allocations. Just don't use the new standard iterators, they be kinda slow. I ended up reimplementing my audio system using C and Miniaudio because existing audio solutions for Go were causing significant amounts of pausing due to the large memory allocations that need to be made for wave files. Fortunately, my audio subsystem was fairly simple and writing that part in C was a smooth process and I got an instant, easy performance boost. I think Go was a decent decision in 2022. Because the C/C++ ecosystem makes me want to pull my hair out, the best alternative would have been Rust, and I had tried Rust but it has a big learning curve and a lot of developer friction that would have slowed me down even more, especially when it came to writing highly dynamic gameplay code. This article has a lot of great points about this. If I were to start again today, I would definitely by writing it in Odin. Odin has many of the benefits of Go's ergonomics while giving you manual memory management, tools for tracking memory leaks, and easy interoperation with C code. It's an unfinished language, but in its current state it is stable enough to have been used in a few commercial projects. I have been tempted to port my code over to Odin, but my project is going slow enough already, so I'd better not :p

I made a significant update to my map editing software Total Editor 3 to support my development of Total Invasion 22, my upcoming remake of Total Invasion II.

This change makes breaking changes to the map format to add support for multiple textures per tile. Now each tile can have a primary texture, selected with left click, and a secondary texture, selected with right click. This removes the need for some of the weird, hacky solutions I had been making to make floors and ceilings look right in my project. I do not plan on making it support more than 2 textures, though, since I think doing so would require significant changes to the editor's workflow that would probably make it less convenient to use.

Any maps saved from version 3.1 will be automatically converted after being saved in 3.2. I also took the opportunity to reduce the size of the .te3 files by about 30-40% by using smaller data structures. Now these maps are starting to become even smaller than the ones I made for Total Invasion II!

Other changes include:

• Removed hacky shapes and textures meant to work around 1 texture per tile limitations.
• Updated example maps to not use removed assets.
• Missing shape model files are now replaced by question marks.
• Fixed bug with entities being misplaced after map size is expanded.
• Made currently open file show up in the window title.
• Status bar will show cursor grid coordinates when nothing else is showing.
• Tile cursor will stay in place while using the scroll wheel if the mouse is not moved. This helps with constructing vertical columns.
• Textures and shapes copied from other tiles will be highlighted properly in the texture/shape picker modes.
• Added setting for hiding certain file names from the texture / shape pickers using a regular expression.
• The editor will warn you about losing unsaved changes and converting map formats.
• Tweaks to enhance readability and visual organization of modals.
• Fixes to the .ti importer.
• Updated and corrected instructions.

A new tile shape was added in order to more easily create floors with diagonal patterns:

I have begun work on the remake, which will simply be called "Total Invasion II 2.0" and will replace the original game on all of its distribution sites. I will, however, keep the original version accessible.

My plan is to remake the engine "from scratch" (that is, using OpenGL and a handful of other libraries instead of an existing game engine) as an enjoyable learning experience. The game's graphics are simple enough that this shouldn't take an excessive amount of time. So far, my plan is to write it in C++. Despite C++ being a pain in the butt to develop in, I think the experience will be valuable for a future in game development. I am also thinking of making a new version of the map editor in Rust, as a way of exposing myself to that language.

Technical talk aside, here are the features planned for 2.0:

• Balance difficulty in all areas
• Fix collision bugs
• Fix raycasting (enemy sight) bugs
• Improve hit detection on explosions
• Improved game performance
• Improve grenade physics
• Fully serialized saving and loading
• Developer console
• Rebindable keys
• Support for multiple resolutions
• Improved lighting and fog

And if that all goes fine and well, I might try my hand at making further enhancements for 2.x:

• Cleaner art style and music (with option to switch)
• Improve look of map geometry (add crevices, slopes, height variation)
• Add bonus fourth episode
• Add Russian localization
• Add alternate character (Ivantari, scythe wielder)
• Add multiplayer deathmatch mode...? Eeeh, maybe.
• Remove Geoffrey

As an example of what a future art style could look like, take this screenshot from my Godot prototype:

Guten tag!

While recording my playthroughs on Youtube I realized that, once again, many of the maps in this game were much too difficult! I spent about 40 minutes trying to get through E3M4 -- screw that map, I want to punch whoever made it...oh, right...

So today I released an update that changes some of the level design to be more forgiving, particularly in episode 3.

However, there are many more problems with the game's difficulty that revolve around its fundamental workings -- Proper raycasting is poorly supported in my janky custom engine, so explosions tend to get you in places they shouldn't, grenades don't bounce properly, and it is easy to get stuck on corners.

Damage taken from enemy contact is accumulated every frame and is also the leading cause of death!

Fixing these problems would involve significantly changing the foundation of the engine -- one that I wrote in 2015 and is an absolute mess.

This is part of the reason that I'm planning to remake the game to be much more maintainable, polished, and stable.

I'm still debating with myself what tooling I'm going to use, but rest assured it will be coming eventually™.