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!

  • 3
    \$\begingroup\$ In my opinion you seem to have caught a bad case of analysis paralysis. There is no one right way to do things in game development because every game is different. Any of the approaches you have here is valid. My recommendation would be to just get something running, see for yourself where your design got drawbacks and then ask us how to fix them. \$\endgroup\$
    – Philipp
    Jan 20, 2018 at 12:40
  • 1
    \$\begingroup\$ Thank you for improving my developer life with the simple metioning of the word "analysis paralysis". I was not aware of this state but now realize, that whenever I messed up my very first approach (dirty coding), I immediately turned crazy and tried to find the very best approach in the world, before touching a keyboard ever again. Cheers! \$\endgroup\$
    – Rufrage
    Jan 20, 2018 at 12:45
  • 3
    \$\begingroup\$ When any failure makes you question your abilities and sends you into analysis paralysis, then I got a video for you: Extra Credits: Fail Faster! \$\endgroup\$
    – Philipp
    Jan 20, 2018 at 12:52
  • \$\begingroup\$ can you elaborate why an action approach would impede your ability to use FSM pattern? I think they can both be used with relative ease. Just keep all the FSM code on the server and have all client/server communication be actions. \$\endgroup\$ Jan 21, 2018 at 5:58
  • \$\begingroup\$ Jonathan, this is exactly what I will try now. The client will send commands to the server, which checks theit legalness and broadcast them out to the world (in this case the 4 players). The server itself will have a FSM that only considers commands, which are currently possible at all (and therefore indirectly throws away the rest). This makes the classes a lot cleaner and easier to read. \$\endgroup\$
    – Rufrage
    Jan 22, 2018 at 14:51

1 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.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .