6 ms·

This engine uses a Redux-like architecture. You have a State type (containing data like "the position of the black kingside rook") and a stream of in-game actio

This engine uses a Redux-like architecture. You have a State type (containing data like "the position of the black kingside rook") and a stream of in-game actions (like "knight to F3"). Each action is handled by a pure function which converts the current State to a new State. You can either transmit State deltas from the server to the client, or just transmit the actions themselves (https://longwelwind.net/blog/networking-turn-based-game/ https://longwelwind.net/blog/networking-turn-based-game/). This design makes it easy to implement optimistic updates, rollback, replays, automated testing, and recovery after a disconnection. It's a surprisingly good fit for UI, too; you can render simple games as a React component which takes the current State as one of its props. However, a stream of context-free actions can be a really inconvenient representation for some games. The rules of a board game are often like the control flow of a computer program: you'll see branching, iteration, local variables, function calls, structured concurrency, and sometimes even race conditions and reentrancy. When you try to represent all of this logic as a State object, you're basically maintaining a snapshot of a "call stack" as plain data, and manually resuming that "program" whenever you handle an action. It doesn't seem ideal. I've been sketching a board game engine which would represent the game logic as normal code instead. It seems promising, but it really needs a couple of language features which don't exist in the mainstream yet, like serialisation of suspended async functions.

NathanaelRea 2y ago
Can you explain more what type of game would need a call stack snapshot? I've never developed a game, but it seems like as long as you store like the initial state and prng you could always get the current state by replaying the full history. All the other logic would be stored outside the state, and only added when "committed". As long as prng is stable and you start from the clean state every time, you'd get the same outcome.
- yojo 2y ago
  I think I have a good example from Magic: the Gathering. There’s a card called “Fact or Fiction”. You reveal the top five cards of your deck. Then your opponent splits the cards into two piles. Then you pick one of the two piles to take into your hand. You’ll need to store structures representing the choices that are intermediary steps (split cards, pick stack) in your state, which is basically function calls and their params (a call stack). This example could get hairier - Magic also features cards with branching logic “choose 1: do a or b”. I can imagine designing cards with large and convoluted possible execution paths. You could have the card define a schema for state transitions/params and represent all these choices as JSON encoded POJOs, but as a developer it sounds a lot nicer to just be able to suspend an async function every time a choice is made.
  - Longwelwind 2y ago
    I had the same issue in AGoT:BG and I solved it by representing the state of the game as a tree. At any point of the game, the current game state is a leaf of the tree. You'd represent this kind of choice as a child node. When the user has made their choice, the code can return to the parent node with the choice being made so it can continue with the next "step" of the game.
    - scrollaway 2y ago
      This is the correct response. Hearthstone is structured like this internally. If you are curious about it, I wrote a cc0 spec which stores hearthstone game state in xml. It’s based on how hearthstone stores game state on the server and client, and it was the first time a replay format was created for hearthstone: https://hearthsim.info/hsreplay/ https://hearthsim.info/hsreplay/ Incidentally the UI we wrote for hearthstone replays is a react app. It’s funny because looking back it was the first time I used react and typescript, and both were not at all adopted by the js community yet at the time. https://github.com/hearthsim/joust https://github.com/hearthsim/joust
- fleabitdev 2y ago
  That's the exact approach I'm considering for the new engine I mentioned! Although that strategy enables you to store and recover the state of a game, it doesn't give you the ability to inspect a snapshot of that state. How can you print the card which has just been played, if that data only exists as an argument in the call stack of a suspended async function? In the same way that you can't inspect the local variables captured by a closure, mainstream languages also provide no way to inspect a suspended stack frame. This problem interferes with debugging, consistency checks (e.g. hashing the game state to check that two clients are in sync), and unit testing.
LudwigNagasena 2y ago
My main pain point with any sort of Flux-like state management is transitions [1]. The state of UI is not fully described by the state of the game [2]. If I play a card, the game state can be instantly updated to the next decison-making point, but in reality I want to show steps of the game through animations, some of which are concurrent and some of which are consecutive. That usually ends up in a mess; and I've never seen someone implement it nicely. [1] And generally dynamic stuff like drag-n-drop, which is infinitely times simpler in any other architecture than in React. [2] That is also true for business apps, but their animations are usually so simple you can simply use CSS.
- semitones 2y ago
  In my experience, the way to solve [1] and [2] is to design a game state that can also _fully_ describe the state of the UI, including animation cues.
- Longwelwind 2y ago
  The way I wanted to implement this in my turn-based game engine: If you implement the deterministic update pattern to handle state synchronisation you can add "event" inside the logic that handles updates that pause the processing allowing your animations to be played. In JS, for example: async function handleUpdate(update) { if (update.type == "sell-items") { this.player.inventory[update.itemId] -= 1; await emitEvent("itemSold"); this.player.money += 10; await emitEvent("moneyGain"); } } Server-side, "emitEvents" would be a no-op. Everything would resolve synchronously. Client-side, the UI can listen to those events to pause the updating of the game state to see the intermediary state of the game and play animations. When the animation is done, it can resolve the promise, resuming the game updating logic. If an update arrives while an update is being handled, it can be queued so it can be played after the current update finishes.
- sjrd 2y ago
  The way I did this was to design a more-or-less monadic container `Result<A>` for all my game logic functions. It batches a sequence of animation steps with a result. It can also model error conditions (like not having enough resources for example). I can then instantiate it any concrete result type, such as a full game state or just the result of individual computations. It was very nice to concisely write complicated game logic with animations while retaining the happy path. https://github.com/sjrd/barrage/blob/main/src/main/scala/be/doeraene/barrage/model/Result.scala https://github.com/sjrd/barrage/blob/main/src/main/scala/be/...
bbminner 2y ago
Yep, that's the exact issue I wanted to address with my own twist on the idea of an online boardgame engine - I was trying to actually persist the callstack of an async wasm vm function (game loop) execution into a database in rust. It is working in a sense that you can implement battle ships or tick tack toe, but I did not quite finish it. Happy to still make repo public if helpful. To be more specific, async wasm function was implemented as a poll loop sync function exported to the caller, there was (at the time) no way to move wasm mv memory, so it was persisted while the game was live and replayed from a message log stored in a db after/if preemption.
Savageman 2y ago
How does secret state fit in this? If you want each player hand to be secret, then each player has its own state?
- fleabitdev 2y ago
  boardgame.io only runs game logic on the server, and it censors the State just before sending it to each client. This strategy makes the UI feel less responsive, but it keeps things simple. The Swords and Ravens blog post recommends resolving actions on the client when they don't require secret information, but resolving other actions on the server. You'd also need to resolve actions on the server when they involve RNG.
  - Savageman 2y ago
    Interesting, would you share the link of this post please?
    - fleabitdev 2y ago
      https://longwelwind.net/blog/networking-turn-based-game/ https://longwelwind.net/blog/networking-turn-based-game/
  - Longwelwind 2y ago
    I don't recommend resolving actions on the server in any situation: For actions that require secret information, you would filter the actions sent to the client of any secret information and make sure the code handling the action can handle both the action and the filtered actins. For actions involving RNG, make all randomness rely on a seed. This seed would be stored server-side and passed along the action when sent to the client. This makes sure the clients can deterministically reproduce the update.
nicolodavis 2y ago
I agree that asynchronous flows are hard to represent using a state object. I chose to go with a monadic approach in boardgamelab.app (I'm not limited by language features since I'm designing it from the ground up for this use case). The language is pure and functional with managed effects. You can express things like: set of cards -> filter by action cards -> choose -> [card] do stuff with [card] written in a synchronous style, while under the hood it: 1. suspends the rule. 2. waits for the user to make a choice. 3. resumes the rule with the choice made by the user. (note: listed above is a simplified text representation. The Boardgame Lab structure editor uses a block-based visual language.) If written in Haskell, the underlying monad would look something like this: {-# LANGUAGE ExistentialQuantification #-} newtype Rule a = Rule {fn :: State -> (RuleResult a, State)} data RuleResult a = Done a | forall x. Show x => Choose [x] (x -> Rule a) instance Monad Rule where m >>= k = Rule $ \state -> case fn m state of (Done a, state') -> fn (k a) state' (Choose list m', state') -> (Choose list (m' >=> k), state') i.e. each rule returns either a completed result or a choice along with a continuation of the remainder of the rule past that choice.

NathanaelRea 2y ago

Can you explain more what type of game would need a call stack snapshot? I've never developed a game, but it seems like as long as you store like the initial state and prng you could always get the current state by replaying the full history. All the other logic would be stored outside the state, and only added when "committed". As long as prng is stable and you start from the clean state every time, you'd get the same outcome.

yojo 2y ago
I think I have a good example from Magic: the Gathering. There’s a card called “Fact or Fiction”. You reveal the top five cards of your deck. Then your opponent splits the cards into two piles. Then you pick one of the two piles to take into your hand. You’ll need to store structures representing the choices that are intermediary steps (split cards, pick stack) in your state, which is basically function calls and their params (a call stack). This example could get hairier - Magic also features cards with branching logic “choose 1: do a or b”. I can imagine designing cards with large and convoluted possible execution paths. You could have the card define a schema for state transitions/params and represent all these choices as JSON encoded POJOs, but as a developer it sounds a lot nicer to just be able to suspend an async function every time a choice is made.
- Longwelwind 2y ago
  I had the same issue in AGoT:BG and I solved it by representing the state of the game as a tree. At any point of the game, the current game state is a leaf of the tree. You'd represent this kind of choice as a child node. When the user has made their choice, the code can return to the parent node with the choice being made so it can continue with the next "step" of the game.
  - scrollaway 2y ago
    This is the correct response. Hearthstone is structured like this internally. If you are curious about it, I wrote a cc0 spec which stores hearthstone game state in xml. It’s based on how hearthstone stores game state on the server and client, and it was the first time a replay format was created for hearthstone: https://hearthsim.info/hsreplay/ https://hearthsim.info/hsreplay/ Incidentally the UI we wrote for hearthstone replays is a react app. It’s funny because looking back it was the first time I used react and typescript, and both were not at all adopted by the js community yet at the time. https://github.com/hearthsim/joust https://github.com/hearthsim/joust
fleabitdev 2y ago
That's the exact approach I'm considering for the new engine I mentioned! Although that strategy enables you to store and recover the state of a game, it doesn't give you the ability to inspect a snapshot of that state. How can you print the card which has just been played, if that data only exists as an argument in the call stack of a suspended async function? In the same way that you can't inspect the local variables captured by a closure, mainstream languages also provide no way to inspect a suspended stack frame. This problem interferes with debugging, consistency checks (e.g. hashing the game state to check that two clients are in sync), and unit testing.

LudwigNagasena 2y ago

My main pain point with any sort of Flux-like state management is transitions [1]. The state of UI is not fully described by the state of the game [2]. If I play a card, the game state can be instantly updated to the next decison-making point, but in reality I want to show steps of the game through animations, some of which are concurrent and some of which are consecutive. That usually ends up in a mess; and I've never seen someone implement it nicely. [1] And generally dynamic stuff like drag-n-drop, which is infinitely times simpler in any other architecture than in React. [2] That is also true for business apps, but their animations are usually so simple you can simply use CSS.

semitones 2y ago
In my experience, the way to solve [1] and [2] is to design a game state that can also _fully_ describe the state of the UI, including animation cues.
Longwelwind 2y ago
The way I wanted to implement this in my turn-based game engine: If you implement the deterministic update pattern to handle state synchronisation you can add "event" inside the logic that handles updates that pause the processing allowing your animations to be played. In JS, for example: async function handleUpdate(update) { if (update.type == "sell-items") { this.player.inventory[update.itemId] -= 1; await emitEvent("itemSold"); this.player.money += 10; await emitEvent("moneyGain"); } } Server-side, "emitEvents" would be a no-op. Everything would resolve synchronously. Client-side, the UI can listen to those events to pause the updating of the game state to see the intermediary state of the game and play animations. When the animation is done, it can resolve the promise, resuming the game updating logic. If an update arrives while an update is being handled, it can be queued so it can be played after the current update finishes.
sjrd 2y ago
The way I did this was to design a more-or-less monadic container `Result<A>` for all my game logic functions. It batches a sequence of animation steps with a result. It can also model error conditions (like not having enough resources for example). I can then instantiate it any concrete result type, such as a full game state or just the result of individual computations. It was very nice to concisely write complicated game logic with animations while retaining the happy path. https://github.com/sjrd/barrage/blob/main/src/main/scala/be/doeraene/barrage/model/Result.scala https://github.com/sjrd/barrage/blob/main/src/main/scala/be/...

bbminner 2y ago

Yep, that's the exact issue I wanted to address with my own twist on the idea of an online boardgame engine - I was trying to actually persist the callstack of an async wasm vm function (game loop) execution into a database in rust. It is working in a sense that you can implement battle ships or tick tack toe, but I did not quite finish it. Happy to still make repo public if helpful. To be more specific, async wasm function was implemented as a poll loop sync function exported to the caller, there was (at the time) no way to move wasm mv memory, so it was persisted while the game was live and replayed from a message log stored in a db after/if preemption.

Savageman 2y ago

How does secret state fit in this? If you want each player hand to be secret, then each player has its own state?

fleabitdev 2y ago
boardgame.io only runs game logic on the server, and it censors the State just before sending it to each client. This strategy makes the UI feel less responsive, but it keeps things simple. The Swords and Ravens blog post recommends resolving actions on the client when they don't require secret information, but resolving other actions on the server. You'd also need to resolve actions on the server when they involve RNG.
- Savageman 2y ago
  Interesting, would you share the link of this post please?
  - fleabitdev 2y ago
    https://longwelwind.net/blog/networking-turn-based-game/ https://longwelwind.net/blog/networking-turn-based-game/
- Longwelwind 2y ago
  I don't recommend resolving actions on the server in any situation: For actions that require secret information, you would filter the actions sent to the client of any secret information and make sure the code handling the action can handle both the action and the filtered actins. For actions involving RNG, make all randomness rely on a seed. This seed would be stored server-side and passed along the action when sent to the client. This makes sure the clients can deterministically reproduce the update.

nicolodavis 2y ago

I agree that asynchronous flows are hard to represent using a state object. I chose to go with a monadic approach in boardgamelab.app (I'm not limited by language features since I'm designing it from the ground up for this use case). The language is pure and functional with managed effects. You can express things like: set of cards -> filter by action cards -> choose -> [card] do stuff with [card] written in a synchronous style, while under the hood it: 1. suspends the rule. 2. waits for the user to make a choice. 3. resumes the rule with the choice made by the user. (note: listed above is a simplified text representation. The Boardgame Lab structure editor uses a block-based visual language.) If written in Haskell, the underlying monad would look something like this: {-# LANGUAGE ExistentialQuantification #-} newtype Rule a = Rule {fn :: State -> (RuleResult a, State)} data RuleResult a = Done a | forall x. Show x => Choose [x] (x -> Rule a) instance Monad Rule where m >>= k = Rule $ \state -> case fn m state of (Done a, state') -> fn (k a) state' (Choose list m', state') -> (Choose list (m' >=> k), state') i.e. each rule returns either a completed result or a choice along with a continuation of the remainder of the rule past that choice.