Networking Board Game Design Pattern

Question

I am currently working on a board game in Java with libgdx. It is supposed to be a multiplayer game, that you can play across multiple computers and for the sake of simplicity, I use kryonet.

Even though I assume my friends are no cheaters, I want all the game logic to happen on the server. This is for learning purposes, so I get to know a clean approach of anti-cheating.

However, I have been looking for design approaches for days now and really can't get my head around how I am supposed to handle actions, their verifications and distributions. You can think of the game as turn-based and similar to Monopoly, it especially has some sort of randomness (drawing event-cards).

At first, I came across FSM and thought it would be a perfect approach, because I could easily let a state process the input and send a corresponding package to the server, who does the validation and broadcasts it to the other clients, who then.. Yeah, what do they do with it? Simply updating the model (as of "Player 1 is not at tile 8) doesn't make too much sense, because I would then not have any actions, such as walking, state transitions, etc. (the game is running in an update method, with a delta parameter, so you usually step your game forwards here).

The second approach I came across was an "action" approach, that strongly discouraged the use of a FSM, because they would easily get too big and too complicated to understand later on. Every Action would have an "isvalid()" function, so the server could check the model for the action to be legal and then broadcast it to the clients to "take action" (pun intended). Here again, I feel the need of a FSM on the server side, so I can validate, whether an action would be legal or not.

Do you think it is fine to mix two approaches? Is there an major point in my understanding of the approaches, that is entirely wrong and leads me to some misconception?

Thanks in advance and have a good weekend!

Answer 1

I am currently doing something similar, and would advise to use FSM as much as possible, in combination with actions.

On the server side, where the game logic is resolved, use FSM where transition from one state to another is triggered by an action from a player (or an external event such as a timeout).

On the client side, it makes sense to be able to render the current game state without performing all actions that led to this state:

1. When a player reconnects after a disconnect.
2. When a user can "watch" a game in progress.

But indeed for showing transitions it is useful to not only send the new game state to the client, but also the details of the action that led to this new state.