herzbube
commented
3 years ago SGF defines node annotation properties and move annotation properties.
Node annotation properties:
- N, C
- N: Node name. Data type is SimpleText.
- C: Comment. Data type is Text.
- N is intended to be like the short version of C, but there is no guarantee that the value is actually short. The only difference is that C can contain newlines and N cannot.
- GB, GW, DM, UC
- Data type for all of these is Double.
- Only one of these can appear per node
- GB/GW: Position is good / very good for black/white.
- UC = Position is unclear / very unclear.
- DM = Position is even / very even. It's not clear what "very even" is supposed to mean. The SGF standard has this to say about the property: "This property may indicate main variations in opening libraries (joseki) too. Thus DM[2] indicates an even result for both players and that this is a main variation of this joseki/opening." This is still not very clear.
- HO
- Data type is Double.
- The meaning is that the node is a "hotspot" or contains a game-deciding move. Double value 2 emphasizes this.
- V
- Data type is Real.
- The meaning is "Value for the node", which in Go means the estimated score at that point in the game. Positive values are good for black, negative values are good for white.
Move annotation properties:
- There are only 4 move annotation properties, and only one of these can appear per node.
- BM
- Data type is Double.
- The meaning is "Bad / very bad move"
- TE
- Data type is Double.
- The meaning is "Good / very good move" (tesuji)
- DO
- Data type is None.
- The meaning is "The move is doubtful"
- IT
- Data type is None.
- The meaning is "The move is interesting"
The "worst case" that the app must be able to handle is the presence of all of the following properties in a single node:
- N
- C
- One of GB/GW/DM/UC
- One of BM/DO/IT/TE
- V
- HO
Ideas how to render these things:
- In general there should be an info box next to the board that displays detail information about the current board position.
- The user should be able to show/hide the box.
- On iPad the view layout needs to be redesigned as there is currently not enough space for such an info box.
- It may be possible to integrate some of the information into the board position cells, depending on how much space is available on a particular device.
- N: Is displayed as the title of the info box.
- C: Is displayed as text inside the info box.
- GB/GW/DM/UC is shown as a single value "Position valuation".
- With a lot of space available the value can be shown as text.
- With medium space available a gradient ranging from black to white with a marker to mark the value could be used to display this. UC could be displayed as "?" instead of a marker. Unclear: How to distinguish DM values 1 and 2.
- With minimal space available only the single color could be displayed.
- BM/DO/IT/TE is shown as a single value "Move valuation".
- This could be displayed with the same basic concept as GB/GW/DM/UC
- The difference is that the gradient uses different colors to indicate the goodness/badness of the move, e.g. red for bad and green for good.
- V is shown as a decimal number. If possible enough space should be reserved to display 999.9.
- HO can be indicated with a symbol such as a red dot or a flame.
Ideas for additional UI elements:
- UI elements that let the user navigate between hotspots.
- A popup list of hotspots that the user can quickly select from (using N as title)
- Allow the user to filter the board position list so that only positions with certain characteristics are displayed (e.g. only hotspots, only positions with comments)
Open questions:
- What is the difference between DM[1] and DM[2]?
- How do we deal with nodes that do not contain moves but only node annotation properties?
With the intregration of SgfcKit the app has now access to comments and annotations that are stored inside an SGF file. The app should provide a means to display these things.