Go On ABoard Without Lines/ Discussion

Table of contents proposal for an easy implementation Ko rule Definition using Removing Friendly Stones Other Stone Shapes [991] ongoing game Wall-based rules, pixelation

Table of diagrams Self-capture Regular capture It's just not Go If you could connect without touching Living with 6 stones Unforgiving diagram Stone shape The white cannot touch The two white can reach each other

Zahlman: Something similar has been done under the name "Open Go", IIRC on a circular play field.

starline: I like the idea of playing this over the internet using clients. I think that if the time limits were set to fast, that it would be a good test of reflexes and judgement - like an arcade game.

DougRidgway: A website describing Open Go and other continuous variants: http://www.di.fc.ul.pt/~jpn/gv/boards.htm . I think of this as "off-lattice go".

Bildstein: Thanks, Doug. I Googled "Open Go" after Zahlman's comment but found nothing.
I believe the Go described on this page has aspects similar to each of "Free Placement Go" (square board), "Open Go" (scoring), and "Continuous Go" (connection).
I think Open Go is actually only a half-baked idea - the definition above shows that ko can be well defined, and there is no definition of connection, i.e. why is capture of a single stone possible in 3 and not in 4?

Rubyflame: One potential problem with these rules is self-capture. Two stones are only connected if they are actually touching, so if a white stone is placed next to another white stone such that they are not quite touching, the two stones are separate groups with three liberties each. Here's an example:

Self-capture  

You'd think that after , white could play to save his two stones. But suppose that the distance between the two marked white stones is slightly more than the width of a stone.

If is placed in contact with the right stone, then the two stones on the left lose their last liberty, and are captured. cannot be placed in contact with the left stone, because that would be suicide.

I'm not sure how the rules can be rewritten to fix this problem. One possibility would be to consider two stones to be connected as long as the distance between them is less than, say, two millimeters. Any thoughts?

Bildstein: I'd considered this long and hard, and in some variants, stones are connected if they are closer to each other than the stones trying to cut them. But this situation is covered in my rules under "Suicide", and I think this is satisfactory. Under these rules, the onus is on White to make sure that the two white stones are close enough that another stone can be placed between them. In this situation, however, Black has placed his stones in such a way that the White stones are alive but no stone can be placed in the gap without killing White, but this is incredibly unlikely in a game - Why not play a bit closer and actually capture White?

Rubyflame: You say: Under these rules, the onus is on White to make sure that the two white stones are close enough that another stone can be placed between them.

Do you realize that this may be physically impossible? Either the stones are slightly too close together and nothing can fit between them, or they are slightly too far apart and they cannot be connected with a third stone touching both, or they will be jostled slightly to make room for the new stone.

Bildstein: Yes. In your example, both players were trying to ride the edge of what's possible. To avoid this problem in a game, when are placed, White would want to make sure they are slightly closer together than they strictly have to be to fit a stone between them, and hence if he needs to play a stone to connect them, it will have to be slightly above or slightly below the middle for it to fit. This also means that Black can cut White by playing on both sides, but that is similar to the following situation from regular Go:

Regular capture  

Both are needed to cut and capture .

Zahlman: Reading all that, I'm inclined to side with the view that non-touching stones be considered 'connected' as appropriate - it seems more stable. I propose:

• A set of stones (normal mathematical meaning of 'set') of the same colour is captured iff there is no way to place a stone touching one or more members of the set;
• A string is a set of stones of the same colour, such that no proper subset can be captured (by the above definition) without capturing the entire set;
• A play which results in any of one's own stones being captured, after removing opposing stones captured by the play, is illegal.

Bildstein: Consider the following diagram:

It's just not Go  

Under your suggested rules, which two stones in this diagram are connected? The obvious answer is that this position is unlikely to the point of being impossible, and in reality either Black or White is connected, but I think it shows that the rules you suggest are just too different from regular Go.

KarlKnechtel: Hmm? None are connected, since any single stone can be captured. Although it seems now that a single stone could _always_ be captured by those rules. Unfortunately, any attempt to clear that up gets recursive, and I don't really see how to make things clear. :s

