Intro to Game Architecture

1. Intro to Game Architecture Jeff Ward Associate Programmer Bethesda Game Studios

2. My Talk • Your first engine • Why architect? • Principles of OOP • Design Patterns • Best Practices

3. Your Talk • How can architecture help us with: • Concurrency • Maintainability • Code ownership • Usability • Performance • Stability

4. Disclaimer Sorry.

5. Your First Engine AI Creature Renderer Player 3DObj Items Bullets 2DObj Sound Input File Loader 3dSnd psst… this isn’t real UML…

6. Why is that bad? • Bad architecture creates problems • Produces side effects • Hard to follow • Hard to debug • Hard to reuse • Spend more time finding a way around the architecture than fixing the problem • OMG HAX!

7. Why Architect (Design)? • Stability • Reusability • Cohesion • Orthogonally

8. A well architected system is easy to understand, change, debug, and reuse.

9. Principles of OOP • Basics • Encapsulation • Inheritance • Polymorphism • Principles of good design • Reduced coupling • Increased reliability • Increased reusability • $10 word - orthogonality

10. Encapsulation • “Encapsulation is a programming mechanism that binds together code and the data it manipulates, and that keeps both safe from outside interference and misuse.” – Schildt • Encapsulation is not just data hiding! • Implies each object should be a cohesive whole.

11. Instance Encapsulation • Accessing elements between instances • It’s a convenience feature, not a good idea • “Always Design for Concurrency” – Tip 41 in The Pragmatic Programmer • Even if you don’t need it, a cleaner architecture results. Creature Creature

12. Inheritance • Key overused concept of OOP • “ Inherit not to reuse, but to be reused.” • “Is a” vs. “has a” vs. “needs to used as a” • Degrades performance • Prefer components over inheritance • Cleaner architecture • Faster execution time and overhead • More flexibility • More encapsulated

13. Polymorphism • Important as it relates to inheritance… • Just realize that polymorphism goes two ways • Readable • Unreadable

14. Intro to Design Patterns • Book Design Patterns by “The Gang of Four” (Gamma Helm Johnson Vlissides) • The same problems keep coming up in CS • We keep solving them in the same (or similar) ways. • Is there a pattern here?

15. SingletonOr “Patterns Don’t Solve all Problems” • Creational pattern • Only one instance of the object exists • Private constructor with public accessor (usually Class::Instance()) • Really nice name for a global • Often overused, and often not a real solution • Singletons translate well to factories

16. Singleton Example • Singletons (or factories) welcome… • Renderers • Resource managers • Memory managers • Message queues

17. Observer / Listener • Behavioral pattern • Inform multiple dependant objects of changes • Usually implemented as Subject and IListener objects • Listeners add themselves to subjects • When a subject changes, all listeners are notified. • Great for message queues

18. Message Queues • Built of one queue with multiple listeners Creature Creature Player Player Queue Vs. Items Bullets Items Bullets NPCs

19. MVCModel View Controller • Architectural pattern • Keeps data and representation separate • Model = data, view = representation • Controller is what sends messages to the model and view. • Advantages • One data, multiple views • Data manipulates data, and doesn’t care if its being viewed • Change renderers without changing anything else

20. MVC Example • Separate view from everything else CreatureRadarView Renderer Creature Model Renderer Creature CreatureView Vs. 3DObj 3DObj

21. Advantages of MVC • Complete decoupling of logic from display • Easier to test, since you can watch just the logic • Easier to change (both the display and the logic) • Can run the view without the logic • Can run the logic without the view • Can distribute the logic • So long as instances are encapsulated

22. Other Quick Patterns • Command • An object that represents stuff that should be done, as an object • Only needs to understand “Execute” and “Undo” • Great for input handlers, macros, and undoable operations • Façade • Encapsulate an entire system by providing a single coherent interface • Proxy • A stand in for a concrete object.

23. Engine Improvements AI Renderer Player View Player Model Queue Creature View Creature Model 3DObj Bullet View Bullet Model 2DObj Item View Item Model IResource File Facade Sound Input File Loader 3dSnd

24. Best Practices • Management idea • That there is a technique that is more effective than any other technique at delivering positive results. • Something you don’t have to do, but it’s a good idea. • They’re like design patterns on a small scale. • Two books: • Pragmatic Programmer by Andrew Hunt and David Thomas • C++ Coding Standards: 101 Rules, Guidelines, and Best Practices by Herb Sutter and Andrei Alexandrescu

25. Examples of Best Practices • Management Best Practices • Use version control • Do automated testing • Have automated builds • Coding Best Practices • Prefer compile / link time errors to run time errors • Give one entity one cohesive responsibility • Prefer composition to inheritance • Always code for concurrency (in terms of architecture)

26. Best Practices Are key to your survival as a coder… … and key to your code’s survival

27. Final Thoughts • Know when to refactor • Know when to rearchitect • Know that both are going to break everything else • Code, Test, Refactor, Test Cycle • Try to automate this • Code is better at testing code than you will ever be.

28. Summary • Architect for cleaner, more stable, more reusable, and more understandable code. • Use the principles of OOP to your advantage, not your detriment • Utilize design patterns to avoid common problems • Understand best practices and apply them. • Make great games.

29. Questions? jeff@fuzzybinary.com http://www.jeffongames.com