XNA and Data Driven Design

Games are made up of two things: logic and data. The logic defines the core rules and algorithms of the game engine, while the data provides the details of content and behavior.

When logic and data are decoupled from each other, the whole team, including designers and testers,
can experiment with different variations and tune the data to get the exact behavior they desire.

Therefore, game data should, ideally be loaded from text files; not embedded inside the code base.
This concept is essential to putting data driven design to work:

Create a system that can parse text files on demand (not just at start up) Put constants in text files so they can be changed easily without recompiling code Don’t hard-code anything; assume that anything can change, and probably will!

Example
Galaga: if the game requires only 3x types of enemy spaceships then you could program a perfectly good system that encompasses all of them. However, if you abstract away the functionality of each spaceship, using data to define its behavior, then you allow for an unlimited number; each with its own personality.

When core design decisions are flexible, the game is allowed to evolve to its full potential. In fact, the process of abstracting a game to its core helps tremendously in the design; this forces recognition of
what should be built, instead of the limited behavior outlined in the design document.

System Testing
System Testing is the practice in which complete, end-to-end software is tested to evaluate the system’s compliance with its specified requirements.

Game development that implements data driven design may find system testing effective because it can be used to validate all data before fully integrating into the game.

When experimenting with new ideas, all changes made to game data must be valid, otherwise it may be possible to easily break the system, or have the system behave in an unpredictable fashion.

System testing allows for this feedback quickly, efficiently and without need to execute the entire game.

Here is a common workflow to integrate system testing into game development:

Write game code and edit game data Run system tests and validate Launch game with current data Update any game data as necessary Re-run system tests and validate Hot swap updated game data Repeat process: no constant build / deploy

Two examples in which game data can be verified through system tests include:
Level Validation and Component Based Design.

Level Validation
In game development, level data is most often stored in text files. For example, the Platformer starter kit contains 3x levels, although an unlimited number of levels could be added using data driven design.

Level data can then be validated through system tests to ensure all data is true and correct, and that all rules are observed before the level is actually loaded into the game.

Component Based Design
Component Based Design is a common approach to build game objects that are flexible, maintainable and scalable: each component encapsulates a set of related functions, or data, so that additional game objects can be created without any extra code.

In game development, component based object data is typically stored in XML files. The logic used to parse XML and build game objects can be complex and error prone; consequently, system tests can
be used to validate all game objects before fully integrating into the game.

Therefore, it seems only relevant to try and integrate data driven design into XNA game development.
As an exercise, I would like to prototype data driven design using the following examples:

XNA and System Testing XNA and Level Validation XNA and Component Based Design

In conclusion, it will be interesting to see if data driven design has the potential to scale using XNA!