Bildstein: Let me clarify: Under my rules, and the rules of Go, none are connected; Under Zahlman's rule, either Black or White are connected (depending on where the slight variations in the position lie), which is just too different from Go for me to be happy with. As a side note, and I might move this elsewhere in this page, you are right that any single stone can always be captured under my rules, but that is the same in regular Go. The rule-of-thumb for life is that every stone in a group must be connected (not touching, just connected) to both of the eyes of the group, for the whole group to be alive (this even covers false eye life).

I reiterate here that, like this diagram, Rubyflame's original diagram was also a special case to the point of it being impossible, and that only the slightest variation would have been needed in the play of the White stones to stop it from occurring.

I also think I should point out that my choice of rules was in some way guided by the principal that the statement of each rule should be a valid statement of an actual rule of Go.

GoStone: One way to solve the connection problem: Two stones are connected if the distance between them is < sqrt(2)-1 (in units of the stone's diameter). This is the distance between stones of the same colour in an ordinary cross-cut, and so it provides the maximum amount of flexibility that is entirely consistent with the rules of normal Go. This would be a more forgiving game than when touching connections are required, and would be easier to play without losing any subtlety. It would be simpler to automate too, as the 'client' program could easily show a line connecting all stones within the distance.

Bildstein: I agree that your equation maintains consistency with normal Go, in that stones that are connected in regular Go will be connected here, and stones that aren't connected in regular Go won't be here. The only reason I don't like your suggestion is that it feels further from normal Go than my rule, to me at least.

However, I wanted to ask what you meant by "providing the maximum amount of flexibility" and "a more forgiving game"? Also, how would the program showing a line connecting all stones within this distance be simpler than if stones had to touch to be connected?

If you could connect without touching  

GoStone Here are some explanations of my terms. (I don't understand your diagram, btw).

Bildstein: Thanks for your explanations of these things. I think I understand what you mean now. My diagram was meant to give an example of how counter-intuitive your rule could be. I think under your rule the Black group is unconditionally alive.

GoStone: Ah, I see what you are getting at now. But it is difficult to draw realistic diagrams for this game using the SL diagram tools, and the diagram as you have actually drawn it does not show any connected black stones at all. They have to be less than sqrt(2)-1 as I'm sure you appreciate. So I'm not absolutely sure that your diagram closely approximates a situation where the black stones could all be connected and have eyes. It may be so, I'm not sure. I actually doubt it. Whatever. It isn't really an argument for either set of rules.

Flexibility: the number of options available to the player. In other words there are more places you can play while keeping your stones connected. This rule maximises available play-space while still keeping within the rules of normal Go.

Bildstein: I can't argue with this - it is self evident that under your rule it is easier to keep stones connected. I just think it will make it too easy to make a live group, but that said, my rule might make it harder than in normal go (although I don't think so, because even with my rule, it takes less stones to make a live group than in normal Go). Here is a diagram of an unconditionally alive group under your rule:

Living with 6 stones  

GoStone again the SL diagrams aren't up to it, but this diagram does come close to a live group by my rules. All the pieces would have to be moved slightly closer together, except for a couple of gaps to allow a large enough eye-space. I hope you can see what I mean :-) I wonder what the minimum 'allowed gap between connected stones' could be to still permit this living group. I don't know if it would be too easy to form a live group, or not. They would have to be placed quite exactly to use so few stones.

Forgiving: The exact placement of the stones (to the nth decimal place) becomes less important. Using your preferred rule of touching-connectedness, moving the stone a tiny distance away from touching disconnects it. This then impacts further situations like this diagram, where the exact position of white's move is critical, if white is to take advantage of the aji of the marked stones.

Unforgiving diagram  

If the move is too close to the marked stones there is no room for another stone and the marked stones would presumably be captured (very unnormal behaviour). If the move is too far away there is no way to connect to the marked stones, so they are also dead. The move would have to at exactly distance 1, which is too unforgiving. The focus changes from grand strategy to calculating exact positions.

Bildstein: (under my rules...) I believe in your diagram were placed just so as to make it virtually impossible for to be useful. By placing slightly closer together, W would already be dead, and I can't see why Black would not want to do that. By placing slightly further apart, could (without needing to worry about infinitesimals) be placed so as to threaten connection. See also my response to your next comment regarding accuracy.

GoStone: Actually the pieces were placed like that because that is all the SL diagrams allow :-) But yes, it also shows an extreme case of the problem with your rules. Why might black play the stones as he has done? Simple. To allow himself to connect by laying a stone between them. If he puts them further apart he won't be able to connect in one move (or at all with the stone any where close to where it currently is). And if he places them closer together stops them connecting. It would be a very realistic example if the pieces had more liberties and it was some kind of semeai.

