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

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

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.

--