Euclidean Go

    Keywords: Variant

Table of contents

Euclidian Go is an implementation of Go on a Board Without Lines. It builds on the contributions of Robert Pauli, Karl KnechtelBildstein, &al. on GoOnABoardWithoutLines/Discussion. See also the /discussion page for this page.


This page describes a new perspective for displaying Go on a Board Without Lines and offers a corrected and further simplified version of my earlier rules. I became aware of the necessity when I looked at Bildstein’s pictures. In them, it is quite easy to see where the ghost stones fit. But his groups are very heavy – similar results can be achieved with a wider spacing. This is essential, since we always strive in Go to achieve our desired results with the lightest possible shape. A more loose arrangement, such as shown in the following picture, lends itself much less to at-a-glance analysis.
Does the white stone live? And if so, how many liberties does it have? Judging this is practically impossible without a ghost stone, even when you have – as here – the situation in front of your eyes. And you’d need the help of a stack of ghost stones if you wanted to plan ahead just one move deep.


Let’s therefore shift focus from the physical appearance of a stone to a geometrical view – let’s focus on the center of the stones. Placement of new stones is forbidden if the center falls in the [ext] open disk around the center of our stone. Let’s call this disk a “halo”. (Other possible terms include “shadow”, “coverage”, “range” and “3-mile zone”.)
A [ext] remark, which we will use later to check consistency with Robert Pauli's definition[2]: Two stones touch if one center lies on the other halo’s perimeter. This has no bearing on our rules, however – as a matter of fact, we can do away with the concept of stones altogether. Henceforth, I will use the word “halo” whenever traditional Go uses “stone”.

Although I like the colors black, white and wood, I found it more expedient to use transparent red and blue haloes on a white background and leave out the stone. This picture shows a few typical contact situations:

Basic definitions and Modified Game Rule

(See also [1].)

Let’s define

  • “red halo” as the halo around a red center;
  • “red point” as a point covered and only covered by red halos;
  • “white point” as a point not covered by a halo; and
  • “purple point” as any point that is covered by at least one red and one blue halo.

Note that

  • every halo also can contain the colour purple
  • obviously, all rules, here and later, imply additional rules generated by exchanging "red" and "blue"

This allows us to determine a halo’s life by its perimeter alone according to the following simple rule:

A red halo (and all its red points) lives if at least one point on its perimeter is either

  • white –or-
  • red and alive.

Examples and Applications

Simple Life and Death
In the above picture, the black halo is killed by the four green halos 䝪 its entire perimeter is blue, as shown by the thick purpleblue line.
The additional red halo does not help our beleaguered halo. It tints part of its perimeter purple – but it provides no white or red points anywhere near it.
[13] The relief works, though, if the blue halos are a bit further apart. Now we get a little red arc on the surrounded halo’s perimeter (see arrow).

Solution of our Initial Question

With these rules, we now can answer our initial question. The good news is: The white stone lives. The bad news is: It only has one liberty (arrow). The liberty is tiny, but that doesn’t matter.
The beauty of this display is that it clearly shows that there is no room for any move inside. Iff there were room then it would show some white points.


Is it possible to separate the red stones? Yes – it is. This is just what a crosscut looks like in Euclidian Go.

This may seem counterintuitive, but it’s consistent with Robert Pauli’s definition[2]: The two stones can not touch anymore. Try for instance to move the left one towards the right one – you can’t since there is no allowed place on the perimeter. It seems obvious that any two stones that don't touch are not safely connected, since they can be prevented from touching if the opponent wedges two stones to the left and right of the gap, creating a cross cut.

Alas, this is not true. If there are already stones around then there may be no room for any new stones there. This leads to the truly counterintuitive situation that non-touching stones are only connected if they are surrounded by enemy stones, as seen above[13]. We could avoid this if we allowed moves not only in white points but also in living friendly points.

While a crosscut in traditional Go always forms a square, the angles of a crosscut in Euclidian Go can be anywhere between 60 and 120, as can be shown from the next diagram.

The Liberties of a Free Halo

