GD - 4th - Game Architecture

[ Wijanarko Sukma . Department of Informatics ]

Game Architecture :wanna play a good

game ?


Taken from the Presentation slide of :

Jeff Ward

Associate Programmer

Bethesda Game Studios


How can architecture help us :

Concurrency

Maintainability

Code Ownership

Usability

Performance

Stability

Architecture


Bad architecture creates problemsProduces 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!

Bad Architecture


Stability

Reusability

Cohesion

Orthogonally

Why do Architect (Design)


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


Principles of OOP (Object Oriented Programming)

Design Patterns

Best Practices

Know this first


Example Engine

Logic

State

Data File Loader

Output Input


BasicsEncapsulation

Inheritance

Polymorphism

Principles of good designReduced coupling

Increased reliability

Increased reusability

orthogonality

OOP Principles


“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

Encapsulation


Accessing elements between instancesIt’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.

Instance Encapsulation

Creature Creature


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 inheritanceCleaner architecture

Faster execution time and overhead

More flexibility

More encapsulated

Inheritance


Important as it relates to inheritance…Just realize that polymorphism goes two ways

Readable

Unreadable

Polymorphism


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?

Intro to Design Patterns


Creational patternOnly one instance of the object exists

Private constructor with public accessor (usually Class::Instance())

Really nice name for a globalOften overused, and often not a real solution

Singletons translate well to factories

SingletonOr “Patterns Don’t Solve all Problems”


Singletons (or factories) welcome…Renderers

Resource managers

Memory managers

Message queues

Singleton Example


Behavioral patternInform 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

Observer / Listener


Architectural patternKeeps data and representation separate

Model = data, view = representationController is what sends messages to the model and view.

AdvantagesOne data, multiple views

Data manipulates data, and doesn’t care if its being viewed

Change renderers without changing anything else

MVCModel View Controller


Separate view from everything else

MVC Example

Renderer

3DObj

CreatureVs.

Creature Model

CreatureView

Renderer

3DObj

CreatureRadarView


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 logicSo long as instances are encapsulated

Advantages of MVC


CommandAn 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çadeEncapsulate an entire system by providing a single coherent interface

ProxyA stand in for a concrete object.

Other Quick Patterns


Management ideaThat 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.

Best Practices


Management Best PracticesUse version controlDo automated testingHave automated builds

Coding Best PracticesPrefer compile / link time errors to run time errorsGive one entity one cohesive responsibilityPrefer composition to inheritanceAlways code for concurrency (in terms of architecture)

Examples of Best Practices


Best PracticesAre key to your survival as a coder…

… and key to your code’s survival


Know what you’re doing and why.

Know that one approach to inheritance is better and know why.

Know when you’re coupling systems inadvertently

Know when you’re coupling instances

Know when to test

Know how to test

Know when to automate

Some Advices


Know when to refactor

Know when to rearchitect

Know that both are going to break everything

Final Words


Game Dev lecturers teamBy Wijanarko Sukma (5105100173)

GD - 4th - Game Architecture

Education

design wijanarko sukma

problems wijanarko sukma

best practices wijanarko

quick patterns wijanarko

mvc example wijanarko

example engine wijanarko

game architecture

book design patterns