---

San Diego - November 2002 Meeting

---

Advanced Data Driven Design
by Bob Skinner, SD IGDA committee member

If you are a Game Developer in San Diego, I hope you made your way to the last IGDA San Diego chapter meeting. The meeting was sponsored by Criterion, the producers of Renderware Studio. Criterion provided just the right amount of Pizza and Beverages. Raffle winners won copies of Burnout II, and a "damn fine" T-Shirt. A big thanks again also to our Venue Sponsors, Qualcomm BREW Developers team, and their representatives in attendance Val Hayes and Mike Yuen. After the main session, extended networking reconvened at Karl Strauss.. So if If you "must see TV" on these odd-last Thursdays, here's an account. 60-odd developers (a count, not a description) of various disciplines were in attendance, no doubt intrigued by what adherence to the technique presented promised. As games increase in scope and scale what leverage can we use to make games more authorable, manageable and malleable? Hmmmm....

Eric Yiskis nodded while the Game Developer Conference session put a name to the technique he was already employing. Crash Bandicoot's developers were explaining "Loose Data Coupling with Actor Components", a technique that helped make Naughty Dog a leader of the pack. Most eyes glazed over, but Eric new the power of LDC. At Oddworld Inhabitants, Eric's Odyssey series was the first iteration of practicing the techniques espoused. At Angel Studios, the methods were honed further. Now at up-and-coming developer Sammy Studios, Eric took an opportunity to evangelize the paradigm that made him one of the big dogs in game development.

The time is ripe to share these methods' knowledge and use, according to Eric. The enlightened developers at Sammy "believe that sharing the right knowledge benefits all developers as it leads to the health of the industry". The techniques can now truly be called tried and proven. Best of all, wider use will allow a feedback of improvements.

Now more than ever it is necessary to have the look and feel of a product in the prototyping phase to reduce risk and effect the maximum improvement during development. You need the designers who say "wouldn't it be neat…" to actually prove the neatness, because you employ a system that lets designers and artists implement their notions. Current methods to do this largely fail because their awkwardness discourages enhancement. The systems have data version headaches, and are just plain clunky.

The solution proposed is to have a behavior system available upfront in the form of software components, and a way to select from those behaviors freely for the myriad actors while alleviating data awkwardness and threats to good class hierarchy.

A class hierarchy works when it is the logical order of the classes. When design enhancements are effected by moving classes up the hierarchy in order to gain capability through inheritance, well, you can begin to abandon all hope. The proposed solution is to make all behaviors components, and have actors selectselected among those components in the authoring scheme. For example, a specific "door" actor may now gain AI capabilities without the AI class moving up a hierarchy to achieve it.

The hierarchy is spared the ugly effects of multiple inheritance and "bubbling-up". Getting objects back to state of "Has a" instead of "Is a" is another good result.

Actors are a virtual bag of components, that is have a repertoire of component behaviors. Components can be mixed and matched, adding functionality without hierarchy or limits. Specific rules are set for building components, among them that components must assume that all other components could exist in the actor. In the absence of any component, the actor must not crash. This isolation allows for testing components individually, and component absence is part of the upward compatibility of the data.

An actor instance's behavior is specified by its actor template plus its layout instance. Games have always been data driven. The old data driven way was to have a layout tool produce a binary for reading by the game engine classes in real time. Eventually programmers are not directly involved in content creation when this pathway becomes stable. Data driving has essential advantages: Design and art changes could occur without recompiling the code, ; the code can be arranged in a hierarchy with the potential for reuse. New behaviors can be placed in classes endlessly to account for new design data.

Problems exist with this solution. For one, the data files have version problems. Enhancement is discouraged by the system. Layouts are high maintenance. There is inflexibility when reusing code, and the hierarchy is always imposing limits that are awkward to overcome. It is hard to make sweeping changes, for example, to find all the Orcs on all the levels of a world and make them uglier, faster or louder.

Loose Data Coupling excels at sweeping changes, because of use of templates and tags and the separation of layout data from template data.

LDC is easily achieved with XML, which, for those unfamiliar, is eXtensible Markup Language, a common text format that uses invented tags and parameters to specify anything in an organized hierarchy that is easily parsed.

Actor templates store default values, say the Orc complete default composition. The layout format would only store deltas, or deviations and extensions of the template. Redundancies in effort and data are removed. New actor types become powerful shorthand for all the details of the sub-type. The overrides and extensions work with the elegance of inheritance in classes. This is achieved in a language that designers and artists can synthesize and maintain with less risk of breaking builds or waking programmers.

A simple example is a door. The template has been established to describe doors generically. In a layout editor, a design collaborator has placed a door, and decided to "lock" this instance. Your assignment: Create an elaborate GUI-based layout editor that outputs the files!

Template File Entry:
<component name ="Door"/>
     <Attr name="Model" type="String" value="GenericDoor.mod"/>
     <Attr name="Animset" type="String" value="GenericDoor.ani"/>
     <Attr name="AnimSpeed" type="float" value="0.5" min"0.0"
     max="1.0"/>
     <attr name="Locked" type="bool" value="0"/>
     </Component>