# Level File Type/Format<

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

## Recommended Posts

So i've successfully created one game in the past and now i'm in the process of writing a breakout clone and one thing i want to do is actually have levels that are loaded from disk.  One thing i keep going back and forth on is how to store to the disk, or rather what file type.  Right now i'm considering XML and finding a XML parser(i don't even know how to use 3rd party libraries other than like DX XD).  I considered XML because i know its quite flexible, then it dawned on me i have no idea how to layout a good XML file.  Right now all thats going to be stored is the name of the level, and the blocks, with each block having an x,y, width, height, and texture file name.  Problem is i'm not sure how to store that in a way that makes sense.  Right now i have it like this


<level>

<name>Level 1</name>

<blocks>

<block>
<x>0</x>
<y>0</x>
<width>20</width>
<height>10</height>
<texture>block.png</texture>
</block>
</blocks>
</level>


each level will have its own XML file that gets loaded at the start of a level of course.  But the problem i ran into is having more than one block of course.  should i instead be doing like block1, block2, etc instead of just block?  Thats whats confusing me.  I'm sure as i go there might be more stuff stored, but for now thats all i have.   I would really appreciate some responses and hope this is the right sub section.

##### Share on other sites

Your current format is better than doing <block1>, <block2>, etc, etc. The file processing code for that would be horrendous.

Your current structure is ok. The only other thing you could do would be to use attributes of the block rather than individual labels for all of a block's properties, such as:

<block texture="block.png" X="480" Y="352" Width="32" Height="32" />

It would probably be easier and the processing code would be prettier with such a layout.

##### Share on other sites

One problem with XML is that it isn't always obvious how to structure a "good" document, and sometimes it's a matter of taste, too. For example, you could (and I would prefer to) write:

<block x="0" y="0" width="20" height="10">
<texture>block.png</texture>
</block>


Neither one is "more correct" or "less correct", really. To me, this "feels better" because all levels have an origin and a width/height pair, but an individual level could have zero or one texture, or twenty.

Which is why I usually decide for one format, but only use XML as a "source format" and compile this into something binary that the actual program later reads, using a script (for me, that's PHP since it's the one I'm most comfortable with, but others would likely use either perl or python -- it doesn't really matter).

Something that works fine for me is a binary format similar to COFF, that is a four-cc followed by a size, followed by a blob of data (which can be laid out as a struct). This trivially maps to an XML or similarly structured document.

Of course, compiling your XML has a serious disadvantage if you want your users to be able to make their own levels. Everybody can write XML in a text editor, and 99% of all people will get it right just by looking at one of your levels. That's not the case with a binary file, obviously. But if that doesn't matter to you (doesn't to me) then this is fine.

Edited by samoth

##### Share on other sites
post deleted due to the form eating my XML samples.

##### Share on other sites

I'd like to add two things.

The first: If you know you will have multiple nodes with the same name (for instance, "level" or "block"), always make sure to group them under a single node (e.g. "levels" and "blocks"), as it becomes easier to parse afterwards. I see you've done this with your blocks, but not with your levels yet:

<levels>
<level1/>
<level2/>
</levels>

The second: As samoth has stated, "good" XML isn't really defined all too well. There's no difference between storing data as attributes or children, other than visual appeal.

This is just my preference, but I like to differentiate my data into the following groups:

1. data that is absolutely required or the program will fail
2. data that can default to built in values, and isn't necessarily required until later

For instance, the texture file I assume is an absolute requirement, because you can't create a block without a texture. Coordinates and size on the other hand don't prevent construction of a block object if they aren't specified, because they could default to 0 (sure the block won't be visible, but you could construct it anyway).

Once I've organized my data into those two groups, I like to keep essential (1) data as XML attributes, and optional (2) data as children:

        <block texture="block.png">
<x>0</x>
<y>0</x>
<width>20</width>
<height>10</height>
</block>

But again, this is solely my preference.

Edited by TheComet

##### Share on other sites
Typically, if you did need to identify the blocks, you would add an "id" attribute/sub-element rather than having each element have a distinct name.

##### Share on other sites

Thanks for the advice guys!  I decided to go with format like samoth said, which is what i was leaning towards in the first place.  Now i just need to get tinyXML added to my project so i can actually load the XML file.

##### Share on other sites

I'd do something more like this:

<blocks width=40 height=20>
<block id=1 image="redblock.png" strength=1 />
<block id=2 image="blueblock.png" strength=3 />
...
</blocks>

<levels>
<level id=1>
<row x=10 y=10 blocks="11122111" />
<row x=10 y=30 blocks="11222211" />
<row x=10 y=50 blocks="12200221" />
<row x=10 y=50 blocks="12200221" />
<row x=10 y=70 blocks="11222211" />
<row x=10 y=90 blocks="11122111" />
</level>
</levels>


That's the general Idea at least

Edited by BeerNutts

##### Share on other sites

I'd do something more like this:

<blocks width=40 height=20>
<block id=1 image="redblock.png" strength=1 />
<block id=2 image="blueblock.png" strength=3 />
...
</blocks>

<levels>
<level id=1>
<row x=10 y=10 blocks="11122111" />
<row x=10 y=30 blocks="11222211" />
<row x=10 y=50 blocks="12200221" />
<row x=10 y=50 blocks="12200221" />
<row x=10 y=70 blocks="11222211" />
<row x=10 y=90 blocks="11122111" />
</level>
</levels>


That's the general Idea at least

It can be made even more user-editable by reducing the "map" to plain text without obnoxious markup and computing as much of the block coordinates as possible. Let's assume "." is an empty space:

<level name="Example">
<blocks width="48" height="16">
<!--more intuitive symbols like r, g and b would be better-->
<block name="weak blue" image="blue16x48.png" strength="1" symbol="1"/>
<block name="weak green" image="green16x48.png" strength="1" symbol="0"/>
<block name="medium red" image="red16x48.png" strength="3" symbol="2"/>
</blocks>
<layout rows="12" columns="10"><!--some explicit space added around the square of blocks-->
..........
..........
..........
.11122111.
.11222211.
.12200221.
.12200221.
.11222211.
.11122111.
..........
..........
..........
</layout>
</level>


Given the block size and the layout size of this particular level (others could use different block sizes and unusually wide or narrow or deep playfields) the game engine can figure out where every block goes; the layout defines a rectangle, a fixed amount of space is added at the bottom (to have a constant distance between the paddle and the bottom row of the layout) and the resulting variable-sized rectangle can be simply centered in the window.

The plain text in the "layout" element can be stripped of whitespace (to allow indentation) and validated to confirm that there are the correct number of rows and columns.

##### Share on other sites

i specifiy the width and height of each block for a reason ;)  I don't plan on having a grid like layout, i want to be able to create larger and smaller blocks and not have a specific grid of any sort with placement of them.

##### Share on other sites

i specifiy the width and height of each block for a reason ;)  I don't plan on having a grid like layout, i want to be able to create larger and smaller blocks and not have a specific grid of any sort with placement of them.

That's fine, just move those specifiers into the block definitions (just give a block an id, width height, and what sprite to use, or possibly, don't give a width and height, but let the program determine width and height from the sprite).

But I still would not suggest having every block that is placed for a level have the markups around it. Otherwise, you'll have a massive xml file for very little information.  Most of your data will be the level layout with which blocks are placed where, so mine or LorenzoGatti suggestion would still work.  Obviously, if blocks are different size, then the textual representation wouldn't line up, but that won't be possible anyway with different sized blocks.