We have developed a XiStrat™ Go variant. Because the task of rendering stones placed on a boundary probably wouldn't be well-defined (see the section called “Calculus of Variations”), and anyway since we appreciate a uniform codebase for our game framework, we decided to have the stones sitting inside the faces (and not on the vertices). This may need some time of accomodation for experienced Go players, but from a mathematical point of view it's just using the dual graph and no principal difference.

In the game Go, one can see much more 'sente' when played on a triangle board, whereas for example on hexagons there are plenty of initial liberties.

We prefer the Japanese rules (at the moment, leaving some subtle bestiaries out for now, that is to say counting territory, prisoners and taking Komi into account). It is aesthetically appealing, because (under area scoring such as for example Chinese rules) unnecessarily placing a stone inside one's own safe territory is not punished, whereas it's an indication that maybe the player is not sure about the state of affairs. Supporting such slack play throws away a possibility to distinguish the level of play. But perhaps s.th. like the Tromp-Taylor set of rules would be easier to deal with from a mathematical point of view.

The stones can be put in the standard way (in the GUI keep the SHIFT key pressed and select the desired location with a left mouse click).

After all parties pass in a row, the game is over. Then dead stones must be removed by all players (again using the SHIFT key and a left mouse click), then all players pass again, and finally somebody has won (the removing phase of dead groups could be avoided once we can have the declaration been done by the computer).

In Figure 3.6, “Go on Hexa Tor” we can see a 2-players game on a marble 'Hexa Tor' graph.

Figure 3.6. Go on Hexa Tor

Go on a marble board (in mirror view)

Below you can watch an ongoing simple Ko fight (Figure 3.7, “Ko on a boundary”). An immediate recapture is not allowed as indicated by the black square surrounding the red stone.

Figure 3.7. Ko on a boundary

Ko fight on a quad-hex graph

Figure 3.8. 2-stage Ko 0

2-stage Ko fight on a dode_tor_6 graph (initial situation)

After the first capture by the red stone (Figure 3.9, “2-stage Ko I”).

Figure 3.9. 2-stage Ko I

2-stage Ko fight on a dode_tor_6 graph (after the first capture)

Then black plays a Ko threat somewhere else on the board. Red could answer this, then black would perhaps recapture. But the red party decides to ignore it, and the situation looks like Figure 3.10, “2-stage Ko II”.

Figure 3.10. 2-stage Ko II

2-stage Ko fight on a dode_tor_6 graph (after first Ko threat)

Red has taken the second Ko (Figure 3.11, “2-stage Ko III”).

Figure 3.11. 2-stage Ko III

2-stage Ko fight on a dode_tor_6 graph (after taking the second Ko by red)

Black now plays another Ko threat somewhere on the board, and this time red answers there (instead he could connect). Black can now recapture the Ko (see Figure 3.12, “2-stage Ko IV”).

Figure 3.12. 2-stage Ko IV

2-stage Ko fight on a dode_tor_6 graph (after retaking the second Ko by black)

Black ignores a red Ko threat and takes the initial Ko (see Figure 3.13, “2-stage Ko V”).

Figure 3.13. 2-stage Ko V

2-stage Ko fight on a dode_tor_6 graph (after second retaking by black)

Here we see a match with three parties involved. The black and red players seem to cooperate, at least they have decided to remove (in alliance) a blue stone from the board Figure 3.14, “Go 3 players”:

Figure 3.14. Go 3 players

Go as a multi-player game (three parties)

Finally we finish our sight seeing tour and watch a wild fight between two random engines on a quasicrystal (Figure 3.15, “Random Go”).

Figure 3.15. Random Go

random Go on a quasicrystal graph