Forum for Smart Game Format
Game collection format [#2434]
RueLue: In a KGS-wishlist (topic collection file) a user complained about CGoban, cutting off a part of a games collection, when saving edits. I checked it and found :
a) Drago produces a collection file which lead to the described problem.
b) Looking inside the file, it showed the structure
(;rootdata;move;move;...)(;rootdata;move;move;...)(...)
As I understand the format description, the right structure would be
(;rootdata(;move;move;...)(move;move;...)(;...))
So Drago (here vers.4.10), star under the Swiss army knives of Go progams, produces files, not compliant with the format description. - Where is my error?
Oh - where in this structure is the game info?
Drago does it correct way.
(;rootdata(;move;move;...)(;move;move;...)(;...))
is correct way to present variations (within one game). Note one added ";" in this.
(;rootdata;move;move;...)(;rootdata;move;move;...)(...)
is correct way to present game collection. Each game may also contain variations.
RueLue: Thank you. I didn't reed the format description carefully enough. So we have the normal game file, one game only and the collection file with normal games one after another: (game)(game)(game)(...).
There is also the description of game info:
When merging a set of games into a single gametree, game infos are stored at the nodes where a game first becomes distinguishable from all other games in the tree.
but then it writes, that the game info is only one time allowed in the tree:
There may be only one game-info node on any path within the tree, i.e. if some game-info properties occur in one node there may not be any further game-info properties in following nodes: a) on the path from the root node to this node. b) in the subtree below this node.
The format description is written for people with a master in informatics, not for me. :-)
RueLue: I think, now I've got it. This is the other possible games file, similar to a collection, but not a collection in the sense of the format description:
(;rootdata;move(;gameinfo;move;...);move(;gameinfo;move;...);gameinfo;move;...)
I stumbled over the ![[ext]](images/extlink.gif)
example file, where the rules were repeated at appropriate places. jEdit with the syntax file for the sgf format showed the structure. Important here is, what is root data and what is game info, what is game tree and what collection.
sorry you are mistaken again
every game (a gametree in the sgf speak may has its own rootinfo.)
a collection is a number of games
so every game in the collection may have its own rootinfo.
maybe it is easiest to see the collection as a forrest of many tree's.
Every tree has only one trunk, but tthat doesn't mean that there is only one trunk in the forrest.
for converting many single games to one collection you just copy and past them into one file. don't change anything in the individual games. (don't make things more complicate dthan nescesary)
in a game collection it is possible to have games on different sized boards or even different games but SZ and GM are root properties.
.
When merging a set of games into a single gametree, game infos are stored at the nodes where a game first becomes distinguishable from all other games in the tree.
PB, PW, RB, RW (ratings), RE(result) .... etc are probably meant here.
I doubt there exist programs which can deal with such files. Probably most programs would either complain (and refuse to open such files), or they ignore these properties in non-root nodes (but preserve them), or in the worst case they could even silently delete these properties in non-root nodes.
One could also discuss, whether it is not better to put such properties at the last move of the game. This way nothing must be changed when more variations/other games are added to the tree (or moves behind the end of the game).
Also, (theoretical question), what happens when two people play exactly the same game? (you need two pairs of PB/PW-properties in the final node)
![[Welcome to Sensei's Library!]](images/stone-hello.png "Sensei's Library")