What a game designer needs to know about

What a game designer needs to know about design patterns

What’s your plan? �How are you going to collaborate? �How are you going to divide up work? �How are you going to make sure that changes work with other people’s code? �What’s needed to write Pong?

What are design patterns? �Useful abstractions for commonly used design structure �Patterns and their consequences of use have been thought through by experienced designers �Helpful for good OO design �Describe what to do and what not to do when implementing the patterns in your project

Main rule of design patterns �Encapulate things that vary from object to object as separate classes But keep common code together �Example in HFDP book: Ducks

Design patterns help you think about encapsulation �In AI, we talk about “agents” �In graphics, we talk about (rendering) “entities” �Example: Reflex agent with state Goal-directed agent �Entities vs. strategies vs. state

Useful design patterns for Games � Composite: Compose objects into tree structures to represent part-whole hierarchies, let clients treat individual objects and compositions of objects uniformly. � Strategy: Defines a family of algorithms, encapsulates each one and makes them inter-changeable. Strategy lets the algorithm vary independently from clients that use it. � State: Allow an object to alter its behavior when its internal state changes. The object will appear to change its class. � Singleton: ensure a class has only one instance, and provide a global access point to it

Design Patterns in Ogre � Abstract Factory: create concrete instances of abstract interfaces � Visitor: perform an operation on an object (i. e. all elements of the scene graph) without altering the object � Frame. Listener: hook in to receive notices of events from an announcing object � Singleton: enforce one instance � Façade: create a convenient access point for many operations on diverse classes

State class � One pointer to a state instance with subclasses � The state object knows under what conditions it should change to a different active state � described in Ch 2 of PGAIBE, good walkthrough in Head. First design patterns � Eliminates the need for giant if statements � Easier to extend with new substate classes

State-Transition Diagrams �Represent a process specification �Have 4 components States Transitions Conditions Actions �Must have one initial state �May have multiple final states

Answering Machine Example Idle Waiting for call Answering Call Recording Message Rewinding Playing Messages

Conditions and Actions �A condition is an event in the external environment which triggers a transition to a new state �An action is a response sent back to the external environment or a calculation whose result is stored by the system that occurs when the transition takes place

Example of conditions/actions Condition Press Cancel button Press Answer button Ready to receive light goes on Ready to receive button goes out Waiting for Call Action Condition Idle Condition Action End of Call or tape runs out Incoming call detected Answering Call Condition

Levelling State-Transition Diagrams State 2 Can be partitioned to State 2. 3 State 2. 1 State 2. 2 State 2. 4

Guidelines for State-Transition Diagrams �Have all states been defined? �Can you reach all the states? �Can you exit from all the states? �In each state does the system respond to all possible conditions?

Food for thought �How do FSMs (state transition diagrams) relate back to the idea of agents? �How would you implement state using design patterns?