Open herzbube opened 1 year ago
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:
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.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.GoMove
is no longer the sole effector of board position changes, the Zobrist hash property must probably be moved from GoMove
to GoNode
.GoNode
methods modifyBoard
/ revertBoard
need to apply the board setup to the board.
GoNodeSetup
needs to remember which stones of the previous setup were changed, similar to the captured stones recorded in GoMove
.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.modifyBoard
/ revertBoard
.GoNodeSetup
to be created or an existing GoNodeSetup
to be updated.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: