There are many ways to organize game data. This section discusses some that have worked well for me in the past.
Games are made of many things. There is the data — creature 3d models, textures, area maps, dialog files, and so on. And then there is metadata — lists that control which creature uses which 3d model, texture, dialog file and so on. The more complicated the game, the more metadata. Roleplaying games with hundreds of abilities, items, and creatures require an ‘insane’ amount of metadata.
The simplest way to organize this data is to use textfile lists, something along the lines of:
So we’ve defined ‘scarymonster’ to be composed of the model ‘modelscarymonsters’ and of race goblinoid. The art system cares about the first part, the game rules the second part. (I’ve worked on projects with dozens of fields, this is a simple example).
Now that’s not too bad to manage but imagine you grow out to several hundreds creatures and dozens of columns or fields. And imagine you have to update this hourly as more information becomes available. And then imagine that you’re asked to produce a report in an excel document for a manager to review and then later you’re asked to create a creature list for a strategy guide. And all these different requests want to see different fields in different formats. Lots of data entry.
I’ve worked with different solutions to this problem but I think by far the best solution has been the use of a database to manage the ‘core data’ and then using different means to export or pull the information out.
If the core lists are all stored in database a world of potential benefits are opened up. A list can be stored in one place and then exported in multiple ways.
Imagine you have a spell list with two hundred entries. Now each spell is going to require at least an icon, some data representing the resource costs (for the player), the visual effect(s) to play, the audio and finally data pointing to how the spell functions in data. Now elsewhere there is probably a design document describing how the spell works, in designer terms, and also another document (or table) with the help text the player should see in game.
All of this can be stored in a database. Different views of the data can then easily be exported. For example a game resource file can be exported telling the game engine what it needs to know (i.e., excluding the designer details but keeping the core game detail), a web page for internal documentation can be automatically updated with all the details the designers need to know, and an external Word document to show a publisher can be generated. Any kind of report that might later be needed can easily be created from this database and if programming later changes the data formats, say to improve performance, all that is required is a new exporter to be written and an export performed.
The choice of database is a separate issue that I won’t go into but look for something that has web access and easy ways to let non-technical users edit the data. This will broaden the user base. Once an easy to use end user interface is created the data workflow will improve tremendously and if the implementation is done correctly can be used for all future projects.
- Case. Use lowercase for resource names and enforce it. It will save you headaches later even if you are convinced case is not an issue.
- Resource Build. Tying data generation into the build process can be very useful. Since this process varies considerably from project to project it remains to the developer to choose the approach that works best for them. One word of advice would be to consider stopping automatic dumps from the data files as the project nears release. At this point you want to be vigilant about examining all changes manually.
The initial costs might seem a little high to set up the database as opposed to hand-editing text files, XML or building a proprietary non-database solution but it is well worth it. The core process can be used for all projects with the user interface access to the data maturing with your team or company and new exports easily written as file requirements change.