SGF Wishlist
This page discusses new proposals for SGF.
Table of contents |
Properties
SGF allows applications to freely define its own properties. However, discussing new properties helps achieve standardization.
Things to think about
We must remember that SGF stands for Smart Game (not Go) Format and that it serves 15 different games. Anyone with a knowledge of SGF and the specification changes over its development should know that properties that have been too specific to one game (and underused then) have not survived revisions. So bear this in mind.
SD - Special Definition
- Property
- SD
- Propvalue
- SimpleText? : SimpleText? : SimpleText? : Text
- Propertytype
- root
- Function
- to make it easier for sgf readers to detect errors and convey full information the the viewer
- Proposed by
- LithiumTwo
Explaination
a sample of sgf (to apply to the PT tag below) might be SD[PT:SimpleText:game-info:The type of problem posed in this sgf]. Where the first value is the tag to be defined that is outside the file's FF specification, the second to be the type of variable for the property (composite types of "(simpletext:number)" may be possible), the third to be the type of property, and the fourth would be a description of the property. The reason for this would be exactly that if people needed a new property for their program, then this file would be perfectly portable, and error checking (and correcting) would be made much easier as standard sgf programs know what to look out for. In addition, for those intending to create new properties: sgf editors should have the capability to easily add these new properties to the sgf (even if they can't interpret them as the specific program will), and they can be displayed to the viewer of these sgfs in any normal editor.
Discussion
MM - Move Marker
- Property
- MM
- Propvalue
- simple text
- Propertytype
- game-info
- Function
- the appearance of the marker for the current move in a node (e.g., "none", "cross", "reddot", "greensquare")
- Comment
- unifies the appearance of the board over all sgf viewers. There should be several standard shapes.
- Proposed by
- Harleqin
Discussion
When this property is used, all sgf viewers mark the current move in the same way, so confusing text ("the stone with the red dot" "what red dot?") is avoided.
The motivation is to finally get wms to abolish his "CR" hack. :)
LithiumTwo: This is a bit redundant... people usually say "the current move" or it's coordinates... or even "this move"... I've never heard anyone refer to "the stone with the circle on it". However, the main reason it's redundant is that wms has already abolished the CR hack =)
PT - Problem Type
- Property
- PT
- Propvalue
- simple text
- Propertytype
- game-info
- Function
- the type of a go problem contained in the SGF file (e.g., "Tsumego", "Fuseki", "Capturing", "Connecting", "Yose", "Semeai" etc.)
- Related
- PD
- Comment
- Problem solvers recognizing this property could automatically group problems into categories and let the user search for them (e.g., "give me all yose problems")
- Proposed by
- maruseru
Discussion
The main motivation comes from the existing practice of storing tags such as the problem type and difficulty outside the SGF file. This makes it difficult, when renaming, moving or copying the SGF files to keep them in sync with the tags. I'd really like to see this information being kept inside the SGF file.
I've added support for editing and searching PT[] and PD[] properties to kombilo and submitted the patched version to kombilo's author, Ulrich Goertz. I've also added a rather basic problem-solving mode to kombilo. Now it would be nice to have support for these properties in problem solvers such as GoGrinder and Go Album. That way you could edit your problems on the desktop and deploy the content to another application (possibly running on a mobile device).
PD - Problem Difficulty
- Property
- PD
- Propvalue
- simple text
- Propertytype
- game-info
- Function
- the difficulty of a go problem contained in the SGF file (e.g., "Beginner", "Easy", "Medium", "Hard", "Pro")
- Related
- PT
- Comment
- Problem solvers recognizing this property could automatically group problems into difficulty levels and let the user search for them (e.g., "give me all hard tsumego problems"). Obviously classifications such as "easy" and "hard" are subjective, but they might denote rank intervals. For example, "beginner" = 30k-20k; "easy" = 19k-10k; "medium" = 9k-1k; "hard" = dan; "pro" = pro (suprisingly; for example, the Igo Hatsuyoron problems would have a PDPro).
- Proposed by
- maruseru
Discussion
Benjamin: I would propose more fluent way of representing a problems difficulty (e.g. something like problem-{EGF}"rating") to give problem databases a way to further divide the probs according to user statistics.
IanDavis: how do you propose accurately finding the correct EGF rating for a problem ;-)
maruseru: I've created a page for discussing problem ratings.
VO - Voice
- Property
- VO
- Propvalue
- simple text
- Propertytype
- game-info, move
- Function
- contains URL or relative address of sound file to be played when game is opened or the move is displayed respectively.
- Related
- GC, C
- Comment
- Voice-over-IP is already supporded by some Go Servers. This property would allow to save it.
- Proposed by
- Sebastian
Discussion
Cheyenne: I have a concern about increasing the size of the SGF file (think of trying to download the SGF from say KGS and then importing into PilotGOne). A suggestion that this facility use two parts. The first part is handle for the sound file. The second part would be indexes into the sound file (start/end times). There could be provisions to handle multiple segment sound files (say within a variation branch). So you would have initial specification of where to find the sound file and then at each point you would only have a small index value to be used to indicate where to start and end the sound clip.
The sgf viewer resolves the connection between the handle for the sound file and the external file (that is either local or online). This should keep the size of the SGF down.
The way that I could see this functioning under say KGS would be that if you downloaded the SGF file you would be prompted if you wished to also download the corresponding sound file for the SGF. The file name would match the file name of the SGF and the file extension would be different (foo.sgf & foo.wav for example)
(Sebastian:) You're raising a good point. The standard could certainly include this in the form
VO[relative\path\voicefile.wav#60-95]
In order for it to become an accepted standard, it should be really easy to implement. I'm not sure yet how easy or hard it is to implement start/end times.
Another way to reduce the size of the SGF file would be to use smart defaults. E.g. an empty property VO[] could be interpreted as sgffilename\movenumber.wav. This would however require that each move description be kept in an individual file, which will certainly create more overhead.
Cheyenne: I think having the actual file name within the sgf file is bad. It makes an assumption that the path to the file will never change. What happens if I transfer the file from one platform to another, or from where the path to the file is a URL to where it is now a local file? who or what is going to keep it in sync. I think what would be better is to simply create a tag that the viewer/player then associates with the sound file (with external hints maybe). For example:
VO[A#60-96] ... VO[B#0-90]
Then let the viewer create the association between A and /relative/path/to/the/file.wav
Zarlan: I would be nice to have some sort of record of when what happens i.e. record if you go back a few nodes and say something there, it will be recorded that that happened. An alternative is having that recorded on a separate file.
This would of course only be useful for reviews and lessons and a format such as this is going to be made for KGS.
(Sebastian:) I'm not sure I understand what you mean. This seems to repeat the wish you just discussed on KGSStatus. If this comment is not an issue of the SGF format then it should be deleted from here.
Juan An alternative is to include the actual sound binary, not just a pointer. Of course it would increase the size of the sgf file, even if encoded as MP3 and depicted as base64 chunks in the file...
LithiumTwo: Zarlan's comment "This would of course only be useful for reviews and lessons" sums the useless of this idea up quite nicely - because currently lessons and reviews CANNOT be stored in sgf - because teachers have the freedom to go back and forth, and such tags are not in the current sdf specification. Also, to keep the game in sync with the sound file, every node of the game would need a <B/W>L (<black/white> time left) property. unless the sound files were going to be stored seperately, which someone has already said would be a stupid idea... now that we've established that this would be useless for teaching and reviewing and in this regard it remains to say that people don't usually talk during internet games. If employed this tag would damage the longevity of sgf files either because urls would change or because, for an archieve service (such as KGS), much fewer games could be supported because of the tripling of the actual sgf file sizes (because of the <B/W>L props.) and because of the sound files added on top.
BE, WE - Elapsed Time, var. 1
- Property
- BE, WE
- Propvalue
- floating point number (number of elapsed seconds)
- Propertytype
- game-info, move
- Function
- document how much time elapsed while the current mover was on the clock.
- Related
- BL, WL
- Comment
- Depending on the time system used, you frequently can not deduce the elapsed time from the BL and WL properities.
- Proposed by
- jfc
Discussion
jfc: This property is useful for playing back a game at the speed and tempo it was originally played. This is particularly useful for games that spend most of their time in Japanese byo-yomi as the BL and WL provide next to no information about the tempo of play during byo-yomi.
T - Elapsed Time, var. 2
- Property
- T
- Propvalue
- floating point number (number of elapsed seconds)
- Propertytype
- - (node annotation)
- Function
- time stamp, documenting how much time had elapsed since game start when the corresponding set of properties was created or revisited.
- Related
- BL, WL
- Comment
- One node may contain more than one T property, but a file must not contain any two T properties with identical time value.
- Algorithm to replay a file along time stamps:
(0) Starting from T[0.0] at game info, (1) the viewer searches for the stamp which temporally (not necessarily textually) follows the current one. (2a) If no stamp specifies a later time: Replaying is stopped. (2b) Otherwise: As soon as that next stamp's point of time has passed, the viewer jumps to there and executes all subsequent properties until it encounters another T property or EOF, then does (1) again.
- For convenience, sgf recording and/or replaying software should be able to pause.
- Proposed by
- blubb
Discussion
blubb: I'd regard such absolute (cumulative) time stamp tags as more promising, because they would allow to replay even highly branched reviews in original order and timing, while also providing all the information BE and WE could define.
LithiumTwo: this would be very nice for complicated reviews.
Format
Compression
A standardized compression scheme for SGF files would be useful, especially for programs making liberal use of flash media (Palm pilot, etc).
Compression scheme should maximize (in order of preference)
- (Minimize) Processor requirement
- Speed
- Size
AshleyF: You seem to be talking about compression of some binary data (voice, player photos, etc.) but I thought I'd mention that Anders Kierulf (creator of SGF) has implemented a simple compression scheme in SmartGo that applies to game records. It greatly reduces file size for large collections while still maintaining an SGF-like syntax. For example, 40.1MB for all of GoGoD as a single SGF collection compresses down to 15.7MB as an SGC. Check out:
http://www.smartgo.com/HTML/index.html?compressedgamecollections.htm
Malweth: I was talking about compression of the text data. Text such as an SGF can be compressed by 60-80% using RAR or ZIP algorithms. I wasn't aware of the simple method being used by Smartgo (I did realize there was a different file format used by this program). I do see problems with this, however - instead of a bulky compression (complete file) that is done and un-done by a compression scheme - once variations are added in the middle of the SGC sequences, the group must be split - a simple variation could actually end up adding more to the file size than the variation sequence actually requires. In any case, some type of method would be useful if added to the specification (not just as a recommendation).
Collection
A standardized SGF collection file would help put multiple SGF files into a single SGF collection. These files should contain a table of contents.
Such a standardization would be useful for SGF databases and collections. The (optional) compression scheme should also apply to SGF Collection files.
AshleyF: The SGF spec already includes the idea of collections; just by including multiple game trees in one file (see
http://www.red-bean.com/sgf/sgf4.html#ebnf-def). Not all clients support it though. SmartGo, to name one, has nice support for it and builds a 'table of contents' view as you suggest above:
http://www.smartgo.com/HTML/index.html?gamecollections.htm.
Transfer Protocol (Single node or branch)
Malweth: A standard protocol to transfer a single node or branch of an SGF file would be useful. This would make collaboration in SGF format possible. It seems likely that the Ultimate Go Server project will define such a protocol.
This need have no firm basis in SGF, but staying as close as possible to the SGF standard would be useful for databasing these collections.