Automation: A mouse-driven client shows a stone hovering over the board as a mouse-pointer. Now how is a player going to be sure his stone is touching? If he moves the pointer one pixel too close it overlaps the neighbour and the move isn't allowed. But if he moves it one pixel the other way it isn't touching. For that matter, what degree of accuracy are you going to require for touchingness? The mouse position has a discrete value made of two integers, not real numbers. It all starts to seem rather arbitrary in its unforgivingness.

Bildstein: I never even considered the sort of mouse-driver client you're suggesting. If stones have to be touching to be connected, then the user will have to specify something like:

• Place this stone where I click
• Place this stone as close to where I click as possible, while still touching this other stone and not overlapping it (in which case the software will remember that they are touching)
• Place this stone as close to where I click as possible, while still touching both of these other stones (in which case the software will remember that the three stones are conected)
• etc.

In fact, I think even under your rule, it would be convenient to do something like this, to maximise the distance between stones while maintaining connection.

GoStone: It's possible such a facility would be useful in my rules, but it wouldn't be necessary the way it is with your rules. You could have a client very similar to the ones we are familiar with (Jago, CGoban etc), where as soon as the pointer-stone gets within connection distance of another stone a little tentative line is drawn. When the mouse is clicked the line becomes permanent. No extra complexities required.

Bildstein: You've convinced me that there are good arguments for you proposed rule on connection. I'm still leaning toward mine, and as I've said before this is only because I personally feel it is closer to regular Go, but now I think it comes down to the aspects of forgivingness and flexibility that you mentioned, which are, of course, subjective. So I suppose the only way to conclude this debate is to try them both and see.

I'm going to be taking holidays through December and January, in which time I hope to write the software I've been talking about. I don't think it would be too hard to put an option into it that allows the user to play with whichever of these two rules on connection he prefers. Perhaps you'd like to try them out with me some time in January, and we can see which one works best in reality?

GoStone: Yes definitely, that would be fun. I suspect your hardest job will be working out whether a group of stones has any liberties. Apart from that, I suggest Chinese rules to avoid having to count territory.

proposal for an easy implementation

(Sebastian:) The page http://www.di.fc.ul.pt/~jpn/gv/boards.htm gave me two ideas, which I think we could combine:

Firstly: If we do not require a grid then a more natural arrangement for circles is to have not 4, but 5 or 6 neighbours. Which is an advantage: The game becomes even more strategic! So I think we should not try too hard to emulate traditional rectangular go, as done in the crosscut and ko examples, but accept that some things will be quite different.

Secondly: We could use Zhiyuan Zhao's applet as a board with the following modifications:

1. Display the points as black and white circles ("stones") with radius r.
2. Use only the triangulation feature.
3. Triangulated lines are only displayed between stones of the same colour. We call them "connection".
4. Disallow any entry of a point that creates a triangulation line shorter than 2*r.
5. If a new stone would overlap the border or an existing stone, then move it away so that it exactly touches the border or the stone (if allowed). This is to ensure that the game behaves intuitively - like most objects that we can touch.
6. Enable undo for (accidentally) deleted points.

This allows us to play already, using NZ rules, and doing the rest manually as follows:

1. Definition: A group is a single stone or a set of stones that are connected.
2. A group lives as long as its owner can add a connection. If in doubt, the opponent can ask the owner to demonstrate this; the demonstration will not count as a move, and someone will delete the testing stone. If a stone has been played inside a group the defender has to demonstrate life for his/her group first. (In a timed game, then demonstration will be on the challenged player's time; the challenged player will be rewarded a bonus 10 seconds for wrong claims; and the challenger has to delete the testing stone on his own time.)
3. If a group is dead, it is removed stone by stone manually.

These rules are not meant to be ideal, but as a compromise for what we could do with little extra effort. Does anyone know Zhiyuan Zhao's email, so we could ask him for the code - or does anyone have the time to program this from scratch?

PS: This also lends itself to a very elegant type of area scoring: Each player's score is the area of the Voronoi cells around the stones of his/her colour. And the best of it is: This would allow us to compute mathematically exact scores at any time during the game that are reasonably close to the eventual score (unless there are big dead groups - but they still would affect the result less than territory scoring, since they are contained by enemy stones and probably have no big outside areas. This in turn has advantages for game analysis and would allow some more fun rules that I'll write about some day.

Karl Knechtel: I really like the Voronoi cell scoring idea. It allows for arbitrarily close games. :)

Tapani Raiko: I vote for the Voronoi scoring too, because: 1) It is faster. No messing around filling the areas with stones when scoring. 2) It is simpler. Consider for instance some weird seki situation, where it is hard to tell what is player's area and what is common.

Ko rule

Instead of (as in NZ rules:) "the resulting board position {must} not repeat the whole board position as it was after any of that player's previous moves" we could say either

1. Forbid to kill a stone that just by itself killed a single stone - or
2. Forbid to repeat the same pattern of triangulation lines

Karl Knechtel: I support the former. Except that it should read "kill a single stone" at the beginning (unless that's what you meant by "just by itself").

"If the play of stone y captures stone x and no others, the response may not capture y unless it also captures other stones."

Any talk of a "pattern" of triangulation lines is bound to be ambiguous.

rubilia: That's true, but upto now, unfortunately, we don't have any rule for superko situations, not even a "no-result" one. Whilst exact recreations of former whole-board positions would be no big deal to forbid, it seems hard to find a simple (or, at least, practicable) way to determine what we'd call a "similar enough" position (sibling) for the sake of avoiding loops.

Definition using Removing Friendly Stones

Robert Pauli: Let me draw attention back to Zahlman's proposol. To me it was good, however, his "definition" not. Let me fix it:

A stone is captured if it remains on the board after following imagined process:
As long as possible remove friendly stones that could be touched by a new stone.

That's all - no need to define connection!

(Sebastian:) I love your idea of removing one more arbitrary definition. And your rule has the advantage that one needs at least 4 stones to surround. (3 evenly distributed stones provide exactly the space to escape between each of them, which is very elegant from a theoretical and intuitive point of view.) What's not so intuitive is the double negation in your definition. For those of us who still find the concept of connection intuitive, we could reword your rules as follows:

A stone lives if it could be touched by a new stone

• either right away or
• after removing one living friendly stone. (In this case, we say: "The two stones are connected.")

Notes:

• To be exact, the quote after "we say..." is not a general definition for connection - it only defines it for living stones with no liberty next to them. But you get the idea. Once we agree on the rules, we can define define our terminology whichever way helps us best talk about the game.
• Of course, these rules would become ambiguous if the stones were imperfect, as axd proposes below.

Karl Knechtel: I think you guys are on the right track here, and this is the idea I was trying to get at. Trying to define "connection" is probably a mistake; the fundamental thing is the rule of capture, and life is defined as that which cannot be captured, and then connection is defined as the property of members of a set of alive stones.

However, I can construct a situation (I will have to draw a diagram, and post the image later - there is no way I could represent it with an SL diagram) in which the first definition (with removing *all* 'free' friendly stones) results in a stone staying on the board while the second (removing just one) results in it being captured. Looking at the situation (I am staring at a few pennies that I have arranged into a precise configuration) I think I would prefer that the stone is captured in this situation.

Thus:

A stone x remains on the board iff: a) it is possible to place a stone y touching it; or b) There exists a friendly stone z which can be determined to remain on the board by this definition (recursively), and such that removing z would make it possible to place y touching x.

This is good enough to let us write an algorithm:

Upon White's play: Mark all Black stones with room for a touching stone. Repeat until no change:

 For each unmarked Black stone x:
   For each Black stone y within 4* units of x:
     If removing y leaves room for a stone to touch x:
       Mark x.

Remove all unmarked Black stones. Mark all White stones with room for a touching stone. Repeat until no change:

 For each unmarked White stone x:
   For each White stone y within 4* units of x:
     If removing y leaves room for a stone to touch x:
       Mark x.

If any White stones are unmarked, replace the removed Black stones**, and report an illegal play.

Similarly for Black's move.

• where the unit is the stone radius.

• • Is it possible that Black stones are removed in the first step, but there still end up being unmarked White stones?)

Now the fun part is doing the geometry to determine whether there is room for a touching stone...

Robert Pauli:

