NewsForumsCodeLogsGallerySpecsSearch

To XML or not to XML, that is the question...

BlitzMax Forums/BlitzMax Programming/To XML or not to XML, that is the question...

bregors(Posted 2005) [#1]
.


N(Posted 2005) [#2]
No, it's not practical. Xml is good for anything that would benefit from a written form, such as materials, entity layouts for maps, etc. The actual level data itself? No, it'd just be bloated.


bradford6(Posted 2005) [#3]
maybe a combo:
<?xml version="1.0" encoding="utf-8"?>
<BrEgOrS_game>
      <level name = "First Level">
            <tilemap>
              </file> level_one_file.TIL
            </tilemap>


        </level>
</BrEgOrS_game>



N(Posted 2005) [#4]
That's not valid Xml, bradford O_o


bregors(Posted 2005) [#5]
.


OJay(Posted 2005) [#6]
you could even embed the binary data of "entrance.dat" within the xml file using BASE64 encoding.

would look something like this:
...
 <levels>
    <level name="Entrance" music="snd/mL1.ogg">
        <data encoding="base64">
SGV5IHlvdVwncmUgYWJsZSB0byBk
ZWNvZGUgYmFzZTY0ISB1bmJlbGlld
mFibGUhIDspDQpIZXkgeW91XCdyZS
BhYmxlIHRvIGRlY29kZSBiYXNlNjQhI
HVuYmVsaWV2YWJsZSEgOykNCkhle
SB5b3VcJ3JlIGFibGUgdG8gZGVjb2Rl
IGJhc2U2NCEgdW5iZWxpZXZhYmxlI
SA7KQ0KSGV5IHlvdVwncmUgYWJsZ
SB0byBkZWNvZGUgYmFzZTY0ISB1b
mJlbGlldmFibGUhIDspDQpIZXkgeW
91XCdyZSBhYmxlIHRvIGRlY29kZSBi
YXNlNjQhIHVuYmVsaWV2YWJsZSEg
OykNCkhleSB5b3VcJ3JlIGFibGUgdG
8gZGVjb2RlIGJhc2U2NCEgdW5iZWx
pZXZhYmxlISA7KQ0KSGV5IHlvdVwn
cmUgYWJsZSB0byBkZWNvZGUgYmF
zZTY0ISB1bmJlbGlldmFibGUhIDspD
QpIZXkgeW91XCdyZSBhYmxlIHRvIG
RlY29kZSBiYXNlNjQhIHVuYmVsaWV
2YWJsZSEgOyk=
      </data>
    </level>
  </levels>
...



bradford6(Posted 2005) [#7]
That's not valid Xml, bradford O_o


it was pseudo-XML (new word, I just made it up:) )


great idea OJAY!

<?xml version='1.0' encoding='UTF-8'?>

<game>
    <level difficulty="2" levelnumber="1" name="Welcome to funsville" tilefile="level1.tiles">
        <!-- here are some things in my level -->
        <ball file="ball.png" xpos="0" ypos="100"></ball>
        <cooler file="cooler.png" xpos="100" ypos="100">
            <lunchbox file="lunchbox.png" xpos="100" ypos="100">
                <fooditem file="apple.png" name="Red Delicious Apple"></fooditem>
            </lunchbox>
        </cooler>
    </level>
    <level difficulty="5" levelnumber="2" name="Had enough yet?" tilefile="level2.tiles">
        <!-- here are some things in my level -->
        <weapon file="trebuchet.png" strength="100" weightLBS="350" xpos="0" ypos="100"></weapon>
        <weapon file="crossbow.png" strength="10" weightLBS="25" xpos="0" ypos="100"></weapon>
    </level>
</game>


I think the point is that XML for describing a Level could be very useful.


Robert Cummings(Posted 2005) [#8]
XML is pointless for game formats where you will not be modding.


OJay(Posted 2005) [#9]
yeah, but the point is: using xml *makes* a game modable (to some extend) :)


bradford6(Posted 2005) [#10]
3 good reasons to do this:

1. XML is readable and easily modified
2. XML can be used for level files, configuration files, save game data, etc.
3. This would be a fun way to learn XML for other, more serious applications


bregors(Posted 2005) [#11]
.


OJay(Posted 2005) [#12]
Don't know how many lines a ~500k file would run at base64, but it definately sounds feasible for smaller projects.


its "feasible" for large projects too. i currently have 4 fullprize games installed, which use xml entirely for all content! however they use a compression algorythm to keep the actual files small. zlib (even with lowest compression) does a very good job here...


Ferminho(Posted 2005) [#13]
CrystalSpace 3D does this, it uses xml for everything; maps, materials, sprites, libraries, etc... I think is a good idea if you don't mind the final user messing with it.


bregors(Posted 2005) [#14]
.


bradford6(Posted 2005) [#15]
you can do compression to shrink the size and encryption to protect the integrity of the data.


N(Posted 2005) [#16]
This is something I did a while back, not guaranteed to work well at all though.

What you could do is use Xml and provide a 'compiler' for it, reducing an otherwise large file to a chunk-based format that would be signifigantly smaller. You could compile them at runtime and include an MD5 in the compiled version to check against the existing Xml file, and if the MD5 doesn't match then you rebuild the compiled version.

The advantage of this is loading speed and size. The compiled version could be more tailored to loading straight to memory because you could simple do something like
Stream.ReadBytes( Varptr obj.FirstField, dataSize )

instead of having to enumerate all of the elements and attributes in an Xml file.

Well, just my $.02.