A Data-DrivenGame Object System.ppt

* (Template is a ‘pattern’ in the conventional meaning, not the C++ meaning.) There is a 1:1 correspondence between a Go and its GoDataTemplate, and a Go’s components and the GoDataTemplate’s GoDataComponents. And within the GoDataComponents, the fields map 1:1 with the GoComponent public properties. * * * Talk about how it’s important to have a public schema like this. * * * * Implicit in this template is the other components that are inherited from the base template. There are many that you don’t see here like physics (yes, chickens can simulate) and actor. * * * * * * * * * Recommendation: have a special part of the tree (make it compile out in retail builds) that is just for test objects. They’ll pollute the global namespace so prefix the names with something like test_ or dev_. Then you can let people work in that branch of the tree doing whatever they like for testing purposes without worrying about it screwing up the main game. DS ended up with nearly 150 of these ‘cause whatever, they’re just for testing… * * * * A paper is not available, unfortunately shipping Dungeon Siege took up all my time. ? Compile ContentDbSpecial notes We want a flat tree for performance reasons Depends on how frequently you construct objects and how fast your data override system is Also permits special const-read optimization that can eliminate memory usage and CPU for variables that are never changed Copy data components on write to avoid unnecessary memory usage If have many templates, will need to JIT compile leaf templates to save memory Editor Integration This is almost trivial Editor should have a property sheet type thing This is a one-entry view into the db Map types and names onto fields using schema Can un-override easily by querying template Be sure to add a column or tooltip for docs! Editor Integration (Cont.) For DS all editing support done through a special “GoEdit” component Transforms data between game object and editor Supports cheap rollback (undo) by double