On 08/19/2012 03:14 AM, Petr Baudis wrote:
Hi!
On Sat, Aug 18, 2012 at 03:18:36PM +0200, Jonas Jermann wrote:
I don't know if this is the right time/place. But I wanted to
mention that I developed my own gaming format to store store
time-accurate recordings of go lectures/games together with optional
media.
In that area SGF is certainly lacking. What I did was: I tried to
keep as much of the SGF syntax as possible (i.e. "tried" to keep it
backwards compatible) and break as few things/assumptions as
possible.
For more details please check it out here:
https://github.com/jjermann/rgf
resp.
https://github.com/jjermann/rgf/blob/master/DOCS/RGF.txt
I really tried to think it through and also made a complete
prototype that already works quite nicely (at least with firefox).
My decision to use an extension of SGF is:
- SGF is already very nice to store tree data, compared to e.g. xml/XGF
or some other binary formats:
o It can be edited by hand
o It is small
o Everyone/most (non-asian) softwares already use it, so
import/export is easier and writing/adjusting a parser is easier
- SGF actually already has _almost_ everything I needed
- It is easy/easier to "enrich" an SGF with time sensitive data
- RGF is actually like a wrapper/container around SGF, so all old SGF
editors can still be used and can easily be extended for
recording...
I did not understand your example in RGF.txt well. I'm confused by
several points:
(i) Is there any advantage in having RGF files a tree of nodes instead
of just a timestamped sequence of actions given that the latter is
exactly what a RGF player will convert it to and it can refer to the SGF
file for the actual variation? If so, why not just keep all the
information in the SGF tree? To have e.g. stones appear gradually, you
can just split AB[]s etc. to multiple nodes, which SGF readers should
handle fine too?
That's another possibility. The main issue with a list is that you need
to reference tree positions somehow. And for several purposes this
reference should better be absolute during the course of a game, not
relative to the current "SGF position". Also in the end the
"player/recorder" will probably need both, the list and the tree.
(ii) In each GS/GD node of the SGF file, you repeat full game
information.
The idea is to provide "snapshots" of certain game moments that can be
handled by classic sgf viewers. The main SGF file is completely
backwards compatible and can be viewed by any old viewer.
> Why all this duplication? What semantics should SGF editors
> adopt regarding changing game information and how should SGF viewers
> handle changes in game information?
That's what I meant when I talked about "propagating meta-game
information". At the moment all meta-game information is contained in
the main sgf file (which can be read by any old sgf viewer) and can only
be changed there. Each recording is assumed to be based on one game, so
it is assumed that none of those meta-game information changes during
the recording, resp. any changes would be applied to the main sgf, not
the rgf. That main SGF file then references the (separate) RGF file (and
as just mentions already has all its meta-game information). A player
that has RGF implemented could then load the recording.
This approach makes the RGF format very simple since there are much less
things to parse. The meta-game parsing is up to the editor for the main
SGF file...
(iii) Zip container is usually preferred for such bundles since you
can easily access random files without loading and scanning the whole
bundle file. Is there a reason why you picked tar instead?
No reason. I'm more used to tar, so zip might be better.
Best
Jonas
_______________________________________________
Computer-go mailing list
[email protected]
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
