this will be a very short blog post about Finite State Machines in GML that I learned about recently and now incorporated into GreyHole. And I really need to get this off of my chest as I am super happy that I learned about it since it helps me grow into programming and managing code, events and general behavior a lot better.
Ever since I started to dig a bit into gamedevelopment I encountered the name “Finite State Machines” or just “State Machines” in my peripheral vision. But I did not really take it in as important. It read like something very advanced, hard to learn, even harder to apply and thus not relevant for me as a rookie developer. I was quite wrong about that, but I guess that sometimes you have to encounter the underlying problems to be open for the learning process. The first thing I learned is that it’s far easier than shuffling if statements left and right.
So what was my problem? It was very much just an increasing complexity with my game that is not yet a game, really. I started off with the game mechanics, then added a death screen. A death screen had to be checked for and handled. Then came the main/pause menu (it’s the same for GreyHole) and all of a sudden I had to check multiple conditions to be able to control the relevant elements and it showed that it would quickly grow too complex to maintain efficiently.
As you can see above in my bad example, I had set global variables to be able to check wether the game is running, if the deathscreen was active and so on. Each action I wanted to take had to consider several dependencies and I really struggled with the thought of the expansion of that. I wrote in both DevBlog#3 and DevBlog#4 about how I admired FriendlyCosmonaut for her clean structure and ordered way of doing things. That was mainly due to her clever usage of Finite State Machines. And unwittingly I took her FSM into my menus. Just because she did not mention it as such, I did not recognize it. As I am a “learning from tutorial following”-guy I looked up different ones for FSMs, such as Shaun Spalding’s video tutorial and the written one over at Michael Charnecki’s Blog. I quickly realized that I had to order my thoughts and that should best be done visually to then be able to transfer the structure over to GML.
For that I threw together a flow chart that I made in Libre Office Draw. That came alon very quickly and after a little more thought I also got the transitions between the states correctly. That way, the whole game can only be in one of the four states as shown in the flow chart above. To trigger a different state all relevant elemtns, objects and scripts can put the game into transition states. I named them with the enumerator “game”. So when I trigger the transition state “game.starting” the o_controller object disables the menu, loads all game relevant assets and then triggers the “game.active” state when done. It all gets handled in a switch statement inside the o_controller object. This allows for a lot of readability and most importantly debug-ability. I enable and disable, spawn and destroy objects in a central place within this switch statement and don’t have to worry about where I am inside these objects or scripts. I can’t express enough how Finite State Machines simplified everything and how wrong I was when I thought it would be difficult. It’s just a different approach. It’s cleaner and I have not yet encountered any disadvantages. Now GreyHole can grow and I don’t need to be afraid of complexity!
I am not yet done with reordering everything. I still need to refactor a lot to make things more readable and stringent. Consolidating scripts, their naming and so on. I’ll be working on that for the remainder of the week, as well as on implementing more options to take effect when you change them.
That’s it for today.
Kindest almost winter regards,
GreyHole - #DevBlog -