DipGo, a love letter to OGS


I noticed a lot of interest recently in multi-colour Go, so I’d like to share with you the server I built, DipGo, and also to express my appreciation for the OGS site and the larger OGS community.

Here is one of my favourite games, played over the course of last year. I think it captures well the way games of this scale can play out between serious and committed players.

Here is a 9 (kind of 8) colour game on a 5x5 board. I was the last player to play and don’t think I could have done much differently to have a chance to win the game!

One downside I have noticed regards online gaming - if opponents are not committed to large games with lots of players and little time on the clock, there can end up being too many dead stones on the board for the game to be dynamic. Maybe some players don’t mind games like this, but I personally find them a bit slow. Here is one where the remaining players negotiated a draw.

I’m happy with what I have created in DipGo.net but it would not have been possible without OGS.

I can safely say that OGS is the single best online resource to learn and play Go as well as to meet like-minded individuals. I have learned so much about the game from so many of the players within the community through the years, and they have helped me to realise more of my potential than I could have imagined when I started out. It has been incredible to watch OGS grow and evolve to include things like AI reviews and Rengo, while at the same time being enabled personally to improve from DDK to SDK. To everyone who works to make OGS better every day, thank you and keep up the good work.

I loved playing on OGS, maybe too much! I played around 10,000 games of blitz 9x9 and spent countless hours on the site chat. I learned a lot through these activities, but I also learned that there is more to life and everything is better in moderation, so I try to play less these days and spend much more of my time on other non-go-related activities.

DipGo was conceived as a cross between Diplomacy and Go. I had the idea years ago but never found the time to build it until the pandemic started and there was not much else to do. It started as a practice project for me to learn Kotlin and grew into what it is now. Having been around OGS for a while, I had some experience of what makes for an excellent Go server and I hope I brought even a fraction of this with me.

I would never have had the imagination to build DipGo without the help of many people within the community, a few of whom I’d like to thank;

Anyway, I think I have said my piece. Thanks to everyone, and let’s continue to celebrate the incredible game that is Go together.

All the best,


Oh huh the server is built in Kotlin? I thought that was only used for Android apps!

Anyway yeah DipGo is really fun. I encourage everyone to check it out!


Nice looking idea, but can’t say I like being faced with the login screen every time I click a link in the left panel. Could be an idea to let anonymous users browse around…


There isn’t really a great deal to be browsed in all honesty. DipGo | Archive is able to be browsed without logging in. Everything else requires an account to play or chat.

Top tip, you are not required to provide a real email address :wink:

My feedback was more about the experience of getting that big red page every time I click on anything, rather than whether I was missing stuff to be browsed.

Maybe grey out all the links that need you to be logged in, if you aren’t logged in.

1 Like

Neat project!

What are your thoughts about simultaneous moves? I think that is one aspect that would heighten the intrigue and similarities to regular Diplomacy. However, it opens questions about how to properly handle collisions.

Actually, on these forums, we have previously played a couple of Diplomatic Go games with simultaneous moves. See this thread and links to the games therein.


Another way to handle simultaneous moves is fractional color mixing…


That’s a really good idea - as you have probably sussed, I am not a UX guy!

I spent a long time trying to understand this situation:

and I still don’t get it!

Even regular 2-colour one-move-at-a-time Go can result in all sorts of weird and complex situations. Simultaneous-move multicoloured Go is so complicated, there must be all sorts of weird situations, and so little-studied (compared to standard Go) that there is probably not much precedent for resolving them. Incidentally, I believe this is one of @martin3141’s fields of study if I remember correctly.

For what it’s worth, when designing the game, I always picked the simplest option I could when faced with such decisions - for example using positional superko and Chinese rules. I imagine a similar approach would have to be taken for simultaneous move Go and, even then, I wouldn’t be surprised to encounter situations I hadn’t considered.


That’s to demonstrate another design consideration regarding simultaneous moves, how to handle simultaneous captures, or rather what to do when move(s) simultaneously remove the liberties of multiple chains.

One approach is (after placing new stones) to simultaneously remove all chains that do not have liberties, but this generalization is a bit different than how capturing works with standard two-player, sequential Go.

Notice that under standard Go, a move can simultaneously remove the liberties of stones of both colors, but only one color’s stones will be captured.

Consider this position, for example:

Black could place a stone at A3 to capture the 5 White stones, but at an intermediate point (before clearing the White stones), the board looks like this:

However, under standard Go, only the White stones are removed, since it was Black that initiated that position by playing a move.

The rules that we used for capturing in our Diplomatic Go games can be a viewed as a consistent generalization. In each turn, we follow this procedure:

  1. Resolve all collisions and place the new stones on the board.
  2. Check for any chains of stones that 1) do not include a newly placed stone, and 2) do not have any liberties. Remove all of those chains (“old chains”) from the board.
  3. Check for any other chains of stones that do not have liberties. Remove all of those chains (“new chains”) from the board.

This procedure boils down to the familiar capturing rule (with suicidal moves allowed), if only one new stone was placed in that turn (e.g., if all other players passed or failed to place due to collisions). The separation of removals into two distinct phases allows newly placed stones (and the chains that they connect to) to have survival precedence.

Even when multiple stones are placed in a turn (as is typically the case), if these stones are affecting distinct areas, then the capturing mechanics still behave in a way that resembles normal Go.

@Vsotvep’s example demonstrates how all of the big chains are captured in the first case, since they are all “old chains”, but in the second case, the Blue and Red chains are extended by new stones, making them “new chains”, allowing them to survive after first removing the other “old chains”.



Is there a place to make feature suggestions for DipGo?

On page dipgo.net/dashboard/play
I think it would be great to be able to sort the games. For instance, if we could click on a column head, to sort the games according to that column. In particular, it would be great to be able to:

  • Sort the games by board size, so as to more easily find a game in a board size that I like
  • Sort the games by title, so as to more easily find a game whose title I remember
  • Sort the games by total number of players
1 Like

Is there a place to make feature suggestions for DipGo?

Not officially no, but thank you for the feedback. I will add it to the list and hopefully act on it soon.


So iiuc, the mechanic for abutting groups works like this?


In this situation, both the inner chains are “new” and have no liberties, so rule 3 removes them in a double suicide?



Yes, that’s correct.