DEVLOG 2023-12-16

This week I was supposed to setup a failure strategy and logging system but before that I wanted to quickly implement the most basic game states: having a title screen, going into the game, getting back to the title screen and having a settings screen openable from about everywhere. To achieve that I needed to use a finite state machine library and as mentionned last weeks and in livestreams while prototyping, I was not completely happy with the ones I have available for C++. So I decided to go with a custom one, to have the exact set of features I need.

It took most of the week’s spare time. I also had a ton of work with music and dayjob so as I’m writing this I’m completely exhausted, I’ll try to make it quick.

The FSM code is currently very runtime-efficient, because… well there is almost no runtime code, it’s all hardcore metaprogramming generic nunchucks. It have been a few years when I had an opportunity to get back to puerely generic programming for this kind of tools. It works, or at least my tests works. The thing allows to specify a table of transition statically, which also allows to easilly generate the state instances and will call their entrance and exit member functions if they exist, as expected. Providing an incorrect (as in “it makes no sense” or “there is duplicat transitions in there”) transition table will not compile, providing states that doesnt support how they are handled through the state machine usage either. You can, but are not forced, access the interface of every state without having any runtime cost (no inheritance or anything remotely close) and it basically takes no space other than a tuple of the different states. I’m quite happy with the result. As of now it is usable to continue with the game-specific code and can be used also in smaller contexts like in the behavior of some enties.

There is however some missing features, but they are not necessary to add immediately:

• I want to add an optional way to have progressive transitions of state (for example to handle a fade-out-fade-in between screens, as I did in Hard Glitch) which means allowing return types of entry/exit functions to be coroutines and automatically handled in that case. I can use whatever I want as a return type currently but there is no special handling to allow that progressive transition feature. But that’s for later
• Right now the syntax to describe the transition table is quite ugly, although very clear. I would love to have a small DSL for that, but that’s far from a priority, more like a luxury. I’ll look into that if I find the time later, or if my patience with working with the current syntax worns out.
• Some special kinds of transitions, like “from any state, if there is this event, go to that state” are not handled yet, although it will become important when I start adding a settings screen. I prefer to have one early because it’s useful to fill it progressively, for testing purpose.
• Ideally I would move that code into a separate library on github as OSS and have some expert eyes to review my kung-fu stances with that one, mainly because I suspect (from experience) that I’m not seeing issues. My tests shows that everything works as expected but you never know. Also it might be useful for a few other people.
• The tests are… well they cover a lot but are not organized at all because there was a lot of experimentation going on. I need to clean that up to properly improve on them afterwards.

So this weekend I’ll setup quickly this time the 3 screens I want, driven by such state machine, and proceed with the other “seems simple enough but will take days” stuffs.

Hopefully I can focus on game-land code next week. At least that’s the plan.