Data and Resource Generation
There are many ways to organize game data. This section discusses some that have worked well for me in the past.
Overview
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.
Database Approach
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.
Some Tips
- 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.
Conclusion
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.
3 Comments
Cal
What are the costs of setting up the db that you mention? Is it the cost of the proprietary software or the time of setting up something like MySQL and running a server?
Brent Knowles
The costs would include
– any required software… some databases are cheaper than others, and there are some that are free, especially for ‘internal company use only’ so this cost could be minimal
– there would be hardware costs, for running the server. Depending on project scope this could be minimal but larger companies with hundreds of employees split among various studios would have to spend more (and be more concerned about security)
– a large cost would be setting up an expandable framework that included easy report generation, ability for developers to add data easily to the database (i.e., decent user interface), and the various exports that would be required. If the company has no database expert, this cost is higher. A well trained database expert could make this be fairly painless (re: cheap).
Once setup however the system becomes pretty cheap to maintain. There would be occasional database repair and upgrade required but that could be handled generally by a company’s IT group. The only thing that would require the game team’s resources might be when new exporters are required so long-term the advantage is significant.
Pingback: