It’s fixed for me, thank you for deploying!
It works! Thank you!
(The browser was Samsung Internet 23.0.1.1 on Android)
I was curious what the colors mean - it looks like they are more or less inert:
It should be noted that the terms ‘continents’ and ‘oceans’ are purely symbolic labels within the game’s design. They do not directly influence gameplay decisions, similar to the origin and star points in traditional Go.
Separately, I would really like to add surface mesh variant since I’ve been doing more graphics at my day job. However, I think it’s a medium sized project and I haven’t been able to prioritize it yet. Still, I think the space is rich! (Cube go, sphere go, etc)
There should be some mechanic that allows players to travel to a new continent.
From what I understand, since the polyhedron has triangle and pentagon faces, the point of the colours is to make it easier to see the symmetries and locate the pentagons.
I thought it was more about helping one to recognise the different parts of the board despite the symmetry, especially when it is moved around. Perhaps also to get a handle to denote the parts of the board in an discussion.
Hi, I am searching for a Go variant named " Cooperative and Sequential Multiplayer Go" here described http://www.di.fc.ul.pt/~jpn/gv/players.htm have you implemented that? Do you know if this variant is somewhere implemented? Thank you!
I don’t believe we have sequential variants for >2 players, but it should be relatively straightforward to adapt some parts of the parallel variants for a multiplayer sequential variant.
I believe the kahv.io server does have 3 and 4-color sequential Go. Not sure if this implementation is cooperative or non-cooperative
You might want to check out DipGo ! It’s an excellent implementation of diplomatic sequential multiplayer go. However I don’t know if it has points sharing for alliances.
I was skeptical in 2022 as the package manager and ecosystem was non-existent, but the Deno team just put out a really cool announcement for Deno 2. Apparently they’ve now got answers to both! (package manager == jsr, ecosystem == npm compat)
I was thinking about variants with hidden information, like hidden move go, or fog of war chess. How about the following variant idea?
Players don’t know the position of stones unless at fields where they have vision. Stones give their owner vision of adjacent empty fields and extending in a straight line until the line meets another stone.
If a player plays a move at a field that is occupied by a stone (possible if they don’t have vision of this field), then the players stone does not get placed, but they get vision of this field until its stone gets captured.
The first two moves are an exception, the placed stones are visible to both players (to avoid a “collision” on the first move).
Is there interest to try this? Any name ideas?
I’d try it, but I might be annoyed that the variant makes me play kosumis and keimas.
What about illuminating a certain region around the player’s stones?
I thought it would be neat if some far-away points also get “illuminated”, because otherwise I’m concerned that people would be incentivised to play only close to their existing stones. But I like that idea too, we could always make it configurable
Would stones still “cast a shadow” with your idea?
There’s always a drawback, casting a shadow with a circular illumination is harder. Maybe Manhattan distance? That would also allow for different boards.
Dev Log 5
A lot has happened since the last dev log. My personal highlights are:
- Sameer Dalal joined the team and implemented the SGF download feature. They’ve also created a Bot for Quantum Go and are currently working on implementing a rating points system. Welcome and thank you Sameer!
- After much technical discussion, we came up with a way to make the new board patterns freely combinable with compatible variants. Just to name a few: Capture, Tetris, Freeze etc. can now be played on the graph boards. Future variant implementations can also use these boards relatively easily!
- A lot of work went into Time control handling. We support various systems now: Absolute, Byo-Yomi, Fischer, Canadian, Simple
- We’ve changed the client - server communication used in the Games view. The client doesn’t have access to all moves anymore, which allows us to make secure hidden information games in future.
Screenshots
The following is a non exhaustive list of changes.
Features and Improvements
Star Points | 183 314 |
Time Control | 185 196 215 203 227 228 229 |
Trihexagonal board | 186 |
Quantum Go | 202 |
Navbar for mobile | 209 |
Sierpinsky Triangle board | 213 |
Byo-Yomi, Canadian and Simple Time Control | 223 |
Error boundary for games list | 237 |
Variant Demo board | 249 |
Graph boards for Baduk and inheriting variants | 255 256 258 259 |
Grid with holes board | 262 |
SGF Download | 273 280 283 288 |
Sequential Fractional | 298 |
Player symbol | 299 |
Upcoming moves | 308 |
Multicolor score marks | 310 |
Maintainance and Refactoring
Dedup time handlers | 227 |
Cleanup clock component | 228 |
Time control test cases | 229 234 |
CORS | 235 |
Config validation | 236 |
Script for variant creation | 239 |
Hot reload | 240 |
Update package versions | 252 |
Remove cypress | 253 |
Send state via API | 267 |
Variant map | 284 |
Sanitize config | 309 |
Style lint rule | 311 |
Bugfixes
For me personally, capture previews are low priority. It would be fine to display an additional stone, and the rest stays the same.
If this adds functionality to the board, it might be worthwhile to first migrate fractional s.t. it uses the DefaultBoard.
I am trying to understand the rules of the quantum variant. I noticed that if I capture one of the first two special entangled stones, a green spot is left where the captured stone used to be. And if I try to place a stone on the green spot in a subsequent move, I get an error saying there is an existing stone there. Do the first two moves permanently reserve those spots for their respective colors?
For example, from this position
Black captures the white stones in the bottom left
Now black cannot place stones in the green spots, but white still can.
Thank you for trying out the Quantum variant! This is a bug that we are going to fix, thank you for bringing our attention to it.
It should be such that the green part is also removed, and stones can be placed at this position afterwards.
//Edit: fixed
Thanks for the report @doh, and thanks for the fix @martin3141!
This may be a separate bug. A workaround you can try is to click the corresponding stone on the left board (the bottom left 3-3).
I believe the issue is that we don’t remap the quantum coordinates from the right-side board correctly.