Every game is dealing with loading and managing lots of data. We can argue that every game engine doesn’t do much more tha managing and processing large amounts of data. I’m not talking about textures and models, most of the time being large chunks of binary, neither the sound & music or occasional videos. Any game needs simple representation of gameplay related data. Lately, data-oriented design brought some interesting ideas to place where object-oriented design was dominating.
Materials, game object/entities, levels, settings. Bunch of small files containing data. In our case, as we are using OpenGL for rendering, our shaders are also short pieces of GLSL shader code – again text files. Currently, shaders & materials are organized in XML files, each file containing both vertex and fragment(pixel) code and also additional lines for including external code (similar to #include) or defining uniforms that can be easily accessed from the game. Parsing XML is not hard, there are many parsers available. However, XML is not so great for defining this kind of data. Having to chose between storing data in tags or in attributes, no support for few data types that are in common use (strings, floats, vectors) is not so great. XML is really much more that we need at the moment, and will ever need for this game. It brings complexity instead of simplifying things.
But JSON is great. It’s simple, easy to read and edit and should be faster to parse than XML. It has support for floats, strings and arrays. Vector of 3 can be simply represented as, for example, “direction” : [0.0, 1.0, 0.0]. It is widely used in web and in mobile apps. Today, JSON is already used more than XML, with steady growth. Id engines used a similar way to define data for a long time (entity defs, materials, etc.). Lately, Bitsquid engine is a great example of similar approach (much of their work I found very inspiring) though they are using custom tailored format based on JSON, even simpler than standard.
My plan for SUPERVERSE is to have as much as possible of game data in JSON. We still have to decide will we ship the game with pure text-based resources (packed in zip archive, for convenience) or precompiled binaries, but for development, data format choice is set. Simplicity is key here. In the end, it will make everything easier to load, parse, and most importantly, write and read.
JSON is also much better name for a child than XML.