Techniques And Strategies For Data-driven Design In Game Development

Case study, part deuxA common approach is to initialize atoken’s prototype data in the creationroutines for the tokenYou probably want to have a listing ofall of the weapons side by side, tocompare their propertiesIn Smash TV 3D, we had a bunch ofenums and #defines at the top of a file

Weapons example

Case Study, continuedWhenever a weapon was constructed, thefactory would initialize it’s variables.p Weapon- SetDamage(kRocketWeaponDamage);p Weapon- SetSpeed(kRocketWeaponSpeed);This approach has many of the problems wediscussed in the Pac-man case study.The variables are all in code, which is a badplace for variables that change frequentlyDuring development, a good deal of time waswasted tweaking variables and thenrecompiling

ImprovementsWe want to move this information intoa text file or database (the “datasource”)This would allow us to just modify thedata source to test your changesHow do we associate the informationin the data source with the game?

Prototype IDsA prototype ID corresponds to an entry in our datasource that contains information for a specific prototypePrototype ID0123NameDamage Speed Amount Delay ModelNormal Shot11042 200 Normal.modelRocket2542 200 Rocket.modelSpreadShot11042 250 3WaySpreadShot.modelGrenades158450 Grenades.modelThis ID should be globally unique

Advantages of PrototypeIDsWe can avoid storing any of the prototype data in theclass at all. Instead of:m damage kRocketWeaponDamageWe get:CWeapon::GetDamage(){return GetWeaponDamage(m prototype id);}Where m protoype id would be initialized toPROTOTYPE ROCKET.

Prototype summaryAll of the information for your prototypesshould be stored externally in a data sourceThe game should read in the data source atrun-time and keep a database of prototypesin memory, each entry storing all of theinformation for a specific prototypeEach instance of a token should have aprototype ID so they can reference theirprototype when it is needed

The Mr. PotatoheadPrototype

Mix N’ MatchYou don’t need to have a different prototypefor every token that describes ALL of thetoken’s properties explicitlyNameModel Type Model Name Movement Mode Movement Speed Movement Turn Rate A I type A I A ggressiveness A I Morale A I LearningGruntA NIMA TING Grunt.model Walking5360 ENEMY0.510 NoInstead, you can have prototypescorresponding to each component in thetokenThen a prototype for a token will actually becomposed of sub-prototypes

Mix n’ Match, continuedIn Smash TV 3D, we could makeprototypes for the following nvincibility.modelModel TypeAnimatingAnimatingStaticPhysics type (movement mode)Prototype ID012zPrototype ID012Movement modeGroundAirAirSpeedTurn Rate536031801030AIPrototype ID AggressivenessMorale00.510.7Learning10 Yes8 No

More Mix n’ MatchYou could then have a prototype for anenemy look as follows:Grunt Prototype:zzzModel: Prototype 0 (Grunt.model)Physics: Prototype 0 (Walking)AI: Prototype 1The Grunt token is then composed of severalsub-prototypes, each which describes one ofthe grunt’s components (model, physics, AI)This allows different tokens to share subprototypes

Extending Mix n’ matchPrototypes can also reference other prototypesExample: The grunt prototype could reference aspecific weapon prototype, indicating the weaponthe grunt will use – e.g. “Rocket Launcher”The rocket launcher might in turn reference a 3dmodel indicating the visible appearance of theweapon when wieldedThe player could also reference the same weaponprototypeUsing this scheme, the code could treat theplayer’s weapon and the enemy’s weaponidenticallyThis buys consistency and reliability because weget code and interface re-use in-game

Mix n’ matchSub-prototypes can be further split into subsub prototypeszzGround movement prototype could be split into‘treads’ and ‘walking’, etc.This process can continue ad infinitumUsing prototypes with a component-basedarchitecture results in a flat object hierarchy,but a complex data hierarchy

What about Instances?Once you have your prototypes, you want tohave a way to create instances of them inyour game and set up the instance specificdataIn Smash TV 3D, different types of tokenswere handled differentlyzzzEnemies was created through spawn points. Atext file controlled the timing of enemy creation.The Spawn Points themselves were placed in thelevel in 3DS Max and were created when the levelstarted in the appropriate positionsPowerups were created randomly every couple ofseconds, based on a percentage in a text file

InstancesInstances can be created through designerintervention and/or through systemsThe creation must provide all of the instance specificdata that the token requiresThis is usually at least a position in the game worldIn Smash TV 3D, the spawn points gave each objectits initial position (at the spawn point)Initial velocity was always towards the center of theroomPowerups were created in a random position within acertain radius of the room’s center

Factory FunctionsA common way to implement instantiation oftokens is through factory functionsFactory functions take a prototype ID, and anyinstance-specific data that cannot be filled out bythe data source, and create an instance of anobjectUsually look something like:Some Type Of Object Handle Or PointerCreateObject(int PrototypeID, instance specific initial params.)Factory functions insulate concrete entity detailsfrom systems that use and spawn those entities

Prototype-instanceSummaryPrototypes consist of the informationnecessary to describe the basic traits of aspecific type of token in the gameThe instances of a prototype are the actualtokens of that type that exist in the gameworldInstances contain both a reference to theirprototype (ID) and instance-specific dataGame behavior is generated by tokens, theirprototypes, and the systems that operate onthose prototypes

Technique IV:ScriptingThe systems approach / componentarchitecture tends to break down when thenumber of unique prototypes of a given typebeings to grow dramatically, and when eachprototype requires very different behaviorExamples:zzScripted EventsObject AI implementation

Scripted Events / In-gameCutscenesYou want a specific sequence of events to occurredin a specific timed orderEach scripted event is uniqueHaving a system to manage a bunch of uniqueevents doesn’t make sense, since you just end upwith a lot of very special case functions in code, onefor each scripted event:void ();void id rldDomination();This makes it difficult to tweak these sequences

That bothersome AIObject AI is similar in this regardEach AI is unique and provides a different setof behaviorsMany of the behavioral variables need to begreatly tweaked before they look appropriateThere is not enough in common amongdisparate AIs to move all of their variables toa data source without enormous amounts ofeffort

The general problemYou will run into this problem whenever you’redealing with some component that requires alarge number of very different pieces of specialcase codeThe key word is ‘different’If you have a hundred different objects, but youcan break them down into a few variables andbehaviors, you can still use the system-prototypeapproachEach creature AI and cutscene has a vastlydifferent behavior, even in a simple game

Grunt Variablesstatic conststatic conststatic conststatic conststatic conststatic conststatic conststatic conststatic 2uint32uint32Rhino Boss Variablesstatic const uint32static const uint32static const uint32static const uint32static const uint32static const uint32static const uint32static const float32static const uint32kEnemyGruntBackswingSpeed 5.0f;kEnemyGruntSwingSpeed 15.0f;kEnemyGruntRecoverSpeed 2.0f;kEnemyGruntSpeed 15.0f;kEnemyGruntNumSwings 3;kEnemyGruntBackswingTime 300;kEnemyGruntSwingTime 100;kEnemyGruntRecoveringTime 500;kEnemyGruntRecoveredTime 200;kBossRhinoEntranceDuration 3000;kBossRhinoTurnTime 2000;kBossRhinoDeathTime 300;kBossRhinoTimeBetweenAttacks 5000;kBossRhinoTimeBetweenShots 100;kBossRhinoPrepShotTime 1000;kBossRhinoPrepChargeTime 3000;kBossRhinoChargeAdjust 0.95f;kBossRhinoChargeAdjustTime 250;and only a few variables in common:static const uint32static const uint32kBossRhinoHealth 500;kEnemyGruntHealth 1;

What do we want?Each custom behavior should be able tofunction in isolation from other custombehaviors, so it is easier to test and manageWe want to be able to tweak as easily aspossibleBehavior should be determined at run-time,rather than compile-time, for the abovereasonBehavior should be treated as “data”, ratherthan code, and be managed accordingly

Scripting LanguagesScripting languages are programminglanguage other than the one actually used toprogram your game, and are used them towrite game behavior through an APIYou pass the scripting language through toolsthat compile the language into a format thatcan be loaded on the fly and executed

Problems with ScriptingLanguagesWriting one is not for the faint of heartRequire an enormous amount of workYou have to write a compiler and executerYou have to expose an API to themYou will have to write a parameter marshallerYou will want a nice suite of tools, like a developmentenvironment, debugger, etc.There will be learning curve since it’s a brand new languageMay result in unmaintainable spaghetti code if poorly designedUsually at best 1/10 speed of C/C , so can drag downperformanceExisting scripting languages (Python, Ruby) may not meet yourneeds, there’s still a learning curve, and will still run very slowly

DllsAll we really want is to be able to write incode, and have that code loaded at run-timerather than linked in at compile-timeOn Windows, DLLs do exactly thatVery similar to executables – collections ofmethods and variables in a specific formatDLLs cannot be launched directlyAnother executable or DLL must load the DLLinto its memory space, and then it can usethe DLLs functions

Using DLLsYou should encapsule each different behaviorin its own DLLWithin each DLL, you’ll probably need toexpose a few entry pointszzzzA Run() methodAn Initialize() methodA Shutdown() methodA way to notify the script of eventsKeep entry points to a minimum; your gameshould communicate with the script in yourDLL through a limited number of connections

Using DLLs, 2You will need to provide an API to allow the script tocommunicate with the rest of the gameApproach 1:Write another DLL that contains the API. The game shouldload this DLL on startup and intialize it with access to all ofthe appropriate global variables. These variables shouldbe stored in a shared segment of the DLL. All script DLLsshould link against the LIB provided with this DLLApproach 2:When the script starts up, pass it a structure that contains abunch of function pointers to all of the API functions (oroptionally a class with pure virtual functions)

Using C classes in scriptsBecause of name-mangling, you can’t placethe exported functions in a classTo avoid this problem, you can use a wrapperapproach. In your initialize(), allocate aninstance of the class you want to use as aglobal variable. Then, have the Run(),CallEvent(), and other exported functions justforward the call to functions in the instantiatedclass.

A better approachCreate an abstract base class with the functions thatyou would have normally exposed in your DLL.class CScriptDLL{public:virtual bool Initialize() 0;virtual bool Shutdown() 0;virtual bool Run() 0;};You cannot instantiate CScriptDLL.You have to create a class that inherits from it, andimplement all its the pure virtual functions

class CCreatureAI: public CScriptDLL{public:virtual bool Initialize() {.}virtual bool Shutdown() {.}virtual bool Run() {.}};Now, any code that knows about CScriptDLL can callthese functions through a CScriptDLL pointer, even if itactually points to a CCreatureAI.Now, instead of exposing all of these functions in the DLL,you only need to expose one function:CScriptDLL* EXPORT CreateDLLInstance(){return new CCreatureAI;}When the executable loads your DLL, it only needs to callCreateDLLInstance(), hold on to the returned pointer, anduse it to call the Initialize(), Shutdown(), and Run() functions

Scripting Languages vs. DLLSThere are tradeoffs between both scripting languages andDLLsThe argument that scripting languages are easier to usefor non-programmers is irrelevant; most complex behaviorcan only be written by someone could also understandC/C One advantage scripting languages can offer is languagefeatures difficult or impossible to realize in C/ C For DLLs, you must have a version of Visual C or theequivalent on the machines that will be compiling scriptsFor a game like Quake, where a lively mod community isdesired, this may not be an optionOn consoles, you will have to learn the executable formatand write your own linker to use the DLL methodThis is still easier than writing a scripting language

Technique VI: The DataEditorThe prior techniques have suggestedways to move much of the gamebehavior into a ‘data source’ external tothe codeWe want to be able to edit the ‘datasource’ as easily as possibleA database can be a good choice foryour data source, since they are easy toread and edit

The Data Editor, 2Databases are only good for numerical and text dataFor graphical data, you should write new or leverageexisting tools to manipulate the data in a graphicalfashionTry to use existing tools when possibleIn Smash TV 3D, we used 3DS Max to create levelsand place spawn points, collision data, and doorsAt Outrage, we use Maya for editing of objects andlevels, and have written a whole suite of plugin tools toadd game contentEven for text and numerical data, it can also be usefulto write dialogs that wrap the database for ease ofediting

Technique VII: ASCII vs.BinaryIf you have a lot of files that get loaded into the game,you can adopt a dual ASCII / binary approachASCII is easier to debug and validateBinary is faster and reduces file sizeYou can have all your tools write out ASCII files in amanner that can be easily read inAlso provide a tool that convert the ASCII into tightlypacked binaryIf you add binary / ASCII transparency into your fileI/O libraries, you will get the best of both worldsDon’t read in the database as is either; have tools toconvert it to an easily-read binary form

Technique VIII:Reload game content on the flyEditing values in the database does notrequire a recompileIt still requires a restart of the game and areloadA system that lets you reload portions of thegame data while the game is actually runningcan save huge amounts of timeYou can even add a button on the data editorto automatically signal the game to reload itsgame data, making the process automatic

Technique IX: Debugglobal variablesDLLs / scripts often have dozens of variables that need tobe tweakedWe must recompile or at least reload the script to makeany changesThis slows down tweaking of these variablesIt is also far too time-consuming to expose all of thevariables in DLLs / scripts individually in the data sourceInstead, create some generic debug global variables(some floats, some ints, etc.)Use the debug variable in place of the real variable whiletesting values that need tweakingSince they are global, you can change their values in thedebuggerThis will give you instant feedback for tweaking

CaveatsDon’t lose sight of your original goalAll of these techniques require additionalwork up front before you see any resultsTake the timeframe and design of yourproject into accountDon’t write code that won’t be usedimmediatelyThe best way to design for the future is tohave a solid design and clean, wellcommented code

Data-driven designSummaryMoving game behavior out of code andinto data results in a more efficient processfor tweaking content and gameplayUse a component-based architecture with theprototype-instance approach for easilytweakable and incredibly flexible gametokensStructure your game systems to operate onspecific tokens and / or token components

Questions?

THE ENDTechniques and Strategies for DataDriven Design in Game DevelopmentScott ShumakerProgrammer,Outrage Gamessshumaker@outrage.com

Game development is hard From a technology standpoint, game development is no more difficult than other software development However, properly functioning technology is just one of many requirements for a successful title The majority of the development time is not spent developing technology, but content and gameplay.