Total Invasion 22 Status Update
Updated 09.03.2025It 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