What a game designer needs to know about design patterns

1. What a game designer needs to know about design patterns

2. 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?

3. 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

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

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

6. 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

7. 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 • FrameListener: 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

8. 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 Ch2 of PGAIBE, good walkthrough in HeadFirst design patterns • Eliminates the need for giant if statements • Easier to extend with new substate classes

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

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

11. 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

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

13. Levelling State-Transition Diagrams State 2 Can be partitioned to State 2.3 State 2.1 State 2.2 State 2.4

14. 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?

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