• Advertisement
Sign in to follow this  

Loading Levels

This topic is 1802 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've done some searching but couldn't find a topic that was quite what I wanted so I apologize if this has been asked multiple times.

 

I'm currently working on a 2D platformer game and am contemplating how to deal with loading levels. I'm using [url=http://libgdx.badlogicgames.com/]LibGDX[/url] as my framework. I was wondering what you guys prefer to do for handling this. I might like to add a level editor eventually so I was thinking about having a simple text file with the maps and different numbers representing different tiles, i.e.

0022200000
0000121000
0111012200
1110020010
0111210011
0120101010

Where 0, 1, and 2 represent different tile images. Then I could just load it in one level at a time. What are my other alternatives? How do you prefer loading levels? Thanks,

 

David

Share this post


Link to post
Share on other sites
Advertisement
When working indexed tiles in the past I usually started out with a small tileset and implemented a loader that would read from text files as you described. Once I was happy with the runtime I'd create a map editor that saved to a simple binary format something like this:

str MAPF - first 4 bytes are a fourcc to verify that the file is the correct format
uint32 length - indicating length of the rest of the file (total file length minus 8) so I can read the rest into memory easily

uint32 width - in tiles
uint32 height
uint32 layers
uint32 zero - for alignment

Then it's just raw byte-width tile id's, row followed by row.

At runtime the dimensions would be loaded into a struct and that would be fed to a loader function that turned each width x height bytes into a layer and spat out the resulting map object. Internally the map class just stored each layer in the form of the data which had been read. I also supported animated tiles, so the map included some functionality for dealing with that. By associating the map object with a tileset texture it could be prompted to render at any x,y offset. In D3D it's simple to do because the D3DXSprite batcher can do the sorting for you, but in an API that doesn't have that you'd want to sort by tile to cut rendering time.

'Tiled' is in vogue at the moment. It's a nice little tool. You may want to look at that before going hardcore. I believe there's a lib for loading Tiled maps as well, though I don't know what it loads into. Honestly if I were to do this again I'd go the Tiled route.

http://www.mapeditor.org/

Share this post


Link to post
Share on other sites

I mean with the example you gave, you could just use a .bmp file and represent red as 1 white as 0 and blue as 2.

Why waste 54 bytes on a header? Just use raw data.

 

to save:

 

FILE * fileLevel;

fileLevel = fopen(NAME,"w");

fileLevel = fopen(NAME,"a");

for(int i = 0; i < LEVELHEIGHT; i++)

{

for(int j = 0; j < LEVELWIDTH; j++)

{

fputc((char)LEVELDATAARRAY[i][j],fileLevel);

}

}

fclose(fileLevel);

 

to open:

 

FILE * fileLevel;

fileLevel = fopen(NAME,"r");

for(int i = 0; i < LEVELHEIGHT; i++)

{

for(int j = 0; j < LEVELWIDTH; j++)

{

LEVELDATAARRAY[i][j] = fgetc(fileLevel);

}

}

fclose(fileLevel);

Edited by ProvenDantheman

Share this post


Link to post
Share on other sites

I mean with the example you gave, you could just use a .bmp file and represent red as 1 white as 0 and blue as 2.

Why waste 54 bytes on a header? Just use raw data.

 

to save:

 

FILE * fileLevel;

fileLevel = fopen(NAME,"w");

fileLevel = fopen(NAME,"a");

for(int i = 0; i < LEVELHEIGHT; i++)

{

for(int j = 0; j < LEVELWIDTH; j++)

{

fputc((char)LEVELDATAARRAY[i][j],fileLevel);

}

}

fclose(fileLevel);

 

to open:

 

FILE * fileLevel;

fileLevel = fopen(NAME,"r");

for(int i = 0; i < LEVELHEIGHT; i++)

{

for(int j = 0; j < LEVELWIDTH; j++)

{

LEVELDATAARRAY[i][j] = fgetc(fileLevel);

}

}

fclose(fileLevel);

 

Easier to modify, easy to visually see etc. Im ok with wasting 54bytes on a header file, when I have those added benefits!

Share this post


Link to post
Share on other sites

Back in time I used... believe it or not... OpenOffice Calc. Exporting to .csv. It worked quite well. In retrospect, it worked better than my current approach which is giving me headaches right now.

The cool thing about using CSV is that you can have many, many tiles, with many, many properties and they'll still align as you want them to when opened in Calc. By contrast, a pure txt file would quickly require a lot of padding to align on number digits and extra annotations.

 

That said, I prefer binary blobs for runtime.

Edited by Krohm

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement