Guidelines: Architecture

Do you have recommendations about my data model?

Understand the concept of Game State. Use the “Event-sourced” approach!

A lot of your code design will come from the notion of Game State. The Game State is a self-contained and minimal set of data that completely describes the state of an ongoing game. It can be a block of bytes or a set of objects, it does not matter - as long as it can be serialized. The important thing is that you should be able to completely restore an (ongoing) game by reloading a Game State. Read more about Game State in the the Scalable Server documentation. We highly recommend using a proven serialization system (like Protobuf), because produced result will be much smaller, and you gain backward and forward compatibility for free when releasing a new version.

So ask yourself this question: what are the minimal data for my game? Exclude everything that is related to any user interface. For example, the Game State for a chess game would be the pieces with their location on the board, the number of turns, and the current player - you don’t need to store the pieces that were taken since you can infer them from the remaining ones on the board.

Once you have identified your minimal data set, consider using an Event-sourced model instead of a Snapshot model. We strongly advise to do this, you will get many benefits (among them better resistance to cheating, past actions replays when reloading a game, etc…) from doing this extra effort. So in our chess example, the Game State would become the list of actions of each player instead of the location of the pieces on the board. The actual board would be reconstructed by the Rules Engine by quickly replaying (and verifying!) all actions since the beginning of the game.

Last, ask yourself about fighting cheats. We have a number of simple recommendations for your data model that should help a lot in this area.

Should I start by coding the Solo mode or the Online mode?

Neither: start with the Pass-and-Play mode!

It seems natural to start by coding the Solo mode, so that you don’t have to deal with the additional difficulties coming from the network side of things. However, on second thought, this might not be such a good idea. A good reason is that coding a Solo mode implies coding some basic AI. This is not necessarily easy, and you might end up with too much coupling between your AI code and your data model.

Therefore we recommend you to start by the Pass-and-Play mode. The Pass-and-Play mode is a mode in which each (human) player plays one after the other, handling the device to the next player. Not only this is a feature that players always ask for, but it paves a great way to make a first viable prototype.

Also, the Pass-and-Play mode is a very convenient way to test your game because you have the complete control on what each player does.

So what the overall architecture is going to look like?

Clean separation of data, game logic and user interface will save the day!

Coding the Pass-and-Play will allow you to develop:

• The data model of your Game State
• The Rules Engine
• The User Interface

The Rules Engine is the guardian of the rules of the game. It is the module that validates the inputs actions of the players, applies them to the data model and returns the results to the players through the user interface and display. It is similar to the “Controller” part of the classic MVC model.

The Rules Engine isolates the data from the user. It is responsible for implementing the games rules. Therefore it becomes easy to develop using TDD (Test Driven Development) techniques.

You should design your code so that the player’s interactions are grouped in a single code interface, whether it is about getting information about the game or performing actions. The player should NOT have a direct access to the data model, it needs to go through the Rules Engine, especially if the game contains hidden information (cards in the player’s hand…). Remember: players cannot be trusted. :-)

The great benefit of making this abstract communication layer between the player and the Rules Engine is that it will make connecting an AI or the online gaming much easier. It will also allow you to implement advanced features such as Bot Hot Swap (replacing a player by an AI on-the-fly), Game Resuming, mixing human and AI players, etc.

You can learn more about all this in the Rules Engine article.

If you are using the Asmodee.net Unity SDK, you will find classes that structure all these concepts. You will still have to write code, don’t worry! You will have a framework to get started but it is important that you understand why it’s there.

Ultimately, you will end up with:

• A serializable data model with an API (your Game State).
• A Rules Engine implementing and controlling the game rules, with unit tests.
• An abstract communication layer between the players and the Rules Engine.
• Players implemented as human interaction-based, AI-based or network-based, which can be connected, mixed and even switched on-the-fly to the Rules Engine.