Public Group

# YAML vs JSON vs XML?

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

## Recommended Posts

I'm working on a 2D RPG in Java using LibGdx, and need to find a way to store my game data. The things I've considered are YAML, JSON and XML. I only have experience in working with XML, but the others can't be too hard to learn. What I need to achieve is being able to define items to be generated by listing the components that the item would have and my EntityGenerator would turn them into game objects.

Additionally, I would like to be able to build myself an "Item creator" utility where I can use a GUI to simply check off the components to add for my item and it would add that into the data file.

Any suggestions?

Edited by stein102

##### Share on other sites

I can't really speak to the pros/cons of YML, I wrote a quick and dirty parser for it a while ago for a webapp, but that's my entire experience. As far as JSON is concerned, if you're not using Javascript, there isn't much point. The reason that JSON is so nice in web development is that it is instantly recognized by the browser's JS interpreter as an object so there's no additional parsing necessary. This is only true in Javascript, though. Any other language requires a custom library to interpret JSON.

Personally, I would say work with XML. For one thing, you already know it. For another, a lot of people already know it, so if you end up bringing another person in on your project, they won't be stuck trying to familiarize themselves with a new data format (and if the person you're bringing in isn't at least somewhat comfortable with XML, you might need to ask if they're a good fit).

##### Share on other sites

I think I'll stick to XML like was suggested above. No need to learn extra technologies to achieve something that can be done with a protocol  that I already know.

Does this look like a good structure to you? Or is there a better way?

<?xml version="1.0"?>
<item>
<id>1</id>
<name>sword</name>
<components>
<wieldable></wieldable>
</components>
</item>


##### Share on other sites

I think at the very least you could abbreviate that format -- remember that XML is really meant to be a semantic format -- I might do something like the following:

<item id="1" name="sword" category="weapon">
<description> Just a regular sword.</description>
<components>
<wieldable />
</components>
</item>

There's quite a bit of art to designing and XML schema, but good designs use elements and properties together in a way that reduces redundancy and encourages correct use. You can define your format using a DTD and validate such files before they touch your game or content pipleline.

Keep in mind that <item> might or might not be a valid element in your schema depending on how much commonality all the different kinds of items have with one another. Say, for example, that it makes no sense for some sub-class of items to have any components, but another sub-class of items might require at least one component. You could enforce this just in the DTD, but it could make maintaining the DTD complicated -- it might be better to not have a generic <item> element, but instead have elements for the different subsets, say <weapon> and <potion>. Like I said, there's some art and intuition behind these kinds of decisions, just think carefully about them rather than tossing the first thing that comes to mind together.

Edited by Ravyne

##### Share on other sites

I think at the very least you could abbreviate that format -- remember that XML is really meant to be a semantic format -- I might do something like the following:

<item id="1" name="sword" category="weapon">
<description> Just a regular sword.</description>
<components>
<wieldable />
</components>
</item>

There's quite a bit of art to designing and XML schema, but good designs use elements and properties together in a way that reduces redundancy and encourages correct use. You can define your format using a DTD and validate such files before they touch your game or content pipleline.

Keep in mind that <item> might or might not be a valid element in your schema depending on how much commonality all the different kinds of items have with one another. Say, for example, that it makes no sense for some sub-class of items to have any components, but another sub-class of items might require at least one component. You could enforce this just in the DTD, but it could make maintaining the DTD complicated -- it might be better to not have a generic <item> element, but instead have elements for the different subsets, say <weapon> and <potion>. Like I said, there's some art and intuition behind these kinds of decisions, just think carefully about them rather than tossing the first thing that comes to mind together.

I'm not fully sure what I'll need for my items yet as I'm just starting development. I like the idea of not using a generic <item> element, but using elements for different categories of items there could be. Do you have any other suggestions that I may need to have? I'm sure I'll be running into complications in no time otherwise.

##### Share on other sites

As for the verbosity of XML, it is fairly simple to use zlib to compress the XML. In the case of network transfer, is may be quite worth to spend the extra CPU-cycles and send a XMLZ-file.

You then have the tooling of XML in a fairly (albeit not the most) compact format.

##### Share on other sites

Remember the various security pitfalls of parsing XML from an untrusted source. If you're not doing that, then you're fine though.

##### Share on other sites

As far as I can tell, many systems are moving towards json for config etc. I can't speak for the rest, but I personally switched from xml (or xml-plists actually) to json because editing (and finding errors) is so much easier in json. Not to mention that json can be much more compact while still retaining readability.

My vote's for json.

• 21
• 11
• 9
• 17
• 13