Problem Construction Best Practices

Choosing a Problem Type

• Life and death: the most basic kind of problem. An entire group must live or die. Generally there shouldn’t be a lot of extra stones on the board beyond this tactical area.
• Tesuji: some kind of precise tactical move resulting in a clear outcome. This could be killing or saving some stones (that don’t have independent life). It could be connecting groups together or cutting.
• Endgame: a challenge to find the optimal move in terms of points. This generally does not involve killing or saving a whole group.
• Joseki: a problem involving making the right choice in a standard joseki pattern. These problems are tricky and generally hard to do well, and should generally be avoided.
• Fuseki: whole board choices. Like joseki, extremely hard to do well, and many problems added over the years have been proven straight out wrong by modern AI.
• Best move: this captures problems that don’t have a defined tactical solution, but have choices that lead to a clear difference in things like influence, thickness, and so forth. Only the strongest and most experience problem creators should consider adding problems in this category.
• Elementary: this category is deprecated and will be removed.

Basic style

Place comments either at the computer's move or at the end of a variation -- comments at the player's move won't be seen if the computer automatically responds.

End correct variations with the protaganist's move, wrong variations with the antagonist's. (An exception to this: if a move dies in gote, it can make sense to end the variation there with a comment.)

Using multiple CHOICE

Often there are multiple ways to test someone trying a problem. In other words, solving a problem fully involves knowing how to cope with various responses from the other side. To this end, there exists a method for letting the computer choose randomly from various responses at certain key junctures.

By default, the computer responds with the top branch -- the first branch given in the SGF. To specify which response you desire, or to randomly pick between two or more responses, add the word CHOICE (caps required) to one or more branches. When the problem gets to a point where two or more branched responses have a CHOICE marker somewhere down the line, it will randomly pick between them. For an example of this, see problem 8. After the first correct move by the human, the computer will randomly select between two different responses.

Example

(;AW[hh][lh][hi][ji][li][lj]AB[kg][lg][mg][mh][mi][mj][kk][lk][mk]C[Black to play and catch the three stones.](;B[ki](;W[kh](;B[jh];W[kj];B[jj];W[ki];B[ii]C[RIGHTCHOICE])(;B[kj];W[jh]))(;W[kj](;B[kh];W[jj](;B[jj];W[kh];B[jh];W[ki];B[ii]C[CHOICE RIGHTstones are caught])))(;B[jh];W[jj])(;B[jj];W[jh])(;B[ii];W[jj]))

Advanced Control

A special tag, NOTTHIS, can be added to a problem. This outlaws a certain move. Just add this like you would add RIGHT or CHOICE, and the user will be unable to move in this intersection. This can be used to cut down on extra variations.

Adding FORCE as part of a comment field is the counterpart to NOTTHIS. The problem solver can only play a next move in places the SGF anticipates with a branch.

Note that adding these controls isn’t ideal, since there needs to be a different type of UI feedback in these special cases, so only use it where really necessary to cut down on insane variations.

Tag Support

The tags from SGF supported here may change over time (new support may be added). Right now, this is supported, and anything else is ignored (these tags are usually encoded as just the capital letters -- eg, AddWhite becomes AW):

• White
• Black
• AddWhite
• AddBlack
• Comment
• LaBel
• TRiangle
• MArk (square marker)
• SiZe (board size)

Note that most SGF editors are pretty well behaved, but some may output non-compliant formats.

What should be considered “correct” in a problem?

You have an option to define the goal of the problem in the root comment. It may be something like:

• Black to kill
• White to find a ko
• Black to play the optimal move

If no instruction is given, there are some assumptions made about the goal:

• Many problems imply a life and death situation. Any path with a clean kill/making life is considered correct in these situations.
• Seki is considered life and is correct by default
• If the solution is a ko (no clean life/death), one step is better than two step and so forth. And if there is the option to take first, another option that has the opponent taking first would be considered incorrect.
• Living with part of a group is considered wrong if you could live with the whole group. (With the exception that losing a stone or two isn’t wrong.)
• Sometimes stones are marked in a problem. Usually this means they must be saved or killed specifically. 

Note that standard go problems are reductions from real game situations – ie, they only cover a section of the board. In real games, different solutions could be better choices depending on context. For example, it’s possible that making seki for life is worse than ko in some endgames.

When adding problems, it’s generally better to let the default goals apply unless there is a good reason not to. Ie, don't bother to put "Black to kill" or "White to get a ko" etc.

The response moves in a problem do not have to be optimal in terms of the best result. They can be chosen to test the player in various ways.

Problem Introductions

When adding a problem, there is an intro field you can fill out. This should be for notes the problem creator wants to add that are interesting or fun for whatever reason. They should not be required to solve the problem, and by default will not be visible to the user.