Dear Sebastian, I love it too! And, right, stones have to be uniform, which shouldn't be a problem since this game will be played on the screen anyway ( Mikado for the rest) . . . hmm, forget the "right", actually only the liberty shape has to be defined, stone shapes could vary.

Dear Karl, thanks for making me realize that connection is not fundamental to Go!

. . . while the second (removing just one) . . .

Think Sebastian's definition is meant recursive, so he's not just removing one stone.

(Sebastian:) Actually, i made a mistake. My definition was recursive, but not recursive enough. Forget that idea, I have a better one: Euclidean Go

rubilia: While I didn't get quite fond of "Go without lines" when looking at the main page some time ago, I am really fascinated now by the Euclidean Go approach. Rules turn out to be beautifully simple that way, and the visualizations are excellent. Heeh, I want to play that game!

(Sebastian:) Great! Let's have an ongoing game! See discussion below^[991]. And thanks for the compliment!

For each unmarked Black stone x: . . .

• Should be black stone - sorry for nitpicking.
• Don't check all unmarked stones over and over again, only check the neighborhood of each newly marked stone (fire front)!
• Think you forgot to qualify y as marked.
• Think you forgot to consider several y blocking one liberty.
• Think it's plainer if the check for free friendly stones isn't just initially, but repeated . . . hmm, forget it, since there's no initial fire front, it still needs an exception.

Is it possible that black stones are removed in the first step, but there still are unmarked white stones after step two?

Only if choked white stones were around initially.

Other Stone Shapes

axd: Reading all this (and also Automation's remark) made me think of following: some problems here stem from the continuous nature (perfect circles) we are trying to impose on the stones. A Japanese mind might not like this perfection, so here is a variant: why not create discrete forms that are approximately round (blobs), but consist of a fixed (i.e. all blobs have the same amount of) number of pixels; either all stones are copies of such a blob, or each stone is unique (yet another game option - and also: what geometric transformations blobs may undergo: rotation, flipping, etc...). Contact would be easily defined as whether blob pixels touch or not. Scoring would be done using the remaining blobs (they would look like stones, but this better describes what I am talking about). The challenge is to find the right level of granularity: not too fine (too much pixels per blob, but we could end up striving for perfect circles again, which we don't want), not too coarse (the other end of the scale is a single pixel blob, with four touching sides). This approach would get rid of as-close-as-possible and "sqrt" problems, for example. Note that this game variant cannot be played without a computer, so let's impregnate it more with computer-related restrictions.

BTW: if we extend this idea, we could play Go with pentominoes.

Robert Pauli: Messed a bit with your rules. Hope you agree. Didn't get the intention of your scoring: Territory without captives? Definition and experimentation? Come on. Left it therefore, but you certainly should go plain: Number of one's stones on the board is one's score - period. The example in the suicide rule should be dropped.

Bildstein: That's fine. I might revise your revisions a bit, later on, but for now they're fine. In the mean time, I've clarified the scoring a little, I hope.

Robert Pauli: Actually I prefer territory scoring, so just go ahead, but what I can't accept is a game being over but nevertheless skill necessary. You can add a clean-up phase, for instance by using pass-stones and an even number of moves.

Bildstein: I suppose I agree. It's not elegant, is it? When I write the software, it might be possible to come up with some automated agreeable process to determine surrounded area.

Bildstein: Also, I think you're right about needing a clean-up phase, for example allowing each player to move or remove stones inside their territory (with adequate compensation, of course), because otherwise it would be too easy to mount a hopeless invasion which costs your opponent points just by virtue of their stones being spaced inefficiently.

Bildstein: Check out some pictures I took to illustrate some basic live shapes under my rules.

Robert Pauli: Saw none?

Bildstein: Hmm. That's funny - they work for me. It'd be a shame if some people couldn't see them. Anyone else got any ideas?

[991] ongoing game

How can we play a game? I see several options:

• use a private chat on KGS to transmit coordinates; each player would be responsible for displaying them. (I could write a simple program that does just that.)
• create a room on KGS where we can chat and have people observe and comment the game;
• (ab)use a game on KGS for that. Obviously, we wouldn't use the board itself. But we could use the chat part so others could follow the game (and players wouldn't see their chitchat), and it would be stored as a file.
• send each other a file with the diagrams. (I used Powerpoint to create them, so if you wanted to use that as well, you could play around with it.)

In both cases we will have to give each other some slack in the event that two stones don't exactly touch.

BTW, you changed Euclidean Go and wrote in the summary: "life definition seems to need further improvement" but I don't see any changes other than the changed hyphens and apostrophes. Anything I missed?

rubilia: Yep, there was a hidden comment beneath the definition. In the source diff it was not really findable either because of the messy syntax changes, wherever they may come from (could be a browser issue?). Anyway, I've put it into a footnote now. The ongoing game idea sounds fine, but right now it's me who feels far too sleepy to seriously consider your suggestions. :)

Reuven Do you really beliv it makes senes? If you want to add more strategy and freedom to the moves, make a more complex linning on the board - just leave the lines there. Without line it makes no sense! It wouldn't be playable for humens - Not even using a PC since one won't be really able to calculate direction and distance as it goes and even if u use a program to do it... You won't be able to use the degrees in a tactical plan! I suggest making a more complex linning if you want your freedom. It can be more lines (100x100) vertical and horisonal as well as lines which go at certain degrees such as 30,60,90 The board should also be larger to avoid the visual mess... - More freedom if that's what you seek...

(Sebastian:) Thanks for the challenge, now we really need to prove you that it is playable. Then again, we might not be humen^[1].

[1] correct plural of "human".

ihope?: I think using square roots of rational numbers and their opposites as coordinates would work. If stones have a diameter of 1, there's a stone centered at (0,0), and I want to put one next to it to the southeast, I could put it at (sqrt(1/2),-sqrt(1/2)).

Jeff: Ihope, Fair enough, I take (0,0); you take (sqrt(1/2),-sqrt(1/2)). I want to respond with a 45-degree clamp. So my stone would go at (sqrt(1/2), 1-sqrt(1/2)). But to do this, we have deviated from your rule that stones must be at square roots of rational numbers. 1-sqrt(1/2) is not the sqrt of a rational number. It is the sqrt of

• (1-sqrt(1/2))^2
• =1-2*sqrt(1/2)+1/2
• =3/2 - sqrt(2)

(3/2-sqrt(2)) is not rational.

fractic: If you allow iterated square roots you could play as Jeff wants. You get all points you construct using a ruler and compass. You still couldn't play everything though. You can't make a regular heptagon out of stones for instance.

ihope?: You have a point, Jeff. fractic's solution does seem to do the job (unless you like regular heptagons for some reason :-), though I wonder if it's possible to get along with sums of square roots of rational numbers.

Wall-based rules, pixelation

Hi, I'm Dranorter, I don't have an account yet though. I have been playing a pixelated version of this, as well as (only against myself) a more continuous version. My approach to the rules was completely different.

My basic idea is to consider pieces captured when they are surrounded by an enemy 'wall' within which there is no room to play. This could be seen as a little less elegant than the version with liberties, but it plays well (in my opinion). A wall is not a line of actually touching stones; instead it is a line of stones close enough that a line of touching stones cannot pass between them; i.e., 2/sqrt(3) where 1 is a stone's radius. This is equivalent to saying the stones are close enough that (ignoring all other stones on the board) no stone could touch the imaginary line between their centers. I like this distance because then a line of actually touching stones is impermeable — an enemy wall cannot pass through it. A straight wall with gaps can be crossed, though zigzagging the wall a bit prevents this.

An odd consequence of this set of rules is that you can end up with an area where there isn't room for anybody to play, but no stones are close enough to form walls so all the stones live. Causing such a situation is an interesting option.

In my opinion these rules aren't overly dependent on exact piece position; playing physically there was not too much reason to place stones at a position borderline between touching and not. If it is played with something that can be grabbed from the top, like a Sorry piece, accidentally moving pieces is not a big problem. So at least for inexperienced players this seems pretty reasonable to play physically. I think this should be an important goal for any continuous version of go.

For the pixelated version, I chose to not consider diagonally adjacent pixels as touching, and I used the following stone shape:

Stone shape  

This means the black in following is connected:

The white cannot touch  

While the black in this diagram is not:

The two white can reach each other  

I think the way the pieces fit together is kind of nice, and there are still enough ways to place pieces that it has the feel of a continuous game. Another advantage is that there is no doubt as to whether pieces are close enough to be connected, or whether there is room for a piece somewhere.