Flux architecture in games — Porting the web design pattern to game development

The Web has progressed towards flux architecture and immutable state.

It makes perfect sense in the data systems world. You have one state, and invoke actions to get a new state, based on which you pass props to the view components and re-render when necessary.

Why not try the same concept in games?

After some time in the games industry, I’ve noticed that games are very similar to the usual webapps. You have the same MVC patterns in the architecture, it’s just the views that change.

In webapps it’s a browser displaying HTML components, while in games it can be any engine rendering your GameObjects (which are essentially assets — sprites, textures, etc).

So since the flux architecture worked out so well for the web apps industry, why not try it in games as well? After all, it’s only the views that are changing.

Let’s say we want to write Tic Tac Toe.

Our state object would look something like that:

{
    board:{}, //Current state of the board
    players:[], //Player objects, each player has a name and colour
    currentPlayer:{}, //Who is the current player to make a move?
    time:DateTime, //How much time passed since game start?
    steps:int //How many steps were taken until now?
}

We would also have the following action creators:

actions/moves //TRY_ADD_ITEM, ADD_ITEM_SUCCESS, ADD_ITEM_FAILURE  - player makes a move - add item to board
actions/rules //RUN_RULES - to run rules on board to determine if someone won.
actions/board //CLEAR_BOARD
actions/game  // GAME_START, GAME_END,...
actions/AI  //CALCULATE_NEXT_MOVE

Reducers:

boardReducer //updates the board model
gameRuntimeReducer //Updates game runtime - currentPlayer, time, steps, etc.

Let’s verbally debug the game:

1. Player makes a move — puts a X somewhere on the board
2. The system needs to check if the move is legal — whether the slot is free. That is done by running a set of rules on the board model.
3. If it is NOT free — the ADD_ITEM_FAILURE action should be dispatched, thus keeping the currentPlayer property without change.
4. If it is free — the ADD_ITEM_SUCCESS action should be dispatched
5. The boardReducer should update the board.
6. The gameRuntimeReducer should update the current player
7. If the second player is AI — the AI manager should fire up the CALCULATE_NEXT_MOVE action
8. After the next move is calculated, the TRY_ADD_ITEM should be fired, resulting in a succesfull board update and switching control to the other player.

The architecture described above is a simple example of how easily the Flux design can come into use in a tic-tac-toe game.

It allows us to easily add more players, change the game rules, change the view and the game state without having to tweak around or start refacoring and decoupling components.

This architecure also keeps our state nice and tidy, and has a very clear seperation of concerns and logical units. Did someone say SOLID?

It is reasonable to assume that at some point you might need to add RX (reactive extensions) to your game and start using Observables, which, to be honest, can also be integrated with Flux.

You just keep the unidirectional data flow in mind and don’t mutate the state. Keep using the Reducers and action creators, and there you have it, RX with Flux.

Once I finish my current projects in the runing, I will implement a redux-like library for C# game development. When this library is ready for use, I’m going to publish it and create a proper documentation page. I will also make a POC on top of it, and present some use cases and common scenarios handling (API requests via websockets, middleware, storage, etc).

Stay Tuned!