Hi everyone, thanks again for the discussion and for really useful feedback all around.
I’d love to move forward with @Jon_Ko ’s offer for the implementation. If the mechanics work out, i would like to name this variant Rizoma.(The name Rizoma comes from Deleuze and Guattari’s concept of the rhizome — a system where separate elements influence each other with no fixed center. Each board is its own game, but resources flow between them horizontally…The name seemed to fit )
Here is the refined logic for the test, but over to you to see if it can work…
Two or more boards played by two players — boards can be the same size or of different sizes.
Each turn, a player places one stone on any board of their choice
Capture Transfer: After a capture, the capturing player may choose to keep the stones as prisoners for scoring, or redeploy them as bonus moves on any other board - excluding the one where the capture occurred. Redeployed stones are played in the capturing player’s own color and are not added to the prisoner count. For example: if Black captures 3 White stones, Black may place 3 Black stones on another board instead of scoring them as prisoners.
Dynamic Komi (new): To balance the first-move advantage, komi for each board is assigned to the second player to place a stone on that specific board. This avoids a fixed komi calculation and lets the balance emerge from the structure of play itself.
UI nice-to-have: Navigation links or shortcuts between the boards of the same match to help with orientation. And a Global Score Tracker: A way to see the combined score/prisoner count across all active domains.
I’d suggest starting with two boards to keep the first tests manageable. I’m also happy to help with the implementation where I can, though my technical knowledge is limited.
I’d be interested in playtesting if the timing works out.
It reads to me just like “Bughouse Go”
Well, to fully match bughouse the way I’ve played it, you’d have partners each playing a board, one black and one white. When black captures white stones they go to his partner on the other board who can choose to deploy them.
These rules can create weird dynamics with the timer which do not occur under OP’s idea of one player choosing to play on any board. So in some ways these rules are superior to bughouse. I do like, aesthetically, the idea of the captured stones being re-deployed without having to change color, which is possible if the game has two boards and the players control opposite color stones on each.
Thanks for the interest in playtesting!
The color idea is aesthetically appealing for two boards, but the way I originally designed this variant should scale to multiple boards.. 2, 3 or more, also of different sizes. In practical terms, and without technological support, your solution is definitely more manageable. But in an online implementation, keeping the same color across all boards maintains consistency for each player regardless of how many boards are in play.
Yes this makes sense. There is something to be said for what the computer makes possible, in addition to how faithfully the computer can imitate reality.
@Jon_Ko — noted, and apologies for the misunderstanding. Any help is much appreciated. I’ve had a look around the site and it’s a great work. Honestly I’m more comfortable with low-code and don’t have much experience with hardcoding or GitHub. With a bit of AI assistance I’m hoping I can manage. If you have any documentation to point me to, or any advice on where to start, any kind of guidance is welcome.
Okay, the first goals to achieve would be to either get the demo page running or the automated tests for the shared package. After that I’d suggest to create either a simple variant that just includes the redeployment of captured stones or a board that consists of multiple grid boards.
But maybe you don’t want to discuss all that in this thread, to keep it more about the variant itself and less about the implementation?
If you’re not familiar with code/github, it will be more of a challenge, but happy to help walk you through it. (If you’re already chatting 1:1 w/ @Jon_Ko then you’re in good hands )
Quick update: I’ve been working with Claude and actually managed to get a working version going. If the AI keeps helping me out, it should be up on GitHub tomorrow evening (CEST).
A couple of things came up during testing:
I’ve included a 0.5 global komi for White (adjustable like dynamic komi) specifically to avoid draws across the boards.
There’s an interesting consequence of the rules regarding captures: if you use a captured stone to trigger a new capture on another board, that stone ‘freezes’ in place, but the original board where the first capture happened becomes available for play again.
Boards follow a simple freeze rule: after a capture, that board becomes unavailable for play. However, if you take one or more captured stones and reallocate them to a different board — triggering a new capture there — the freeze transfers: the new board locks, and previously frozen board (including the one where the original capture happened) become available again.
In short: only the board where the most recent capture occurred is frozen at any given time.
It is an interesting concept and I agree any redeployment should be legal. Also redeployment seems incredibly strong and chaining captures potentially game breaking making the game too unpredictable or requiring extremely conservative strategies.
An alternative could be limiting redeployements such as only one redeployed stone per turn.
This could be implemented in different ways:
For each captured group you can either save the points or redeploy a single stone that turn
For each captured group you save the points or redeploy all stones one each turn.
I think this better balances both options and, makes you consider whether is more important the current points or the benefits of a single stone or (multiple in future turns).
Also I don’t think you really need to change colors, can’t you play each board with a different color? then the captured stones are already correspond to the other board. Maybe you can force alternate play, P(player)1 plays b(black) In B1 (board), then P2 plays b in B2, P1 w in B2, P2 w in B1 and so on just with the additional captured stones placement in between.
On the first point (the risk that redeployment becomes too strong or unpredictable): maybe we can assess this better in playtesting. The board freeze mechanic should prevent — or at least I hope limit — the snowball effect, because it stops you from immediately redeploying captured stones on the same board where they were captured. Whether that’s enough remains to be seen, but I think it’s testable.
On the second point (changing colors per board): I’m keeping in mind that we could potentially use up to 5 different boards, also of different sizes. In that scenario, keeping the same color for each player across all boards would help avoid confusion. Also, I’m leaving open the possibility of a future modification where more than two players could play in the same game (though that would need its own rules). In that case, rotating colors per board would become unmanageable. Of course, we would then need to figure out how the disadvantage of playing third, fourth, etc. might impact the game — but that’s a separate discussion.
Thanks to everyone who contributed feedback in this thread — the variant has been implemented and is now available to play on govariants.com.
**How to play:**
Create a new game, select Rizoma from the variant list, and configure the number of boards, their sizes, and komi settings.
**Rules:**
Two or more boards are played simultaneously by two players. Boards can be the same size or different sizes. Each turn, a player places one stone on any board of their choice. Standard Go rules apply on each board independently, including the ko rule.
**Capture Transfer:** After capturing stones, the capturing player faces a choice — keep the captured stones as prisoners for end-game scoring, or redeploy them as bonus moves on any other board, excluding the board where the capture occurred. Redeployed stones are played in the capturing player’s own color and are not counted as prisoners.
**Dynamic Komi:** The second player to place a stone on each board receives that board’s komi. This rewards the player who responds on a new front rather than opening it.
**Global Komi:** An optional global komi can be assigned to White at game setup. Recommended when playing with an even number of boards to prevent draws.
**Scoring:** Territory is counted across all boards and summed. Dynamic komi is added per board. Global komi is added to White’s total. The player with the highest total wins.
)