This arrangement is the borderline case for capturing a stone. Since we defined the halos as open disks, arranging three disks evenly leaves three white points (arrows) on the red halo's perimeter. The red halo lives with three liberties, even though it contains only one red point – its center! This ensures that it takes at least 4 moves to capture a free halo. Thus, a free halo has 4 liberties. The beauty of this is that it encourages WabiSabi (albeit differently from axd’s request). By playing at exact points, Blue wasted two moves!

Life Forms

Let's take a look at Bildstein's Echidna shape. As expected, it contains two separate white areas. which we call eyes.
However, is it really the most economical living shape?

On the search for a smaller living shape I came across the clam, which has only only 6 stones:
Alas, if blue puts a stone in one of the eyes, he can make it overlap the other eye, so there's no place for another blue stone. If we switch to the stone perspective, then the (yellow) ghost stones representing its two eyes overlap. Sadly, the halo view can mislead one to see two eyes where there is only one.

A Peculiar Situation

The following picture illustrates an interesting asymmetric situation: If the red stone to the right were surrounded on its outside (two dashed blue halos), it still could get help from its friend to the left thanks to the part of the perimeter marked by the arrow, which is red. However, the opposite is not true – the left halo’s (right) perimeter is entirely purple. This situation corresponds to Robert Pauli’s definition[2], by which you may be able to move the left stone so it touches the right one, but you can’t move the right one far enough to touch the left one - it is blocked by the two enemy stones. My first reaction was that this is ugly, but I now see its beauty in the spirit of Go: Simple rules that can lead to complex situations.

However, the red connection is not secure. If blue makes a move in the dashed position, he can cut. Conversely, if red moves there, she can connect:

If we move the blue halos even further we obtain the following:
The blue sliver means that it is not possible to slide the right stone so that it touches the left one. But it is possible to lift it up and move it, which is all we need for a connection according to our rules.

[1] I think this definition is not quite what it intends to be, since it mistakenly allows to regard a completely enclosed red dango without any eye as alive. Apparently, the recent discussion took another way, but to my view, it's better to still deal with the term "connected" (which should mean having at least one common red point), and then to apply the "white point" life criteria to the entire connected set.

Another issue is if we shouldn't rather talk of being "breathing" here than of being "alive", since the latter already has at least two other meanings. To clearly distinguish between them verbally is supposed to facilitate future discussions of e. g. life/death problems.


Robert Pauli's definition

  • a stone has liberties if repeatedly removing friendly stones with direct liberties eventually removes it
  • a stone has direct liberties if there is enough space around it to fit a stone touching it (it's of no matter if putting a stone there is legal)

Note that this does without defining connection!

ilan: This seems to be analogous to the Poisson blob model of percolation, in which one places disks of radius 1 randomly in the plane with "intensity" lambda, that is, on average (in a sense to be made precise), there are lambda disk centers per unit area, and one asks what is the probability of a set of overlapping disks going off to infinity. It turns out that there is a critical value of lambda which is about .35 (for values less than this, there is no set going off to infinity with probability one and there is one for lambda bigger).

The standard percolation model would be disks of radius 1/2 but with centers on the points with integer coordinates which corresponds to an infinite connected group on an infinite go board.

Now, the "Poisson" model is the formalization of the first model by considering disks of radius 1/2, but with centers at finer and finer grids (points with coordinates integers divided by N, with N going to infinity). This would correspond to playing go on a normal (infinite) board, but with stones of radius N/2 placed with centers on any normal intersection. This is relevant for "Euclidean Go", it seems.

One important technical note is that two disks of radius R overlap if and only if doubling their radius means that one disk covers the other disk's center. This observation also seems relevant to Euclidean Go.

I have written an exposition of this model and given a number of references in this paper [ext]

Euclidean Go last edited by joukepouk on January 11, 2023 - 17:52
RecentChanges · StartingPoints · About
Edit page ·Search · Related · Page info · Latest diff
[Welcome to Sensei's Library!]
Search position
Page history
Latest page diff
Partner sites:
Go Teaching Ladder
Login / Prefs
Sensei's Library