This should be in a good place to port stuff over from rules, but I wanted to get this in front of people first.
This should be a complete implementation of Go rules (unless I forgot something?)
Capturing
Suicide
Ko
The main differences between the rules implementation are:
Separate board representation from game representation: This is important because when directly editing a board during reviews, game logic is circumvented. In other words, you can add or remove stones illegally. It also allows for separation of concerns for easier testing. The general logic is relatively similar to the rules implementation.
More efficient board representation: The old implementation used individual stone structs to represent the board state. This essentially meant that many operations required traversal over sets of stones to determine stone existence, rather than being able to directly check the existence of a stone at a position in O(1) time. This represents the board state in an array for constant time lookups of stone state, and stones/stone strings as indexes into that array.
Additionally, in the rules implementation, the model is tightly wired to the board state. In fact, we're storing individual moves as DB rows it seems. This will quickly become unscalable, and is probably unnecessary, as there's no reason to query the database directly for subsets of moves. Games can be serialized when stored to the database (SGF is actually a serialization format that can be used directly, or we can roll our own), and deserialized into the in-memory representation when read.
Things to review:
Game logic may be busted in some ways that I didn't notice
The tests should be fairly complete but I probably missed some edge cases which still may not work.
Misc Changes:
Added testify as a dependency for easier assertions in tests.
This should be in a good place to port stuff over from rules, but I wanted to get this in front of people first.
This should be a complete implementation of Go rules (unless I forgot something?)
The main differences between the rules implementation are:
Separate board representation from game representation: This is important because when directly editing a board during reviews, game logic is circumvented. In other words, you can add or remove stones illegally. It also allows for separation of concerns for easier testing. The general logic is relatively similar to the rules implementation.
More efficient board representation: The old implementation used individual stone structs to represent the board state. This essentially meant that many operations required traversal over sets of stones to determine stone existence, rather than being able to directly check the existence of a stone at a position in O(1) time. This represents the board state in an array for constant time lookups of stone state, and stones/stone strings as indexes into that array.
Additionally, in the rules implementation, the model is tightly wired to the board state. In fact, we're storing individual moves as DB rows it seems. This will quickly become unscalable, and is probably unnecessary, as there's no reason to query the database directly for subsets of moves. Games can be serialized when stored to the database (SGF is actually a serialization format that can be used directly, or we can roll our own), and deserialized into the in-memory representation when read.
Things to review:
Game logic may be busted in some ways that I didn't notice
The tests should be fairly complete but I probably missed some edge cases which still may not work.
Misc Changes: