I am a relative newcomer to Go and more interested in the programming aspects of designing a Go Engine.

Do Go engines use a systematic list of Endgame positions with known wins, the way chess engines do? And do professional-level Go players memorize a list of endgame positions as part of their training?

Some online digging turned up this Wikipedia article and computer science paper suggesting that Solving Go Endgames by computer is really hard problem, guaranteed to take up plenty of time. Perhaps that's the reason why Go endgame tablebases don't exist / aren't widely used?

  • On topic at game development? Commented Nov 9, 2011 at 22:14
  • As there is two question in one I migrated the second here Commented Dec 13, 2011 at 17:24
  • 1
    While I do not recall specific comments on endgame positions in the reports on Apha Go — and I found neither “endgame” nor “end game” nor “yose” in the freely available PDF of Mastering the Game of Go with Deep Neural Networks and Tree Search —, I imagine that its policy neural network with 13 layers containing 192 filters would, once trained, be pretty useful in the end game.
    – PJTraill
    Commented Mar 3, 2016 at 13:25

3 Answers 3


I know much more about Go than chess, so I don't know how accurate my guesses about chess endgames will be, but... I think chess tends to be at its simplest in the endgame (like Go), and there is little information in the endgame about how the rest of the game progressed (unlike Go). And, there are algorithms for winning (in some cases) that generalize to a large number of positions. E.g., if white has a Queen and a King, and black only has a King, unless the Q is about to be captured white will win, regardless of position.

In Go, the endgame is also the simplest part of the game, in that it is the only part of the game in which the score and the value of each move can be calculated very precisely, however position is everything, and you will never see two games end with the same board position. In chess, you can generalize many positions to what pieces remain, but in Go the only generalization is the score count and the number of points still remaining to be taken.

It would be utterly impractical to rely on whole-board level tables in Go, however many small areas of the board will fit common patterns, which are memorized by Go players and programmed into computers alike. A medium-level example would be bent four in the corner is dead, but you'll see that this relatively common position is not at all obvious to a beginner and comes with several caveats (no un-removable ko-threats, surrounding group must be alive with 2 eyes), and while relatively common, it is somewhat of a special case.

Something like knowing where to play to kill (or save!) bulky five (and many many other shapes) should be automatic for a human or computer.

Programming a computer to play good yose is a very hard problem, but is one of the few aspects of Go at which computers can beat professional Go players, as it is all calculation and, while difficult, the theory is well-understood. To do it effectively the program must be able to estimate the current score, identify the moves left on the board that are worth points, and sort them in order of worth---not trivial. This article might be a good place to start.

Summary: There is a place for systematic lists of positions in Go programs, but they won't be useful for whole-board positions. The program needs to be able to evaluate the life/death status of every group on the board, and it is in these one or two group positions that lists will be most useful---and they'll be valuable throughout the game. In trying to attack opponent's groups, your program's goal won't be just to recognize shapes from the list, but rather to force the opponent into shapes that it knows are dead, while maintaining live shapes itself. See also Common Corner Shapes.

In writing a Go program, I would give you the same advice as I would a person learning Go: start on a small board, even as small as 5x5 until you have the rules down. Move up to 7x7, and then stay with 9x9 for a long time before you even think of trying 13x13.

Good luck!


There are no whole-board endgame databases because there are too many possible permutations in the end. Such an approach could not be handled with state-of-the-art computer systems.

The good news is that endgame databases for confined, local situations do make sense and can be applied really well, the further the endgame has progressed. After you have analyzed, what's the result of each confined, local situation, you can calculate the best way to deal with them by finding the right order of moves. Of course it is not that easy to find a perfect solution, because you have to time "free" sente moves that do destroy your own ko-threats and so on, but AI endgame in Go is pretty good compared to midgame.

To understand the concept of the endgame, common patterns, the importance of sente/gote and so on, I can recommend the book The Endgame, if you are interested in them.


There is an endgame theory for Go using Surreal numbers. The theory is layed out in the book "Mathematical Go: Chilling Gets the Last Point" by Berlekamp and Wolfe.

An AI using this theory plays optimal and usually beats a human pro player on the endgame. Reading the book is still fun for an average Go player and teaches you a lot about endgame strategy.

  • Comments on the Amazon page for the book, indicate that computer Go today is very different than described in that book.
    – John
    Commented Mar 4, 2016 at 17:43
  • @John: The mentioned book only treats endgame theory (but this in an exhaustive way); it is not about Computer Go in general. Commented Mar 5, 2016 at 9:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .