This post is a bit of an addendum for an earlier post (Data and Resource Generation) which talked about ways to organize the data needs for a game.
Role-playing games are data intensive. In my career I’ve worked at two different extremes, in regards to how game data is organized and edited by designers. Both have their benefits and their disadvantages.
Everything is Unique
In this scenario if the designer needs to place a creature, for example, they would create the creature from scratch or reuse one from a library.
- Full Control. This scenario allows for maximum customization, the full particulars of each creature can be tweaked until the perfect balance/encounter difficulty is established.
- Lots of Data Re-Entry. Imagine that the game rules change, or overall balance changes, and all Super Soldiers of a particular level need to have their health adjusted. This could mean going through all the creature files manually (a database storage system could make this easier but still not painless). It could even be worse if the creatures, once placed, exist only within the area data… then it involves opening each area map and tracking down instances of the creature… painful.
- Dude that’s not your Demon! In some scenarios another designer might be able to modify the files you used… say re-using your Super Soldier but halving their health for a particular custom scenario. This actually happened to me once on an early project, when I received balance complaints I noticed that almost all the creatures I had used in one area had been modified by another designer for balancing in their level.
A Templating System
There are many alternative models to use for data organization but one that I’m fond of (though it is not without its faults) is a template system. In an ideal template system core details for a particular creature are stored in one file but when it is placed in an area the designer has the option of overriding particulars. So they could change the name and the health but leave weapons/armor the same. Any detail they do not change on the instance can be globally modified by a tweak to the template, if required.
- Major Changes = Easy. If a major game change is required only one file has to be updated.
- Self-Teaching Design. Another benefit of this is that a junior designer can easily go through a more advanced designers areas and look at what that designer has customized (in a good templating system the overridden fields should be easily visible). Skill improvement In this way they can see how a more experienced designer has tweaked creature parameters.
- Extreme Templates = No Customization. An extreme approach can be take here, basically boiling down all the instance parameters of the creature placed in an area to a series of fields like ‘Power Level’, “Type”, ‘Category’, and so on. The combination of these parameters imbues the instance with actual statistics when the game is loaded. Designer’s cannot tweak individual statistic values but a system’s designer can tweak the math formulas used behind the scenes to generate stats. This is a huge balancing time-saver but it comes at a cost: basically it becomes very difficult to tweak an instance, to create a custom flavored scenario.
- Dude, that’s still my Demon! Designers can still overwrite data in this scenario as easily as in the first but with a templating system controls can more easily be put in place… perhaps limiting template access to certain designers. Again watch out for the danger of killing creativity by taking away control.
A template solution is definitely something to consider if you are organizing dozens or more areas and hundreds of creatures. Just make sure you strike the right balance between allowing designers the freedom to customize their critters and being able to do massive balance passes lightning fast. Without the customization your encounters will become repetitive. Without ease of data modification your game might never ship.