1. Object Oriented Analysis & Design Game Patterns

2. Contents  What patterns are  Delegation  Game Loop  Scene Graph  Double Buffering  Component  Object Pool  Singleton  Decorator  Observer  Factory Method  Decorator  Composite 2

3. What Patterns Are  Patterns are good solutions to common problems  Patterns are NOT code  Patterns are ideas about how to solve a problem  They are general solutions to a group of closely related problems  Patterns are well-known solutions to problems  You would discover most patterns yourself... eventually 3

4. Delegation 4  A delegate is someone who you ask to perform a job on your behalf  In programming, a delegate is an object that performs the work of another object class Delegator { private: Delegate *delegate; public: void doSomething() { delegate->doSomething(); }

5. Delegation 5  Delegation allows you to change what doSomething() does by  Changing the delegator object  You could create a subclass of Delagator and override doSomething() but  You have to create an instance of Degator or Delegate  In order to change the behaviour, you have to destroy one object and create a new one  If you want to add new behaviour, you must derive a new subclass and code the logic to use this into your game

6. Delegation 6  By using delegation  You can alter behaviour any time by changing the delegate  You can create and use a new delegate any time without changing the code in the delegator  Delegation is more flexible than subclassing  Subclassing has early binding  The functionality is bound to the class at compile time  Delegation allows for later binding time  The functionality is bound to the delegator at run time  Late binding allows for far more flexibility

7. Game Loop  Description  A way to structure games that render frame-by-frame with movement calculated between frames.  Motivation  Games involve  handling user input  Performing the game logic  Rendering the game  It was recognized that this was common to all games and that there was a common way to architect all games 7

8. Game Loop  Solution  Create a loop that repetitively performs the operations in rendering a frame in a game while(keepRendering) { getUserInput(); updateScene(); renderFrame(); } 8

9. Game Loop 9

10. Scene Graph 10  Description  An organized technique to represent all objects in a scene to make it easier to render the scene  Motivation  As games become more complex, the number of objects grows  This makes the rendering of the scene more difficult  It makes sense to automate the rendering of the scene

11. Scene Graph 11  Solution  Create a data structure which will store  A reference to every object in the scene  The position, orientation and scale factor of every object  The game loop will now update the position and orientation of objects in the scene graph  The game engine can render the scene by  Traversing the scene graph  Rendering every object at the indicated position, orientation and scale

12. Scene Graph 12  Implementation  For a tile-based game  The graph could be stored as a 2D array of objects  The engine would traverse the array, drawing objects in the correct position, orientation, and scale  For a non-tile based game or one with complex objects  Use a graph structure  Each node has  A position, orientation and scale  A list of objects at that position  A list of child nodes whose position, orientation and scale are relative to that of the parent node

13. Scene Graph 13

14. Double Buffering 14  Description  Smooth graphics can be displayed by drawing the frame into an off-screen buffer and swapping it with the frame buffer when the drawing is complete.  Motivation  When graphics are drawn directly to the screen buffer  The screen is refreshed before the frame is completely drawn  The screen appears to flicked to the user  This is because the user is seeing part of one frame and part of the next

15. Double Buffering 15  Solution  The solution is to use 2 buffers  1 that is rendered onto the screen  1 into which the next scene is rendered  When the scene is rendered  The pointers to the 2 buffers are swapped  The next screen refresh will show the new scene  The old screen buffer is ready for the next scene to be rendered into it

16. Implementation 16  Most modern graphics systems have automated support for double buffering  Usually, you just configure your graphics system to use double buffering

17. Component 17  Description  Complex behaviour of an object is spread over several classes so that a change in one behaviour does not require a change in other behaviour. This also allows common behaviour to be shared among objects.  Motivation  When creating a game object it is common to  Place AI logic in the class  Place rendering logic in the class  Place physics calculations in the class  Place update logic in the class  This results in  Overly complex classes  The combination of separate logic

18. Component 18  Solution  Separate each responsibility into a separate class  Build the game object so it refers to the classes representing each responsibility  This has the benefits  The logic for each responsibility is separated  Several game objects can now share common behaviour by referencing the same behaviour class  You can change the logic in one behaviour class without affecting the other behaviour classes

19. Component 19

20. Object Pool 20  Description  An object pool holds a collection of objects which are expensive to create and destroy.  The pool allows objects to be used and then returned to the pool when they are no longer required. The next time an object is needed, it is take from the pool for use.  Motivation  The constant creation and destruction of objects is a very costly series of operations.  When this involves large numbers of objects, as in a particle system, this can waste a lot of time.

21. Object Pool 21  Solution  Create a pool which will create a large number of objects  Track the objects which are in use and the ones not in use  Provide operations  To retrieve an object not in use from the pool  To return an object to the pool and mark it available  One of the design goals will be to manage the retrieval and return of objects from and to the pool as efficient as possible  We also need the class stored in the pool to provide a method to allow the objects to be initialized before use

22. Object Pool 22

23. Object Pool Implementation 23

24. Singleton 24  Description  Restricting a class so that only one instance of the class can be created  Motivation  Many classes only require one instance and more than that will cause problems for the game. Consider:  One game engine  One scene graph  We need a way to ensure that only one instance of these classes can be created

25. Singleton 25  Solution  Make the class constructor private  Declare a static pointer to the single instance initialized to NULL.  Declare a static method getInstance() which will build an instance if there is none or return the existing instance if there is one

26. Singleton 26  Implementation class Singleton { private: static Singleton *theInstance; Singleton() {... } public: static Singleton* getInstance() { if(! theInstance) theInstance = new Singleton(); return theInstance; }

27. Decorator 27  Description  Allows visual decorations to be added or removed from a game object without deleting and recreating the game object  Motivation  During a game, the visual appearance of objects will change  A character might appear different due to a power-up  A character might glow as a result of a spell  We want to be able to add / remove these decorations  Without destroying the original object  Without changing the type of the reference to the original object

28. Decorator 28  Solution  The solution is to  Create the GameObject class  Make GameDecorator a subclass of GameObject  Add a pointer to GameObject within GameDecorator  Override the methods in GameDecorator to call the same methods on the GameObject the decorator has a pointer to

29. Decorator 29

30. Decorator 30 class GameObject { public: void doSomething() {// code to do something } void render() { // code to render game object } GameObject& decorate(GameObject decoratee&) { return *this;} GameObject& undecorate() { return *this; } }

31. Decorator 31 class GameDecorator: public GameObject { private: GameObject *decoratedObject; public: void doSomething() {decoratedObject->doSomething(); } void render() { decoratedObject->render(); // code to render game object } GameObject& decorate(GameObject decoratee&) { decoratedObject = &decoratee; return *this; } GameObject& undecorate() { return *decoratedObject; }

32. Decorator 32