[zem]

is it too expensive to send an event log to the client and have it be replayed? i did that for a stateless scrabble bot and it worked out pretty well, the bot got an event log from the server, replayed it to construct a board position, and sent back a move which was added to the event log sent to the other player.

[mathgladiator]

that's what I am doing, but my events are data transformations with zero game-context. For instance, I have an array that goes from [1,2,5,7] (card ids in your hand). I will know that array will change into [1,2,5], and that's great. However, why did it change? Did I play a card? was a card taken from my hand? Did I trash a card?

The immediate problem is how do I animate the card going away? The next question is how do I convert that to text like "You drew a card" versus "You stole a card from player X"

Now, ideally, I want to make this very simple and also privacy respecting as well. I can hack the card animation problem directly by having the UI detect connect the dots between cards appearing and being orphaned. This may be good enough for many scenarios.

Another thing I'm thinking about is contextualizing the events the client sends (which do have more domain context). This is probably the right way to go, but this adds a new layer to think about.

[zem]

it would work better if the event was something like "PLAY, played=7, drawn=K, trashed=K, hand=[1,2,5]" with the client perhaps validating that applying the play does lead to the hand [1,2,5] as an error correction mechanism.

you need to make sure not to leak information about one player's hidden moves to another player, of course, but in general i would say have your events be as rich as possible so that clients can interpret them for animations, screen reading etc.

edit: for reference, this is the format scrabble programs have standardised on for their event log: https://www.poslfit.com/scrabble/gcg/