super-tux-devel

[Super-tux-devel] Next IRC Meeting

[Ingo R. <gr...@gm...>]

I think its time to schedule a new IRC meeting, this time with the
topic "Level building". So that we can introduce people to the level
editor, discuss issues with building good levels, level testing,
missing tiles, style guide, ie. simply give people a general
introduction on how to build levels and answer questions that people
will have. Prerequirement for this would be:

a) a working editor
b) all new tiles useable in the editor
c) a level fileformat
d) a tile fileformat
e) hard limits for the gamemechanics (ie. jump-height/width)

Issue a seems to be meet, we actually have two working level editors.

Issue b however isn't meet, mostly due to issues c and d.

Issue e is half done, ie. I would suggest 4 tiles for the jump height,
5 for accelerated jump (see milestone1 site for more info), not sure
if everybody agrees here and jump-width is an unsolved issue. However
this don't have to be completly hard-limits, but they should be hard
enough to keep the number of tweeks needed for the levels low.

If we can fix issues b,c,d till the weekend I would suggest:

Sat March 13 20:00 GMT 2004

as a date, is that doable or are there any showstoppers?

-- 
WWW:      http://pingus.seul.org/~grumbel/ 
JabberID: gr...@ja... 
ICQ:      59461927

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

[Ricardo C. <ri...@ae...>]

 I could implement the use of files for tiles, but we need to agree with a=
=20
file format. As I said before, the INI-like file format would be, IMO, the=
=20
one that fits better with this. It is powerfull more than enough and very=20
easy to edit.

 March 13 looks like a fine date to me.

Ricardo Cruz

Em Segunda, 8 de Mar=E7o de 2004 11:56, o Ingo Ruhnke escreveu:
> I think its time to schedule a new IRC meeting, this time with the
> topic "Level building". So that we can introduce people to the level
> editor, discuss issues with building good levels, level testing,
> missing tiles, style guide, ie. simply give people a general
> introduction on how to build levels and answer questions that people
> will have. Prerequirement for this would be:
>
> a) a working editor
> b) all new tiles useable in the editor
> c) a level fileformat
> d) a tile fileformat
> e) hard limits for the gamemechanics (ie. jump-height/width)
>
> Issue a seems to be meet, we actually have two working level editors.
>
> Issue b however isn't meet, mostly due to issues c and d.
>
> Issue e is half done, ie. I would suggest 4 tiles for the jump height,
> 5 for accelerated jump (see milestone1 site for more info), not sure
> if everybody agrees here and jump-width is an unsolved issue. However
> this don't have to be completly hard-limits, but they should be hard
> enough to keep the number of tweeks needed for the levels low.
>
> If we can fix issues b,c,d till the weekend I would suggest:
>
> Sat March 13 20:00 GMT 2004
>
> as a date, is that doable or are there any showstoppers?

=2D-=20
A man paints with his brains and not with his hands.

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

[Ingo R. <gr...@gm...>]

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).


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)))

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.


Another way which I would also find interesting is directory based
level format, ie. a level is represented as a directory:

$ 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.

-- 
WWW:      http://pingus.seul.org/~grumbel/ 
JabberID: gr...@ja... 
ICQ:      59461927

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

[Ricardo C. <ri...@ae...>]

Em Segunda, 8 de Mar=E7o de 2004 15:41, o Ingo Ruhnke escreveu:
> 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).
>

 Nice to have a vote, would like to hear from Tobias.
 About the level file, I just suggested the use of the ini-like file as an=
=20
alternative to the current one, that is hard coded readed and hasn't any=20
flexibility. Of course, in the future, INI-like format would not be that go=
od=20
to use to make enemies position pixel-based or implementing moving platform=
s=20
or places that would be creating enemies all the time...

>
> 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 don't think that file format to be powerfull enough. Futhermore, an ini=
=20
could be used like this:

[LEVEL]
version=3D1
name=3DHello World
enemies_number=3D2

[ENEMY0]
type=3Dsnowball
xpos=3D11
ypos=3D10
[ENEMY1]
type=3Dicecube
xpos=3D11
ypos=3D10

[TILEMAP]
rows=3D3
row0=3D 1 2 3 4 5 6 1 414 23 4324
row1=3D 1 2 3 4 5 6 1 414 23 4324
row2=3D 1 2 3 4 5 6 1 414 23 4324


 The enemies_number and rows entries could even be omitted.


>
>
> Another way which I would also find interesting is directory based
> level format, ie. a level is represented as a directory:
>
> $ ls foobar.supertux/
> =3Dmap.data
> =3Dname
> =3Ddefault-archive
> =3Dwidth
> =3Dheight
> $
>
> 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.

 That looks interesting, but managements and editing doesn't sound much=20
appealing to me,

Ricardo Cruz

=2D-=20
A fool and his honey are soon parted.

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

[Christopher A. W. <cr...@li...>]

I'm sorry... I'm probably not understanding all of this... are we
planning to build scripting of any sort (python, perl... preferably
python, IMHO) into this, for the action of baddies and such?
Just wondering.

Christopher Allan Webber


|
The bottom line

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.

-- 

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.
-- 

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

[Ricardo C. <ri...@ae...>]

Hi,

 I just remembered about the today's meeting! Don't miss it! :)

check GMT time at:
http://wwp.GreenwichMeanTime.com/home.htm

Ricardo Cruz

Em Segunda, 8 de Mar=E7o de 2004 11:56, o Ingo Ruhnke escreveu:
> I think its time to schedule a new IRC meeting, this time with the
> topic "Level building". So that we can introduce people to the level
> editor, discuss issues with building good levels, level testing,
> missing tiles, style guide, ie. simply give people a general
> introduction on how to build levels and answer questions that people
> will have. Prerequirement for this would be:
>
> a) a working editor
> b) all new tiles useable in the editor
> c) a level fileformat
> d) a tile fileformat
> e) hard limits for the gamemechanics (ie. jump-height/width)
>
> Issue a seems to be meet, we actually have two working level editors.
>
> Issue b however isn't meet, mostly due to issues c and d.
>
> Issue e is half done, ie. I would suggest 4 tiles for the jump height,
> 5 for accelerated jump (see milestone1 site for more info), not sure
> if everybody agrees here and jump-width is an unsolved issue. However
> this don't have to be completly hard-limits, but they should be hard
> enough to keep the number of tweeks needed for the levels low.
>
> If we can fix issues b,c,d till the weekend I would suggest:
>
> Sat March 13 20:00 GMT 2004
>
> as a date, is that doable or are there any showstoppers?

=2D-=20
=2D- I have seen the FUN --

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

[Michael G. <mi...@ge...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ricardo Cruz wrote:
| Hi,
|
|  I just remembered about the today's meeting! Don't miss it! :)
|

Gah, I missed it.  is there a log somewhere?

- --Mike
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAU/kCrJDiig1GCW0RAngzAJ495t/S/hq8FgoIrJZkN2jfkB2PsACbBmD9
QrteHb+Aoqy0A1aBZR8wZR8=
=Et1R
-----END PGP SIGNATURE-----

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

[Ricardo C. <ri...@ae...>]

 Stupid me, there was no meeting, sorry :(

Ricardo Cruz

Em Domingo, 14 de Mar=E7o de 2004 06:17, o Michael George escreveu:
>
> Ricardo Cruz wrote:
> | Hi,
> |
> |  I just remembered about the today's meeting! Don't miss it! :)
>
> Gah, I missed it.  is there a log somewhere?
>
> - --Mike

=2D-=20
The Bible is not my Book and Christianity is not my religion.  I could
never give assent to the long complicated statements of Christian dogma.
=2D Abraham Lincoln