Data Driven Is Half the Battle

1. Data Driven Is Half the Battle

2. Me Jeff Ward Toolsmith / Programmer Fire Hose Games • Previously: • OrbusGameworks (Metrics Middleware Software / Consulting) • Bethesda Game Studios (Oblivion / Fallout 3)

3. This is a talk about being data driven in a smart way

4. This is not a talk about data driven programming… But we have to stop there on our way…

5. Data Driven • When a coder “clearly distinguishes code from the data structures on which it acts, and designs both so that one can make changes to the logic of the program by editing not the code but the data structure”

6. Data Driven • Separating code and data • Data is exposed and editable • Changing data can change the logic or behavior

7. Benefits • Fast iteration time for certain changes • Ability to add and remove parts quickly • Allow other team members to do their work without programmer intervention

9. What do you Drive Via Data? • Everything! • Whatever is data • Whatever people might need to change

10. Common Data Driven Elements • Levels • User Interfaces • Stats / The Numbers • Hit points, damage, probabilities, formulas • AI • What they can do, relative importance, probability • Game Configuration

11. The usefulness of data driven programming is depends on what, how, and to whom you expose your data

12. What • Who • How • - Data Files, .INI files, Text Files, XML, Json

13. Usefulness • Readable by anyone • Editable by anyone • Which also means being able to fix syntax errors • Self documenting

15. Approaches • Human Readable Text Files • Xml, json, proprietary • Binary formats

16. Usefulness • Readable by anyone • Editable by anyone • Which also means being able to fix syntax errors • Self documenting

17. “Human Readable”

18. “Human Readable”

19. “Programmer Readable”

20. “Programmer Understandable”(for the most part)

21. Usefulness • Readable by anyone • Editable by anyone • Which also means being able to fix syntax errors • Self documenting

22. Explanations • These formats are meant to be context free • The meaning of the data is defined by the program, not the format. • This means that to truly understand what’s going on, something needs to supply context

23. Interruptions • 82 percent of all interrupted work is resumed on the same day. • It takes an average of 23 minutes and 15 seconds to get back to the task. • Increases stress, increases errors.

24. Focus on the Problem This is the problem…

25. This is not a case against human readable formats

26. This is a case for good tools

27. This is a talk about tools! And exposing your data

28. Editors are the Answer

29. Simple Editors

30. This is a tech talk (and a design talk…)

31. Two Sides • The Editor Side • The Game Code Side

32. Editor Goals • Driven by game code • Easy to use • Won’t loose any data • If you can’t get these, you aren’t doing anyone any favors.

33. Game Code: Make It Easy • The key here is programmers are lazy. • If you make it hard to • read / write properties to data driven files • add properties to the editor • document said properties • Programmers won’t do it.

34. Game Code: Make It Easy • Every step you add to the process makes it more likely that a step will be missed or preformed incorrectly

35. What to Strive For • Types are discoverable • Properties on types are discoverable • Documentation on properties are discoverable • (Initial) UI for editing properties is generated from discovered properties, types, and documentation • Serialization / deserialization occurs through this discovery process

36. C# Makes It Easy

37. C++ Makes it Hard! • Data description formats? • Parsers? • Generators? • Custom Reflection?

38. “One Line Changes”

39. One Way How

40. Basis of Custom Reflection class Version : public Reflect::ConcreteInheritor<Version, Element> { public: std::string m_Source; static void EnumerateClass( Reflect::Compositor<Version>& comp ) { comp.AddField( &Version::m_Source, "m_Source" ); } }; void Init() { Reflect::RegisterClass<Version>( "Version" ); }

41. Be Careful • Relying on deserialzation of each object • Read data that doesn’t change once • Potentially cache other data • Memory footprint of reflected properties • Human readable formats are good during development, optimized formats are better for deployment

42. Summary • Data Driven Programming is Awesome! • So long as people can actually use it • And understand it without interrupting others • Tools make this possible • Tools that modify data should be • Easy to use • Easy to maintain • My recommendation is reflection

43. Questions? Email: jeffw@firehosegames.com Blog: www.jeffongames.com Twitter: @fuzzybinary www.firehosegames.com Twitter: @FireHoseGames