Re: [Super-tux-devel] Next IRC Meeting

[Tobias <tob...@gm...>]

One addition. :)

We should decide for one file-format and therefore for one
parser, which gets implemented in SuperTux. Wasting energy (for the
first implementation and maintaining) to write one parser esspecially
for config files and another one for the levels and another one for
scripts etc. is something we should avoide.
Let's decide for a powerful way to parse data and use it throughout
SuperTux.

Greetz...

Tobias Gläßer

Am Mo, den 08.03.2004 schrieb Tobias Gläßer um 18:03:
> Am Mo, den 08.03.2004 schrieb Ingo Ruhnke um 10:41:
> > Ricardo Cruz <ri...@ae...> writes:
> > 
> > >  I could implement the use of files for tiles, but we need to agree
> > > with a file format. As I said before, the INI-like file format would
> > > be, IMO, the one that fits better with this. It is powerfull more
> > > than enough and very easy to edit.
> > 
> > For the tile-format I am fine with .ini, it serve the purpose there
> > good enough. For the levelformat however its not that good, yep, it
> > would work for milestone1, but it wouldn't win a price for eleganc
> > (ie. simply misses any way to handle structured data across multiple
> > levels).
> 
> Only copying the .ini style is not very innovative. :)
> .ini like file formats could make the deal for current SuperTux needs,
> but when I think of more complicated stuff and SuperTux's beyond 0.1
> future, I'm sure this can't be our choice. Why? Think alone of scripting
> abilities and you'll agree.
> 
> > I am personally happy with the lispreader library which I used in
> > Construo (no extra library dependency, since its just two files that
> > can be assimilated):
> > 
> > http://www.complang.tuwien.ac.at/~schani/lispreader/
> > 
> > It provides a way to read in lisp-like S-Expressions and returns a
> > parse-tree. Levelformat itself would then look like:
> > 
> > (supertux-level
> >   (version 1)
> >   (properties
> >     (name "Hello World")
> >     (width 500))
> >   (enemies
> >     (snowball (pos 11 10))
> >     (icecube (pos 10 10)))
> >   (tilemap 
> >     (data 1 2 3 4 5 6 1 414 23 4324
> >           1 2 3 4 5 6 1 414 23 4324
> >           1 2 3 4 5 6 1 414 23 4324)))
> 
> I've to admit that this format is very promising and I already took
> a look into the implementation. I'm not sure, if this API fits all
> our needs, but possibly we could write a wrapper around it and even
> extend it's functionality. For example we could extend it with
> gzip compression, which is really easy to implement.
> 
> Don't get me wrong I didn't decide anything regarding to this issue yet.
> Implementing our own innovative file format with SuperTux 1.0 needs in
> mind could be another solution. A time consuming one, but for sure a
> innovative one.
> 
> > Advantage would be that its trivially to parse in Lisp/Scheme like
> > languages, parsers for perl and python exists too, but its not that
> > widespread as XML.
> 
> The widespreadness is a non-issue. :) At least the lisp format isn't
> as bloated as the XML approach.
> 
> > Another way which I would also find interesting is directory based
> > level format, ie. a level is represented as a directory:
> 
> I guess every developer has thought about such a design at some point.
> But in SuperTux's case this isn't the way to go IMHO. :)
> 
> > $ ls foobar.supertux
> > =map.data
> > =name
> > =default-archive
> > =width
> > =height
> > $
> > 
> > Each file there contains then the relevant data (ie. tilemap data gets
> > its own file, level name gets its own name, etc.). Never used that in
> > practice, but its used in both QMail and Arch and has the advantage
> > that it is easy to parse from all languages, even bash, since there is
> > after all not much to parse, but just a directory tree to read in.
> > Disadvantages are of course that its a bit obscure to edit with a
> > text-editor, since its a multi-file format.
--