Scene serialization and deserialization

Started by
2 comments, last by a light breeze 1 year, 4 months ago

Hi, I am currently building a game engine and I want to be able to save scenes to file and load them from file. I have experience in doing this with tinyxml2. I have seen that some engines use YAML over xml. Should I stick with what I know or move to yaml? What librarys would you recommend for this?

Thank you

None

Advertisement

KielanT said:
Hi, I am currently building a game engine and I want to be able to save scenes to file and load them from file. I have experience in doing this with tinyxml2. I have seen that some engines use YAML over xml. Should I stick with what I know or move to yaml? What librarys would you recommend for this?

XML and YAML both have their pros and cons. I personally find YAML a bit easier to read and edit by hand, because there are is no stuff like closing tags and thus the whole file can be more condensed. Though I'm also really using a custom “dialect” with a custom parser in my own engine, so actual milage may wary (especially Unity YAML tends to be very verbose in its own way, for example).

In the end, I'd say it doesn't matter that much. Pick whichever you are more comfortable with. If you already know XML and you have a library that you know and like, stick to it. If you are smart, you'd already design stuff so that changing a serialization-library won't mean to change all your code. No, you don't have to come up with some sort of crazy IO-wrapper, but what I mean is just, well, don't tie XML-code to code that doesn't need it. The basics of abstraction. That way, if for whatever reason you later find that JSON or YAML is better, you'll update your serialization-routines with a new library, and thats that.

For further reference, I used XML for about 4 years with my own engine, with a custom parser, then I moved to YAML, with another custom parser. So I can't recommend libraries (and this is definately not something anybody should really do!). XML did work until then; aside from liking the format a bit better there were some improvements to be had because I wrote the XML-parser at the start; and so it sucked. When I eigther had to write an entirely new XML-parser or YAML, I went that way. But I could still be using XML and would be fine eigther way.

JSON beats both YAML and XML for this. (Which isn't to say that JSON is actually good for this, just that it's better than YAML and XML.)

XML is unnecessarily complicated and unnecessarily verbose. Its real strength is marking up text (e.g. text with <u>underlined</u> words), not serializing arbitrary data.

YAML is unnecessarily complicated and suffers from the Norway problem. Its real strength is user-editable configuration files, not serializing arbitrary data.

JSON is simple and its strength is data serialization, which makes it superior to XML and YAML for that purpose. A well-designed custom text format will probably beat JSON for any specific purpose, and a well-designed binary format will always beat a text format for conciseness, but when you can't be arsed to use either of these superior options, JSON does the job.

This topic is closed to new replies.

Advertisement