How to create a finite state machine to load your game using JavaScript
On this new post I’ll explain how to divide the whole process of loading a game by using a finite state machine.
The type of game we’re facing to fit this structure is a game that retrieves the needed data from an external file hosted on a server or on the game project to create the views, interface and get the game ready to begin depending on that data. This data can be composed of a saved game and the game configuration, the upper image is the FSM diagram the post is based on.
Finite state machine structure
The first state to begin with is called ‘init’, on this state we’ll get the game configuration data from our external file and store it in our game models.
Next, we switch to ‘LoadingAssets’, here we load the needed game assets to begin the game such as atlas, layouts, sounds, animations, particles, fonts…
When the assets are ready, we check in ‘LoadingSavedGame’ if the player has a saved game to take into account in further states.
On ‘CreatingViews’ we start to build the game views creating sprites, animations, texts and more, using the assets loaded previously on ‘LoadingAssets’, here we take into account the player’s saved game.
Having our views ready, now on ‘CheckingInterface’ we enable or disable the suitable buttons, graphics and so on to begin the game, corresponding with the player’s saved game or new game.
Finally, our game is ready to be played, depending on the existence of a player’s saved game, the game will begin from a checkpoint, or from the beginning of the game.
From this point, it all depends on your game logic to add more states to the FSM, this structure is thought for puzzle-like and arcade-like games.
Constants Definitions
We begin being tidy by defining the needed constants related with states and actions of the FSM.
The state is where the code makes its job, and the action is what triggers to switch to another state of the FSM.
Basically, we are ‘coding’ all the states and actions defined on the diagram image at the beginning of the post.
Finite state machine configuration
On this class, we define which action triggers which state and the getter and setter of the state. We’ll need to use listeners and event dispatchers on this project, in my case I was using a previously created custom library, you can replace it by the library you like to use.
Loading the finite state machine
On the main game file, we import all the game states classes, instantiate the FiniteStateMachineConfig class, create a stateControllers object which contains an instance of each game state class and define the listener that will trigger the change of state.
GameState classes
WaitingToPlayGameState is an example of the code structure for a gameState class. All the other gameStates classes should follow this structure.
When a change of state is triggered, the first method called on the new state is enter, on this function we can define listeners and call other functions defined on this gameState or on other classes.
As we finish all we needed to do on this gameState, we dispatch an action, which will be retrieved by the FiniteStateMachineConfig, and switched to the next state to jump in. Just before changing to the new state, the method exit will be called, this is a good place to remove listeners related to the gameState and reset related variables.
And that’s it! I think there is many documentation about FSM applied to gameplay and AI, but very little applied to game loading tasks, in comparison, which is a pity because I find very interesting and advantageous to know how to structure your loading tasks and apply it to a FSM :)
