Hi guys
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...
Essentially it was a pragmatic decision.
Of course it would be nice to have a modern replacement format. I very
much like the idea of JSON, not so much the idea of XML. One just has to
be careful that it is not dropped and forgotten like XGF!
Anyway, here I just wanted to present my format and offer my experience
about how to do/handle recordings of games. I thought a lot about it and
also about how to implement it (and what issues arise there).
For me RGF is to SGF like AVI/MKV (container/format) is to DIVX/MPEG
(codec)... Essentially my prototype feeds some existing SGF editor "SGF
and editing frame data" and similarly it catches all SGF commands and
editings and stores those information in a big RGF container...
One main issue I e.g. ran into with this container approach was:
How to propagate meta-game information?
I would be curious what you guys think about it and how you would
support game recordings in some future format...
Best
Jonas
On 08/18/2012 02:01 PM, Don Dailey wrote:
One of these suggestions come around every year or so. It used to be
that "we should use XML" and we would hear that a couple of time per year
or so.
Personally I don't care for SGF but I'm a firm believe that if it's not
broken, don't fix it. I suggest you simply build a tool to translate
from and to XML and publish that tool. There could be javascript and php
versions of those routines and perhaps also java and other languages.
I do appreciate json and believe it to be elegant and if this wheel were
not already invented I probably would be in favor of json.
Don
On Sat, Aug 18, 2012 at 7:48 AM, Petr Baudis <[email protected]> wrote:
Hi!
On Fri, Aug 17, 2012 at 09:07:19PM +0100, Jonathan Chetwynd wrote:
SGF has rather limited metadata, JGF could standardise at least part
of this...
examples might include:
Location: ie GPS or similar
PC[]
Timing of moves see javascript date object
BL[], OB[] etc.
I think the most obvious representation as JSON is a straightforward
syntactic translation from SGF, and a common chunk of javascript code
can serve as that... The next step can be to have an option to generate
SGF.json directly but I don't see a great case for that except for
optimization of particular webapp setups.
Petr "Pasky" Baudis
_______________________________________________
Computer-go mailing list
[email protected]
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
_______________________________________________
Computer-go mailing list
[email protected]
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
_______________________________________________
Computer-go mailing list
[email protected]
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
