![\"\"](\"https:\/\/osu-wams-blogs-uploads.s3.amazonaws.com\/blogs.dir\/4753\/files\/2021\/10\/image-2.png\")
<\/figure><\/div>\n\n\n\nHere we know that every loop will only ever be in one state and that every state individually controls what other states it can enter. So from start to finish a given state controls everything about that execution sequence. It doesn\u2019t have to worry about other states interfering and it doesn\u2019t need to check if we\u2019re flying because we\u2019re obviously dying instead, otherwise we wouldn\u2019t be in the dying state to begin with. This example leads to my next bit of code, otherwise known as \u201cindicators you might need a state machine\u201d:<\/p>\n\n\n\n
![\"\"](\"https:\/\/osu-wams-blogs-uploads.s3.amazonaws.com\/blogs.dir\/4753\/files\/2021\/10\/image-3.png\")
<\/figure><\/div>\n\n\n\nThis is a not so exaggerated example of code similar to some I\u2019ve seen in my teammates work on previous projects. These often tend to spread all over the place as systems get more complex and often act as band aid fixes when characters are doing things when they aren\u2019t supposed to. The problem here is that aiming has to care about all the other actions the player could take and for each new one you add there\u2019s an exponential growth of systems that need to check for the status of other systems until you\u2019re stringing along conditionals that become impossible to manage. We don\u2019t want \u201caiming\u201d to have to worry about if you\u2019re \u201cdancing\u201d or \u201cclimbing\u201d or \u201cjumping\u201d (well maybe jumping, but we\u2019ll get to that later). We want \u201caiming\u201d to handle aiming. That is its one responsibility and removing all the extra complexity makes designing a system that handles aiming much simpler and more straightforward. This makes any system where you can compartmentalize logic into separate states easy to handle and develop.<\/p>\n\n\n\n
All this sounds pretty good right? Well then what’s the catch? Well a good example of the catch is jumping. You might not want to dance when you\u2019re jumping, but if you\u2019re making something fast paced you may want to be able to aim while you\u2019re jumping. Well ok, one combination is simple, we can just put together a new state called \u201cjump-aim\u201d. But then what if we want to do flips while jumping and aiming? Then we need \u201cjump-flip\u201d and \u201cjump-aim-flip\u201d and then we need to consider how you transition between them. Can you jump-flip into jump-aim-flip? Can you jump to jump-aim to jump-aim-flip? Then how does non jumping aiming transition into all of these states? Wait, this is starting to turn into the problem we had before where things were handling too much at once. And this is where state machines start to break down. There are two main issues at hand here; the first being that states without clear boundaries start to break down when you try to put them together i.e. composite states. The second, and arguably the bigger issue, is that whenever you add a new state, suddenly every other state has to be considered for transitions. While we\u2019ve limited the growth of long if statements, the growth still exists. For every additional state we need to handle all the different transitions, both in and out, to all the relevant existing states. These two issues combined can cause state machines to balloon out of control and become difficult to manage and expand over time. While I personally haven\u2019t had to deal with extreme cases of this, I\u2019ve definitely had to toe the line and it\u2019s easy to see how something complex could make an unmanageable mess.<\/p>\n\n\n\n
So while state machines definitely have their uses, they aren\u2019t a magic bullet to every problem. An easy way to tell if they\u2019re good for a given system is to consider how well the system\u2019s tasks separate into independent functionality. If they don\u2019t cross the line into other tasks’ functionality often, then the system could be a good candidate. In addition if the system isn\u2019t meant to be dramatically expanded on then it also could be a good candidate. If neither of these are true then it may be time to learn something a bit more complex or to try and re-design the system to better accommodate the separation of responsibilities. <\/p>\n\n\n\n
All that said, just remember that using a state machine is probably better than going in without a plan at all. They can make your life easier when used correctly, just use caution so you don\u2019t turn your team\u2019s project into a monstrous machine.<\/p>\n","protected":false},"excerpt":{"rendered":"
I remember my first introduction to state machines was by a professor exclaiming about how terrible they were. When I eventually discovered how they worked and what they did I thought he was crazy. In my head I thought \u201cthey give you so much control over logic flow and solve so many complexity problems, how … Continue reading State Machines Are Bad and Why You Should Use Them Anyways<\/span>