super-tux-devel

[Super-tux-devel] File format

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

Hey there,=20
=20
 To implement tiles like the ones decribed in the development page,=20
I think we need to:=20
- create a config file with all the tiles and the information about=20
them;=20
- make tiles code flexible;=20
- improve collisions between tiles and the player.=20
=20
=20
 My point is that we need a file format, since the level and=20
highscore ones should be more flexible and use a common system to=20
read them.=20
 In my opinion, we don't need a very complex file format, so I vote=20
for a kde/windows (.ini) like file format.=20
 This is how my BobbleBubble game levels looks like:=20
=20
=AB=20
[LEVELS]=20
totallevels=3D3;=20
=20
[LEVEL1]=20
tile=3Ddata/pattern1.bmp;=20
redshadow=3D240;=20
greenshadow=3D80;=20
blueshadow=3D220;=20
redbackclr=3D0;=20
greenbackclr=3D255;=20
bluebackclr=3D255;=20
pla1-row=3D10;=20
pla1-col=3D3;=20
pla2-row=3D10;=20
pla2-col=3D19;=20
row 0=3D11111111111111111111111111;=20
row 1=3D10000000000000000000011111;=20
row 2=3D10000000000000000000011111;=20
(....)=20
row27=3D11111111111111111111111111;=20
=BB=20
=20
 And this is a function that reds an entry, by feeding it with the=20
file path, group and entry name:=20
=AB=20
char* filemanager(const char *path, const char *group, const char=20
*entry)=20
{=20
FILE *file =3D fopen(path, "r");=20
if (file =3D=3D NULL)=20
	{=20
	cerr << "File: " << path << " couldn't be open\n";=20
	return NULL;=20
	}=20
=20
char buffer[1024];=20
static char entryvalue[1024];=20
char *ptr;=20
char *entryptr;=20
bool groupFound =3D false;=20
bool entryFound =3D false;=20
=20
while ((ptr =3D fgets(buffer, sizeof(buffer), file)) !=3D NULL)=20
	{=20
	if (ptr[0] =3D=3D '#')	// comment=20
		continue;=20
=20
	if((groupFound =3D=3D true) && ((entryptr =3D strstr(ptr, entry))=20
!=3D NULL))=20
		{=20
		entryptr +=3D strlen(entry);=20
=20
		char *semicolonptr;		// will point to ;=20
		strcpy(entryvalue, entryptr);=20
=20
		if ((semicolonptr =3D strchr(entryvalue, ';')) =3D=3D=20
NULL)=20
			cerr << "ERROR: ; is missing in line: " <<=20
ptr << endl;=20
		else=20
			*semicolonptr =3D '\0';=20
		entryFound =3D true;=20
=20
		break;=20
		}=20
	if (ptr[0] =3D=3D '[')	// group symbol: [=20
		{=20
		groupFound =3D false;=20
		if (strstr(ptr, group) !=3D NULL)=20
			groupFound =3D true;=20
		}=20
	}=20
fclose(file);=20
if (entryFound =3D=3D false)=20
	{=20
	cerr << "ERROR: the " << entry << " entry was not found on "=20
<< group << " group in the file " << path << " ." << endl;=20
	return NULL;=20
	}=20
return entryvalue;=20
=20
// example:=20
//filemanager("/home/rick2/.kde/share/config/kppprc", "[Account1]",=20
"Password=3D");=20
}=20
=BB=20
=20
 What do you think?=20
=20
Ricardo Cruz=20
_________________________________________________________
Screensavers e wallpapers gr=E1tis: http://freegames.online.pt

Re: [Super-tux-devel] File format

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

ri...@ae... writes:

>  To implement tiles like the ones decribed in the development page, 
> I think we need to: 
> - create a config file with all the tiles and the information about
> them;
> - make tiles code flexible; 

Yep, tile-id to filename mapping and collision behaviour of a tile
should be configurable via file and not hardcoded as it is now, would
make it quite a bit easier to add new tiles.

>  My point is that we need a file format, since the level and 
> highscore ones should be more flexible and use a common system to 
> read them. 
>  In my opinion, we don't need a very complex file format, so I vote 
> for a kde/windows (.ini) like file format. 

.ini is as far as I know pretty much unstructured (beside the group
headings of course), its fine for simple name -> value mappings, but
for a level format a little bit more structure is needed. I vote for
.xml, s-expressions (aka lisp stuff) or something based on a scripting
language we use (ie a python list or something like that). In
Windstille my levels currently look kind of like this:

(windstille-level
 (properties
  (name "Hello World"))

 (scripts "level_script.scm")

 (objects
  (igel (pos 10 20)
        (direction left)))

 (tilemap
  (width 10) (height 20)
  (data 
   0  0  0  0  0  0  0  0  0  0
   0  0  0  0  0  0  0  0  0  0
   0  0  0  0  0  0  0  0  0  0
   ...
   8  8  8  8  8  8  8  8  8  8)))

My biggest complains about the current format are basically that
something like name=value looks a lot nicer then deriving the meaning
of a value simply by its position and that there is a simple character
to tile mapping, which limits the number of available tiles character
pretty much (something like 80 when one wants to use just printable
ASCII). It might not be a problem for the 0.1 release, but for later
versions it will become problematic. Currently I have already 44 tiles
and thats just one theme and without much background or variation in
the tiles, so the final number will easily be ten times larger.

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

Re: [Super-tux-devel] File format

[Bill K. <nb...@so...>]

On Thu, Feb 19, 2004 at 07:33:43PM +0100, Ingo Ruhnke wrote:
> My biggest complains about the current format are basically that
> something like name=value looks a lot nicer then deriving the meaning
> of a value simply by its position and that there is a simple character
> to tile mapping, which limits the number of available tiles character
> pretty much (something like 80 when one wants to use just printable
> ASCII).

Heh, yeah, that's the way I often do it.  Sorry :^)

It's for a couple of reasons:

  1. I'm not usually interested in making a level editor for my games,
     so I just hand-code the levels using Emacs ;)

  2. My background is from the Atari 8-bit.  I would often just create
     a special character set ('font') which had the different shapes
     mapped to characters in the ATASCII character set, and then literally
     type them into my code or into a data file.

     Much like I did for BoboBot and SuperTux, except I'm limited to
     printable ASCII, rather than nearly 256 easily-typed and
     easily-printed ATASCII on the Atari ;)

-bill!

Re: [Super-tux-devel] File format

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

Hi Ricardo,

I've already told you about my plans with scripting support in SuperTux
and the old levelformat would have to be dropped when this effort begins.

But until the 0.1 release ( 0.7-0.9 are supposed to have short release cycles)
we should keep it to have enough concistency, so that level creators and designers
don't think their work would be destroyed with every SuperTux version.

Greetz...


Tobias Gläßer