Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

XML vs YAML vs JSON for a 2D RPG [duplicate]

Tags:

c++

json

xml

yaml

I can't figure out whether or not to use XML, YAML, or JSON for a C++ 2D RPG.

Here are my thoughts:

  • I need something which is simple to save not just player data, but environment data, such as object (x, y) coordinates; load times; dates; graphics configurations, etc.

  • I need something flexible, easy to use, and definitely light weight, but powerful to handle the above.

Which is the best choice? I have experience with JSON in JavaScript, but not C++. Are there any good references for parsing JSON in C++ if this is the route to go?

Edit

Honestly, if a text file seems like the simplest and most effective solution for something like this (especially if I can just write it to binary), then I'm all ears.

Edit 2

Feel free to provide other suggestions as well.

like image 920
zeboidlund Avatar asked Dec 06 '11 12:12

zeboidlund


People also ask

Is YAML more readable than JSON and XML?

YAML, depending on how you use it, can be more readable than JSON. JSON is often faster and is probably still interoperable with more systems. It's possible to write a "good enough" JSON parser very quickly.

What is the difference between XML JSON and YAML?

YAML stands for “YAML Aint Markup Language“. JSON stands for “JavaScript Object Notation“. XML is “eXtensible Markup Language” whereas YML is not a markup language. XML uses a tag to define the structure just like HTML.

Is YAML better than JSON?

JSON is comparatively faster than YAML. However, if data configurations are small then YAML is better since its interface is much more friendly. JSON has a feature to encode six different data types like an object, array, strings, numbers, null and boolean.

Is YAML the same as XML?

The biggest difference, though, is that XML is meant to be a markup language and YAML is really more of a data format. Representing simple, hierarchical data tends to be more gracefully done in YAML, but actual marked-up text is awkward to represent.


1 Answers

I would use the simplest thing that satisfies your requirements.

If you don't need hierarchical storage, then flat tabular files are so much easier to deal with than anything else. All you have to do is read lines off disk and split on tab.

If you are looking at more of key/value pair type storage (as opposed to lists of things), then INI files can be reasonable. This format has a lot of flexibility, though reasoning about it can less approachable when you start doing more complicated things than it was designed for.

If you need hierarchical, it's possible that JSON would be simpler. There are JSON libraries in wide range of languages, and it sounds like you already familiar.

https://stackoverflow.com/questions/245973/whats-the-best-c-json-parser

sqlite may be another option. There be dragons in SQL, but with a nice C++ wrapper around sqlite, it can be manageable. The primary benefit would be ACID, in my opinion.

The YAML spec looks somewhat lengthy, so I can guess that it has more kitchen sinks. Just skimming the libyaml docs, the API looks somewhat like SAX interfaces that I've used in the past. I have no a posteriori knowledge of it, but I would be reticent to start using it without a good reason.

XML sucks to deal with, don't opt in to it. There lots of reasons for this. I think the most relevant one in my mind is that it's prone to make the code that uses it more complicated than it would be otherwise. Any system I've seen designed with XML, reasoning about the XML is more complicated than the design interests that its trying to support. There are valid uses for it, though it's rare that another storage system wouldn't have been just as adequate.

Regardless of which one you choose, write as little code as you can managing it. You really want to write the classes your engine will use first. Then worry about serializing them. If you let your serialization influence your class design, you'll probably regret it. :)

like image 92
Tom Kerr Avatar answered Oct 06 '22 14:10

Tom Kerr