Intro to Game Architecture

Intro to Game Architecture
Jeff Ward
Associate Programmer
Bethesda Game Studios
My Talk





Your first engine
Why architect?
Principles of OOP
Design Patterns
Best Practices
Your Talk

How can architecture help us with:






Concurrency
Maintainability
Code ownership
Usability
Performance
Stability
Disclaimer
Sorry.
Your First Engine
Renderer
Creature
Player
AI
3DObj
2DObj
Items
Bullets
Sound
Input
File Loader
3dSnd
psst… this isn’t real UML…
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!
Why Architect (Design)?




Stability
Reusability
Cohesion
Orthogonally
A well architected system is easy
to understand, change, debug,
and reuse.
Principles of OOP

Basics




Encapsulation
Inheritance
Polymorphism
Principles of good design




Reduced coupling
Increased reliability
Increased reusability
$10 word - orthogonality
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.
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
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
Polymorphism

Important as it relates to inheritance…

Just realize that polymorphism goes two ways


Readable
Unreadable
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?
Singleton
Or “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
Singleton Example

Singletons (or factories) welcome…




Renderers
Resource managers
Memory managers
Message queues
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
Message Queues

Built of one queue with multiple listeners
Player
Creature
Vs.
Items
Bullets
Creature
Player
Queue
Items
Bullets
NPCs
MVC
Model 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
MVC Example

Separate view from everything else
CreatureRadarView
Renderer
3DObj
Renderer
Creature Model
Creature
Vs.
3DObj
CreatureView
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
Other Quick Patterns

Command

An object that represents stuff that should be
done, as an object



Façade


Only needs to understand “Execute” and “Undo”
Great for input handlers, macros, and undoable
operations
Encapsulate an entire system by providing a
single coherent interface
Proxy

A stand in for a concrete object.
Engine Improvements
Renderer
Player View
Player Model
Creature View
Creature Model
AI
3DObj
Bullet View
Bullet Model
Item View
Item Model
Queue
2DObj
IResource
File Facade
Sound
Input
3dSnd
File Loader
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
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)
Best Practices
Are key to your survival as a coder…
… and key to your code’s survival
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.
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.
Questions?
[email protected]
http://www.jeffongames.com