A New Approach to the Creation of Go Problems

   

Imagist: I have been doing a lot of go problems lately. I collect these problems from various sources, mostly books, but also the internet and pamphlets handed out at go events. Go problems have helped my game a lot, but I have noticed a number of problems, most notably:

  • Even without looking at the directions such as "White to live" or "Black to kill", the general situation is usually clear. If black has stones in the corner and white is surrounding the corner, it is clear that white is trying to kill black, and the problem will be either "White to kill" or "Black to live". The problem lies in that stones that have no effect on the problem are removed from the problem. While this simplifies things for the person making the problem, it does not help the person doing the problems. When a life-and-death situation occurs in a game, the unrelated stones don't magically disappear. Including unrelated stones in a problem helps the reader to recognize life-and-death situations during a game and to differentiate between important and exterraneous stones.
  • Problems always have a stated goal. "White to connect the marked stones" or "Black to create ko" are the problem. In a game, the local objective you may be thinking of is not always the correct objective. I rarely am able to recognize when a life-and-death situation comes up in my game because in a game I am generally thinking with the objective to "Make influence toward the right" or "reduce my opponent's territory along the bottom edge."
  • Problems are always solvable for the stated objective. The assumption is that if the problem is "White to kill", white can kill. Usually when I recognize a life-or-death situation, if I can live or kill, I recognize how to do it. I have no doubt that this comes from my studying tsumego. However, if I cannot kill or cannot live, I often do not recognize this immediately. Usually I end up staring at a dead group for a long time and sometimes attempting to save it, occasionally even dying in gote. The reason for this is that go problems have taught me how to make life or kill, but not to recognize when it is impossible for me to make life or impossible for me to kill. Additionally, there are some times when ko can be made but the problem only lists the way to unconditional life or unconditional death. There are many cases where I have needed two moves in a row to make a large invasion work, and would gladly given up a small group or killing a small group by making a ko to gain the two moves in a row. Unfortunately, go problems do not effectively teach one how to create ko.

I propose the following solutions to these problems:

  • Include extraneous stones in go problems. Ideally a whole-board situation should be given, but this can be taxing for both the creator of the problem and the solver of the problem, so a comprehensive local situation is fine.
  • Do not state a goal, and show all variations. If there is more than one possible goal for a situation, give the way of achieving each as a solution, discussing the merits and characteristics of each. Not only does this teach the solver to see multiple possibilities in a situation, but also to see which goal should be pursued in a situation.
  • Do not show who has sente. This is related to not giving a goal, as often telling the who has sente makes the goal of the problem clear. This also allows us to get more out of a problem, as it allows us to solve it twice. A notable exception to this rule is if playing a problem as one color gives a trivial solution.
  • Intermix different kinds of problems. In a game a player is usually presented with a variety of situations intermixed. Rarely is a player presented with a nice group of opening problems, then a few tesuji problems, and then a few life-and-death and endgame problems. While it makes sense for a player to look at a group of endgame problems if he/she wants to work on his endgame, general collections of problems should not categorize their problems so strictly. Instead, the situation should be given and the reader should be left to figure out what kind of problem they are dealing with. This may necessitate comments such as, "White should leave W3 as a ko threat unless it is very late in the game." or "B8 and W9 are small and should be left until the endgame."
  • Discuss variations from BOTH players' perspectives. In a problem designed for black to kill, one should also discuss how white should die to produce the best aji, and so on.
  • Do not make every problem solvable. In a game it is just as useful to know that a group is alive as it is to know that it is dead. This is also useful for teaching how to use ko threats or even ladder breakers; given two local placements in a row (i.e. a ko threat and a second placement after the ko threat is ignored) many groups that would otherwise live can be killed.
  • There are always exceptions. These guidelines lead to some very dynamic and challenging problems, which is a good thing, since that is what Go is like. However, beginners might feel lost and without direction in this kind of problem, so it may be beneficial to break some of these rules for their sake. Also, if you are giving problems as examples to reinforce a concept, it is inappropriate to give problems with possible solutions that are unrelated.

Richard Hunter You do not say whether the problems you have been studying are in English or Japanese. I suspect English, which has a limited offering. Problems in Japanese include most of the things you are looking for. Many players need to brush up on fundamentals (look for 基本詰碁). What you want might be more readily found under 実戦詰碁 or real game examples. I think there is value in both. Study whichever you prefer.


Example:

[Diagram]
Black to save marked stones  


This is the old way of showing a problem. A goal is clearly stated and sente is given to black.

[Diagram]
B5 at B1  

Black throws in for a connect-and-die. B5 is at B1.


This is the old way of giving a solution. One solution is given, without consideration for a wider situation.


Example 2:

[Diagram]
 


This is the proposed method of stating a problem. A complex situation is given and the solver is left to find the best play given the situation.

[Diagram]
Black has sente  

The vital point is the throw-in at B1.



[Diagram]
Black has sente  

If white plays W1, black captures the marked white stone and connects.

[Diagram]
Black has sente  

If white plays at W1 capturing the marked black stone, B2 creates a connect-and-die. This is best play for white, as it captures a stone and saves the marked white stone for the time being (it is not in black's best interest play at a until the endgame because there are likely larger moves). Additionally, white can play at a as a ko threat to kill the black stones.

[Diagram]
White has sente  

If white has sente, W1 at either a or b prevents the connect-and-die mentioned earlier.

[Diagram]
White has sente  

However W1 is the best move because it serves a double purpose. It kills the black group because after the sequence B2, W3, black cannot play at a because it would be self-atari. W1 also connects the marked stones to the main group so that black cannot use b as a ko threat later. Note that while c makes a self-atari, b still threatens white.

Bill: Diagram changed.

Steve: As I see it, W1 in this diagram, or White b in the previous diagram both leave 2 ko threats for Black in this position. The only difference would be that b in this diagram is a ko threat which may give points on the outside. As such, I'd suggest that the proposed solution should point out that the difference is in the value of the ko threats available, not the number of ko threats (that doesn't seem clear as it's stated at the moment).

This is the proposed method of giving a solution. Note that it gives variations for both black and white, and the best solution based on a larger local context. This teaches us to consider all variation and to choose our answer based on a wider way of thinking.


A New Approach to the Creation of Go Problems last edited by 24.91.83.128 on February 5, 2007 - 07:03
RecentChanges · StartingPoints · About
Edit page ·Search · Related · Page info · Latest diff
[Welcome to Sensei's Library!]
RecentChanges
StartingPoints
About
RandomPage
Search position
Page history
Latest page diff
Partner sites:
Go Teaching Ladder
Goproblems.com
Login / Prefs
Tools
Sensei's Library