I reimplemented a process management scheme I wrote about elsewhere, finding a few bugs/inconsistencies in the original implementation and trying to recall why I made certain design decisions when the system was originally implemented.

The basic gist behind the system is to break up the game into small running processes, where a process has a small defined task and responds to messages while performing this task. Processes can have child processes, forming a process tree.

The process scheme evolved after I developed a distaste for the way I was handling state management; a giant switch-case for the different states/substates grew hideous, and keeping a queue of states left a lot to be desired (for instance, jumping back to states at arbitrary positions in the queue, which is pretty common).

The first implementation actually occurred during the original 72 Hour Game Development Competition, although it was quite rudimentary - processes could not have children, only one process could exist at a time, and there was little a process could do to communicate information to another process. In short, it was ugly, but it existed in that version in my codebase for well over a year before I came up with the scheme I wrote about.

I’ve been using the method in the article (with various tweaks/changes) for a number of years now in personal projects, and it’s done a good job for me. Hence why I’m giving it a place in, “Oh No, Zombies!”