[filleduchaos]

> Having to wait for the server for the set of legal moves feels like a hack

But you are waiting for the server anyway - that's the "turn" in "turn-based". The way I build, the notification about your turn simply comes with the moves you can make as well - and the moves you can make don't change, because _it's your turn_, so there's no limit to how powerful a UI you can make with it.

Take chess for example (it was while implementing chess that I worked out this paradigm, actually) - a move from the server (sent in a packed binary format) was a mapping of start and end positions and a metadata byte that linked it to a kill, a promotion, or castling. and it was rare indeed that a complete payload (with a full set of currently legal moves + effects) would be up to two kilobytes. The client would deserialise that and of course could show you possible moves when you selected a piece and so on.

> The server and the clients all keep a full state of the game and when a player makes an action, it is transmitted to all the actors, who apply this action to their own state of the game.

This is actually what my current approach was born out of! But then I wanted to build a second client app, and I felt it was a pain to rewrite the game logic in another language - one solution to that is to have an isomorphic application, but in my case I decided to try out moving as much as possible to the server and just focusing on data parsing and rendering on the client and it worked out surprisingly well. It also let me do things like implement custom rulesets with much greater ease, because the rule logic exists solely on the server and you can deploy/modify that without requiring the clients to update.

[Longwelwind]

Fair enough!

I can understand the reasoning if you need to code a client in a different language, then you would effectively need to code the whole game once again. I feel like it would quickly bore me to code the rendering of each set of moves for each possible action. I feel like it's easier to have access to the complete state of the game client-side when you need to code a UI. There might be a solution if the server broadcasts the diff of the game state to the clients after each action has been performed (instead of letting the clients re-apply the action on their game state), but I'm not sure it would be nough.

How do you handle state synchronization, though? When a player makes an action, how do you propagate the changes to the game state?