You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the app allows board setup to take place only at the beginning of the game. This restriction needs to be lifted if the app wants to be a proper SGF editor with full variation support. Also a future tsumego mode likely requires board setup at various stages in the tree of nodes because it's reasonable to assume that Go problems are modeled with variations.
A rough sketch of the requirements:
The user should be able to change the following things in any board position:
Which side plays next
Remove existing black or white stones
Place new black or white stones
When any of these things is changed, any future moves that still exist must be discarded.
The new board position must be legal
Stone groups with no liberties are not legal.
After placing or removing a stone the new board position must satisfy the Ko rules of the current game.
The text was updated successfully, but these errors were encountered:
The major problem with implementing this feature is that Fuego only supports stone setup on an empty board. For instance, the GTP command gogui-setup B A1 on a non-empty board fails with the error message "setup only allowed on empty board". Setting up a different side to play next (GTP command gogui-setup_player) is fine, though.
Brain dump of some notes that I took for implementing this:
Currently GoGame is the model class that stores board setup information. Because there is only one GoGame object the model is currently not capable to have multiple board setups distributed across the tree of nodes.
So the board setup properties in GoGame need to go away. Board setup is instead made available as a sub-object of GoNode, e.g. an instance of a new class GoNodeSetup.
GoNodeSetup must be able to store the information from the SGF properties AB, AW, AE and PL.
Because GoMove is no longer the sole effector of board position changes, the Zobrist hash property must probably be moved from GoMove to GoNode.
The GoNode methods modifyBoard / revertBoard need to apply the board setup to the board.
This includes the "who plays next" information (PL)
For the revert mechanism to work, GoNodeSetup needs to remember which stones of the previous setup were changed, similar to the captured stones recorded in GoMove.
For the modify mechanism see the GoGame method setSetupPoints: which has the mechanism how to place all setup points and then make a liberty check afterwards. A liberty check is not sufficient, though, because Ko needs to be taken into account, too.
The UI needs to be able to step through nodes with setup. Hopefully this works automatically by implementing modifyBoard / revertBoard.
The way how board setup is made in the UI needs to be reworked to a certain extent.
Switching to board setup mode must be possible on any board position
If the current board position contains a move, then changing the board setup creates a new board position, because SGF does not allow move and board setup properties to co-exist in the same node.
If the current board position contains no move, then changing the board setup causes a new GoNodeSetup to be created or an existing GoNodeSetup to be updated.
If all board setup is cleared from a board position then the existing GoNodeSetup is removed.
Regarding the requirement to discard future moves/nodes when board setup changes: It might be possible to go without this, but it would probably require quite complicated handling. Check out q5go, which has replace, append and insert operations for board setup.
Currently the app allows board setup to take place only at the beginning of the game. This restriction needs to be lifted if the app wants to be a proper SGF editor with full variation support. Also a future tsumego mode likely requires board setup at various stages in the tree of nodes because it's reasonable to assume that Go problems are modeled with variations.
A rough sketch of the requirements:
The text was updated successfully, but these errors were encountered: