How do you put together your games? (State Machines)


I’ve recently been exposed to the concept of state machines, and aside from being great at organizing user input, they seem to be really useful in piecing together parts of a game.

I don’t think I am qualified to explain what a state machine is if you don’t know it, but here is one of several articles I have read on the subject.

For example, here is a diagram representing some states of an RPG game, and what triggers those states:

I have made a simple state machine, but it’s pretty bad so I’m not going to add it here.

However, my main question is, is a state machine a good way to stitch together a game? If so, how would you go about implementing a good state machine? If not, how do you put together the different parts of your game?


It’s good to plan out the UI like this so you can optimize it; however, you don’t want people in too many screens when they first join as most of them are kids and they aren’t patient.

As for how this will be used you’ll need to learn scripting if you don’t already know lua.

This is more of a game design post not a scripting support post.

1 Like

I didn’t even know that there was a game design thread, whoops! Thanks though :smiley:

However, I was mostly asking how people put together the different parts of their game efficiently and elegantly…

Think of it like writing a paper, you first must make a rough draft. In this instance you’ve made a diagram for a base lay-out. Next you’ll need to make it materialized and functional from there you can test it and see how smoothly it works and have some people give feedback on it and also look at how other games have theirs configured.

I normally just go off memory and do that part in my head and then make images for my background with a base design set so all my gui’s will have the same theme.

Here is a example of one of my games i’m in the process of making.

Even same layout for the crafting menus.

1 Like

Impressive! But I think you might still be misunderstanding my question a little bit, I will try to rephrase it here and if you understand it then I will edit the main post. Sorry for the confusion!

I’m not asking about designing the actual game, I’m talking about how you piece together the individual parts of your game. For example, in your game, I see that you have an inventory. But you probably shouldn’t be able to access it in, say, a cutscene. But how does your inventory know when you can’t access it? You could do it the obvious way and simply disable the inventory whenever you don’t want it, but depending on the type of game, every time you enable something, you will have to disable a lot of other things, and when the player leaves that thing you just enabled, you have to re-enable everything you just disabled and so on, and that gets really hard to manage. Using state machines, only in certain states will some things like the inventory be available. For example, in a “Gameplay” state, the inventory can be accessed, but in the “Cutscene” state, the inventory and pretty much everything else would be disabled.

I know that was an awful example and I probably still didn’t get my point across, but I can’t think of a good but simple example for an entire game. But to the main point: my question is, how do you piece together parts of your game (like your inventory, and introductory cutscene, etc.) such that the code is elegant and easy to maintain?

So lets say we have many different things that can open and close ui for cut senses, maybe you don’t want the ui displayed while the bank is open or if the player dies and you want to display a re-spawn screen. I’d say get a boolen and just change it from true to false if it’s changed to true hide the uis.

Planning it out like that helps a lot because you can use it for coding also, for instance: a quest system seems tricky to create. Most games only do kill x monsters for y gold, very boring and basic.

I’d use one to help me understand my layout and take into account many variable and or step that i’d need to make for each quest. This lay-out helps you set up for base quest system that could be placed in a module and called upon for simple content added anytime and still have the ability to create complex quests or add manually coded sections of a quest.

Thank you for linking the article on state machines, I learned something new today.

However, my main question is, is a state machine a good way to stitch together a game? If so, how would you go about implementing a good state machine? If not, how do you put together the different parts of your game?

State machines are useful for things that should only be constrained to 1 state, such as handling visibility of UI. For example, you would only want 1 GUI open at a time, or disable visibility of GUIs entirely when, say, you’re in a loading screen, in which case you should implement a state machine.
This is exactly what I do in my games, and ever since I started using this method, it’s never been easier to add new UI, or add restrictions to when UI can be opened/closed.

Your question is vague, though. Which parts of a game are you asking about?

From your reply to DevVince, it seems like you’re only talking about handling UI. Could you clarify which parts of a game you’re asking about?

1 Like

Huge fan of state machines. I’ve used them for controlling robots and websites and all sorts before.

I think they suit a certain type of game very well, particularly if you have different core loops that are exclusive, and can occur in a number of different orders.

For example, I’m working on a city builder game, containing a few key states:

  • Initialisation (including selecting a save slot to load)
  • City Running
  • Edit Mode

You can transition between any of these states from any of the others depending on the inputs and a few conditions, so a linear structure wouldn’t work.

And within edit mode there are sub states like

  • Building placement
  • Water network management
  • Power network management

Again, you can transition between these sub states in any order you choose.

State machines are super useful because you can have the same inputs, e.g. the user presses X, but the outcome depends on the state. In complex games or games with exclusive loops (e.g. the city is never running while you’re editing it) then state machines really help to organise things.

I don’t really use state machines for UI screens as such, because generally the input is separate. It’s mostly useful for cases where the input is the exact same (e.g. keyboard presses and mouse movements). When you hover over a building in edit mode, the response is entirely different and exclusive to when you hover over it in run mode.

I think your diagram in the original message was confusing, and perhaps a better diagram shows the different ways to transition between states. Here’s an example using a well-known board game:

The quality of a state machine resides in the way you define the transitions and mapping out the conditions or triggers to cause the transition.

In terms of how to code that, well I usually create a state-setting function, and each state has entry and exit code. When you exit run mode, I hide the run-specific stuff. Then when I enter edit mode, I show the edit stuff. That saves you having to spend loads and loads of lines disabling everything that might have ever been visible. Knowledge of the previous state allows you to disable only the things that were enabled by that state. If you have 16 states, you should only ever be disabling one and enabling another, not disabling 15. That’s where the transitions are key.

I think some of the other repliers didn’t really read your post or are unfamiliar with state machines but I hope this helped. It’s important to realise state machines apply to anything you do in life where the sequence can be non-linear. The only question is whether you have enough states or the loop is complex enough to warrant the time spent coding it.


Thanks a lot for the reply!

I guess my question is pretty vague, but I don’t really know how to word it. However, the reply that BanTech made perfectly answers my question. Whenever I try to reword my original question, it always turns out the exact same, so I will just apologize for my vagueness! :stuck_out_tongue:

That was a well explained use case for a state machine, thanks a lot!

I guess my diagram doesn’t really make sense for a state machine directly because the inputs/events are very vague, or maybe there is another reason that I don’t quite catch on to… XP

Using your reply, I did fix up my state machine module some, but I ended using and modifying this state machine module for lua.

I hope your city-building game turns out well, and again, thanks!

1 Like