Lecture 8 - Design Patterns | Games Engineering

# Lecture 8 - Design Patterns
### SET09121 - Games Engineering

<br /><br />
Kevin Chalmers and Sam Serrels

School of Computing. Edinburgh Napier University

---

# Recommended Reading

Game Programming Patterns - Robert Nystrom

![image](assets/images/game_patterns_book.jpg)

---

# Review of UML

---

# What is UML?

- UML stands for the Unified Modelling Language.
- UML allows us to model software from various viewpoints.
    - The structure of the software.
        - Class diagram.
    - The behaviour of the software.
        - Use case diagram.
        - Activity diagram.
        - State diagram.
    - The interaction within the software.
        - Sequence diagram.
- UML can be integrated into any software development process.
    - Analysis and requirements gathering.
    - System design.
- UML essentially provides a schematic of our software.

---

# When to Use UML

- There are five diagrams I find useful.
    - Use case diagrams -- overall requirements gathering.
    - Activity diagrams -- flow chart of behaviour.
    - Class diagrams -- main system design.
    - Sequence diagrams -- individual steps and interaction between components.
    - State diagrams -- model object or system state.
- **Use diagrams whenever possible!** 
 - Working out on paper how something works is always easier than banging your head off your code, even if the diagram is rough.
 - Trust me, I've been there.

---

# What are Design Patterns?

---

# What are Design Patterns?

- A design pattern is a reusable solution to a commonly occurring problem when designing software.
- Reusable is the key here.
    - Engineering is about reusing existing solutions whenever possible.
    - Other engineering disciplines have reusable solutions to given problems.
- When we look at our software development problems from a high enough abstraction level we will see lots of areas of reuse.

![image](assets/images/software_development.png)

---

# Reading UML for Patterns

- The important factor we are going to cover is our ability to recognise and implement patterns from UML.
- We're not expecting you to find patterns online, try to determine if they are useful, and then try and integrate them.

![image](assets/images/patterns.png)

---

# Useful Design Patterns for Games

---

# Types of Patterns

- Design patterns can be divided into a number of categories based on the type of problem they try and solve.
 - **Creational** patterns
    - Used for, or dictate, object creation mechanisms.
 - **Structural** patterns,
    - Allow control of the relationships between objects.
 - **Behavioural** patterns,
    - Used to control common communication patterns between objects.
- We have already used a pattern from each of these categories.

---

# Singleton

---

# Singleton Pattern 
![image](assets/images/singleton.png)

---

# Singleton Pattern

- The Singleton pattern lets us ensure that only one instance of a given class ever exists.
- The pattern is good when we want to control and coordinate particular operations in our system.
    - E.g. A game only has one GameController for tracking gamestate and flow.
    - Our game engine wants to ensure control over game entities at particular stages.
- Singletons are good for providing a centralised approach to access a particular part of the system.
    - Almost like providing a global attribute.
- There are numerous approaches to ensure Singleton behaviour.

---

# Composite Pattern

![image](assets/images/composite.png)

---

# Composite Pattern

- The Composite pattern allows us to treat objects and compositions of objects in a uniform manner.
- We tell our game to update, it tells the entity manager to update, which tells the entities to update, etc.
- A pure compositional pattern has components and compositions of components that look the same.
    - In Object-Oriented Software Development you could add buttons to panels, and panels to other panels or windows. The window just treats the panel as any other component.
- We take a less pure approach but we are still composing groups of objects with uniform interfaces.

---

# Iterator Pattern

![image](assets/images/iterator.png)

---

# Iterator Pattern

- The iterator pattern allows us to access the individual elements of a collection of objects (aggregate) in a uniform manner without exposing the collection structure underneath.
- One of the most useful (and oldest) patterns available.
    - Create a collection.
    - Add objects to collection.
    - Iterate through collection when needed and perform individual actions.

---

# Mediator Pattern 
![image](assets/images/mediator.png)

---

# Mediator Pattern

- The Mediator pattern provides a unified interface to a set of objects in a system.
- Objects no longer communicate directly with each other, but instead communicate through the mediator.
- This reduces the dependencies between communicating objects, thereby reducing coupling.
- Mediator is very common pattern in GUI systems.
    - Event based programming.
    - Message passing. 
- The mediator pattern is useful for building messaging systems as it detaches the components. It is a loose coupling approach.

---

# State Pattern 
![image](assets/images/state.png)

---

# State Pattern

- Allows us to encapsulate an object's state within another object.
- We can switch the state object at any time during runtime.
    - Effectively changing the behaviour of the object.
- For example the ghost in PacMan.
    - Current state is chase PacMan.
    - When PacMan eats a power pill the ghost changes state to evade PacMan.
    - When power pill timer runs out state changes back to chase PacMan.
- The different behaviours are programmed in different objects. The ghost simply calls the state class when it updates.

---

# Strategy Pattern

![image](assets/images/strategy.png)

---

# Strategy Pattern

- Sometimes we want to maintain a set of algorithms that an object can execute at given times.
- In general the algorithms that need to be used are not known until runtime.
    - The PacMan example previously code equally be achieved by the strategy pattern.
- Again this is a good AI pattern allowing us to interchange behaviours at given points.
- Notice that the state and strategy patterns are also very similar (structurally identical). They have different purposes but can be used fairly interchangeably.

---

# Manager Pattern

![image](assets/images/manager.png)

---

# Manager Pattern

- We want to have a centralised repository and control point for a collection of objects.
- The manager object keeps track of objects of a particular type and maintains them in a data collection.
- The manager object also performs group operations on the collection of objects when required.
- The manager pattern is something we've identified when making the game engine.
    - There are similar patterns such as the Boss pattern.
    - We are free to define our own patterns.

---

# Data-driven Design Pattern

![image](assets/images/data-driven-uml.png)

---

# Data-driven Design Pattern

- Having each object contain its own data is not-necessarily efficient.
- Data layout in memory means certain functions are going to jump around memory, which is expensive.
- Also, it can lead to costs in copying objects around.
- A better idea is to store data objects in data owning objects.
- A functional object (one that has actual methods) then has access to these objects as required.
- This makes everything much easier to manage -- although some OO purists think it isn't OO any more

---

# Recognising Design Patterns

- You will be surprised how often design patterns pop-up when developing software.
- Some patterns are even built into languages and frameworks that you have used.
    - `foreach` in C# is an iterator.
    - C# also has delegates.
    - Python has decorators.
    - Java provides the observer pattern.
- To recognise a pattern you need to first recognise the problem you are trying to solve.
    - Again, this means doing a higher-level analysis.
- If you find you are doing the same thing over and over again, chances are you have a pattern.

---

# Summary

---

# Summary

- Design patterns are a very important tool in the software engineer's toolbox.
    - Reusable solutions to particular problems.
    - Simplify existing solutions.
    - Patterns have proven usefulness.
- Understanding design patterns is probably the most important skill you can pick up at this stage of your programming education.
    - Object-oriented Software Development touched on these areas.
- Knowing when and where to use a design pattern can save you a lot of effort.
    - And there are a lot of potential patterns out there.