Use appropriate file formats

If you implement a tool that spits out game data, the file format you choose have a big impact on the amount of work required. In general, keep these principles in mind:

• Human-readable formats are great for debugging the tools that create data, or spotting logical creation errors (for example, putting an object below the world plane by accident). It also makes it easy to create quick test data by hand, or to modify existing data quickly (also for testing).
  
• Human-readable formats should always support comments. Not so much for documentation but as for rapidly taking out some data temporarily. This is important for testing.
  
• Human readable formats should support flexible white space handling. The tool should be able to read lines that start with spaces or tabs, or jumps over empty lines. This allows files to be better organised visually (whether produced by man or machine), and prevents "invisible" problems (such as empty lines that crash the parser).
  
• Using custom formats is usually not a good idea. Using existing formats will often save you the work of writing parse code, and will help you to reuse tools across projects.

Property Files

Here is an example of a property file:

level = Jupiter
aliens_count = 5
space_ship = Androxi II

These files are relatively easy to parse, simple to edit (also for non-programmers).

Make sure that your importer does not rely on a specific order – this makes the tool easier to maintain, and helps make it backwards compatible).

Property files are only suitable for flat data. If more structure is required, XML should be used instead.

XML

XML is by no means the best format for data. It tends to be verbose, and does not represent some data structures, such as graphs, well.

However, it is so widely used that it would be a terrible waste not to piggy-back onto existing code and tools:

• XML parsers are readily available in almost any language. All you have to do is traverse the tree. Moreover, object serialisation in many languages (such as C# and Java) has already been implemented to work with XML. That means, you can read in objects directly from their XML presentations, so if your tools produce XML in these formats, you do not even have to load in class attributes manually.
  
• XML is used for a wide variety of file formats. These file formats can readily be read into your game, allowing you to use tools a bit more creatively. For instance, SVG file format (that can be exported from vector art tools) can be used as a level description file.
  
• There are many XML editors available, many of them for free.
  
• XML can be rendered with formatting that is specified independently of the data. If you implement DTDs for your files, visual inspection can be very powerful.

XML is also editable by non-programmers (after a 5 minute training course!), and the verbosity actually helps document the format.

Scripting Language as a data format

If your game engine supports scripting, it is often better to generate data in the scripting language directly. This means you can use the built-in parser, and, if it is available, also the editor. In addition:

• It allows for "smart" content, (for example, a property whose value depends on other properties). This is especially useful if the scripting language is also used for other purposes (for example, Python), which allows use of external libraries.
  
• It allows for more complicated data structures.

On the downside, it is not suitable for hand editing by non-programmers. Also, smart content is dangerous, especially if it cannot be checked in the tool where it is created. For those reasons, it is best to limit your format to use only the most necessary data presentation features of the language (dictionaries and structs, for example).

Game or Game Engine Language as Data Format

In some cases, you might want to produce code files to be compiled with your engine directly. This is most useful for files that control behaviour, (such as state machines or other AI behaviour), scripted events, procedural content, or graphics routines (such as shaders).

The main advantages of this approach is that it

• can give a performance benefit (such as in state machine or shaders),
  
• gives support for smart content when no scripting is available, and
  
• saves writing complicated code for handling an intermediate format (such as for graphs).

It is also a dangerous approach, and can easily become a production bottleneck:

• It is generally harder to make it work, because of the additional constraints in syntax and names (to avoid name collision with other engine code classes, for instance).
  
• Each time the asset changes, it must be recompiled. This can become a problem in bigger projects if it is not dynamically linked.