• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
stein102

YAML vs JSON vs XML?

22 posts in this topic

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
2

Share this post


Link to post
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).

2

Share this post


Link to post
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>
1

Share this post


Link to post
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.

0

Share this post


Link to post
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.

0

Share this post


Link to post
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. 

0

Share this post


Link to post
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>

 

I think you could abbreviate that a bit further, by removing the <components> tag, since it is kind of redundant. Any child elements of "item" could be seen as components of the item, and the "description" is one of them.

Personally, I try to put everything in tags and arguments too, since I find it easier to write the parser for with tinyxml.

So I'd write

<description text="Just a regular sword."/>

 

That way, you also avoid the end tags, and get the format a little bit more brief.

 

So this:

 

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

 

or something...

 

That's one problem with xml, so many ways to do it.

But I like it.

Edited by Olof Hedman
0

Share this post


Link to post
Share on other sites

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.

 

 

This is becoming increasingly less true.  Many of the NoSQL databases for example expect and return JSON.  More and more web services are moving from XML to JSON as well.  There are increasingly parsers for JSON in more and more languages, often many times lighter than XML.  Frankly, if you aren't having to describe/discover the data's type, XML is overkill.

 

 

Since you are working in Java ( or C++ is another option here ), I would also consider checking out ProtocolBuffers.  Ultra light weight and better, can actually generate java code to create a Builder for the type you define.

0

Share this post


Link to post
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.

 

this works pretty good IME.

 

though, granted, it is possible to get the speed/compression tradeoff a little better with a specialized binary serialization, but this is a bit more work (IOW: may involve working with entropy-coded bitstreams, ...).

 

a minor issue of XML+Deflate, is that it isn't by itself ideally suited for transmitting a stream of messages, so generally needs to be wrapped in some sort of container. in a typical example, this will be a tag-value, followed by a length, followed by the compressed data.

 

in some cases, it may also make sense to "escape code" the data, such that a tag may never appear in data. this may allow things like resynchronizing with a data stream.

 

 

as for data representations:

I also use S-Expressions to some extent as well, though these are not as widely popular.

 

another option is basically creating a byte-oriented data serialization, and then feeding this through zlib / deflate.

Edited by cr88192
0

Share this post


Link to post
Share on other sites

I've had very positive experiences with Protocol Buffers. They are fast, compact and have text and binary representation (even convertible from one form into the other using just a small tool). They are just so little work and versatile that I am using them for lots if different things: Network protocols, configuration files, save games, ...

 

I have found few libraries that made my life as much easier as protobuf did.

0

Share this post


Link to post
Share on other sites

Protocol buffers looks really nice for anything that isn't a tree. (or am I missing something?)

 

I guess XML is at its best when you have to describe a tree, but I will definitely look into protocol buffers some more for things that isn't, and sending stuff

Edited by Olof Hedman
0

Share this post


Link to post
Share on other sites

Basically all I need this to do is the following:

 

-Have "Item" class and "ItemLoader" class

-ItemLoader reads the data file and creates an instance of item for each item in the file

-Item has very limited fields/methods(Id/description/name)

-ItemLoader reads the data file and adds all components to the item(ex. Consumable, wieldable, weapon, shield, etc.)

-Easy to manipulate via API(Going to be editing and creating items from a GUI)

0

Share this post


Link to post
Share on other sites

Perhaps just wrap it one level higher, so you can easily switch it out depending on the job at hand.

 

At work, we tend to swap between JSON and XML weekly ;)

0

Share this post


Link to post
Share on other sites

Protocol buffers looks really nice for anything that isn't a tree. (or am I missing something?)

 

I guess XML is at its best when you have to describe a tree, but I will definitely look into protocol buffers some more for things that isn't, and sending stuff

message X { 
    optional X x = 1;
    optional X y = 2;
}

This works just fine. Trees!

0

Share this post


Link to post
Share on other sites
<?xml version="1.0"?>
<item id="1">
    <name>sword</name>
    <components>
        <component wieldable="true" />
    </components>
</item>

Is this bad?

0

Share this post


Link to post
Share on other sites


    <components>
        <component wieldable="true" />
    </components>

 

That's a little weird. Why is wieldable a property of component? Isn't wieldable the component? Would you want to define multiple component properties on the same component like <component wieldable="true" throwable="true" />? Are you meant to enumerate all components of the item in a single component? If so, what's the purpose of the <components> parent element? Can a component property ever be false? What does that mean? Why not just leave it out in the first place? Is it more than a binary state?

0

Share this post


Link to post
Share on other sites

Well isn't wieldable just a boolean state? And item can have components, so having a component element can't be that strange? As an (Final Fantasy 7) example, an item would be a sword with name: DragonFang. It can have components such as: spells and materia. Spells are castable and Materia are wieldable or equippable.

 

Or maybe I've just completely misunderstood the XML schema.

0

Share this post


Link to post
Share on other sites

Sure, what you posted succeeds at encoding the information, I just think there are better ways to encode it. Like you said, whether something is "wieldable" or not is a Boolean state, but there's many ways to encode that -- as a property on an element as you've done is one way, the presence of an element named <wieldable> is another. In the former, one has to modify the component element schema every time a new component ability is added (component is going to keep growing too!), in the latter, you just define a new element type and add it to the list of acceptable child elements of <componenents>. In the former, its difficult to add any information about the wieldable-ness of the object -- perhaps its only wieldable by a certain class of character, or requires a certain amount of strength to wield-- in the latter, because wieldable is its own element, it can have its own properties and child elements that further describe it, and everything is neatly organized -- Wieldable might have an entirely different set of properties and children that describe it than Equipable does.

 

This goes back to one of the things I said early on, which is that unlike JSON or YAML, XML is as much a language for describing the data format as it is for exchanging data using said format. Its a truly structured document, rather than a list of information loosely organized by convention alone. Because of this, the way you structure your format has a big impact not only on your data interchange, but also on the effectiveness of other very useful tools in the XML ecosystem, like validators, XSLT, and XPath.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0