Original creator of boardgame.io here. A pleasant surprise to see this here after many years.
More recently, I've been working on https://boardgamelab.app/, which uses a visual programming language to model game rules while also taking care of the UI layer.
I feel like saying that is supports AI players, but not having a simple, already hosted example is a disservice. Even tic tac toe, or go fish would be a nice hook to help people understand what it actually delivers.
Oh, thank you. I've used your library a few times for personal projects, and it does exactly the thing that I needed. I really appreciate you having created this.
Omg! I've been noodling about making my word game https://WordGlyph.xyz multi player and been dreading that journey but now here it is!
> More recently, I've been working on https://boardgamelab.app/, which uses a visual programming language to model game rules while also taking care of the UI layer.
Suppose there were a technology that could turn the canvas you authored into finished, consistent art; and a way to turn natural language rules into correct code. Would you use it? Why or why not?
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/).
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.
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.
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");
}
}
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.
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.
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.
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.
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.
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.
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.
10 months ago, there was also Boardzilla (https://www.boardzilla.io/) posted here: https://news.ycombinator.com/item?id=39180953 . Curious to see how these two compare
Looks like it might originally have been from Google based on this discussion
The original author looks to have been at Google till 2020.
boardgame.io was created as a personal open-source project while I was employed at Google. It is not an official Google product.
Is there a simple demo that one can test? I see a tutorial about tic tac toe, but the result doesn't seem to be hosted anywhere.
The tutorial page[1] has a link to open an interactive sandbox with a TicTacToe example. The link is titled "Edit in CodeSandbox".
I tried to use this before, but many parts didn't really work right, lots of conflict between dependencies, especially the server parts. I had to abandon what I wanted to do with it. Shame because many ideas were interesting, but felt it was a bit untested.
Looks very interesting.
Somewhat related: I've recently wrote a code-walkthrough (in Clojure) of modeling chess-like games.
https://neuroning.com/boardgames-exercise/
It's very basic and intended for teaching/learning functional programming, not a real library or engine like the OP.
It's really cool that it has a MCTS bot built-in!
Get a daily email with the the top stories from Hacker News. No spam, unsubscribe at any time.