11–20 of 69 posts
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.
Then what, print it out to play on the kitchen table?
Put the screen on the kitchen table and sit around it, call it CounterTop Surface, have a little imagination man.
It's easy to overlook rules that a computerized game automatically handles for you, though. For example, I'm part of a group that plays Heat ( https://boardgamearena.com/gamepanel?game=heat ) every week. An important part of that game is moving the game-controlled cars, and since the platform handles that, only one person in the group. This is potentially quite bad for strategy, depending on the rules you don't know. Another issue that comes up in the same game is people losing track of the size of their deck. The game is very generous about the allowable timing of deck-manipulation effects, but if you're not actively paying attention you can draw through your deck and trigger a reshuffle, wiping out your discard pile, when you wanted to do something special before the reshuffle. This isn't a mistake it's possible to make while using a physical 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.
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.
Do you have any plans for the business model?
Then what, print it out to play on the kitchen table?
Put the screen on the kitchen table and sit around it, call it CounterTop Surface, have a little imagination man.
I've been playing around with writing my own turn-based game engine with TypeScript: https://github.com/snowbillr/turn-based-game-engine
It's a WIP still, but what's really been the struggle for me is coming up with a data structure and traversal algorithm for the turn order. I wanted that to be extremely configurable by whoever uses the library.
```
engine.defineFlow((f) => {
f.node({
actions: f.actions(WelcomeMessage),
})
f.node(
{
actions: f.actions(RoundStart),
cleanups: f.cleanups(RoundEnd, TestLog),
},
players.map(player => f.node({
playerId: player.id,
actions: f.actions(TurnStart),
cleanups: f.cleanups(TurnEnd),
})),
)```
This example shows a TicTacToe game defined like this:
```
- welcome
- round
- player 1 turn
- player 2 turn
What I ended up with was essentially a tree that's traversed depth-first to enter each node, and then goes back up the same traversal path until a sibling node is found to dive into.
That lets the user define rounds/turns/phases as children of each other in whatever shape they want.
It's been a real fun project!
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/netw…
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/netw…
[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.
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.
The boardgamelab.app looks like a stealth, proprietary project; at least at the moment its T&C[1] says: "under this license you may not (...) use the materials for any commercial purpose, or for any public display (commercial or non-commercial)". Do you have any plans for the business model? [1]: https://boardgamelab.app/terms-and-conditions