Design Patterns: The Strategy Pattern

Have you guys played Pyre yet? No? Well do. It is one of my favourite games this year. It is also a sort of Strategy game… kind of… it is hard to define what it is really, but it has strategy elements!

In this post I am going to talk about the Strategy pattern. In wikipedia term, the Strategy pattern is a behavioural software design pattern that enables an algorithm’s behaviour to be selected at runtime. Fancy.

In game development terms, we could look at enemies. In an action game, maybe you want the enemies to have different behaviours when they fight the player. I am going to use like an Ace Combat style game as an example. Each Enemy Pilot has some standard stuff, but we want the pilot AI to do many different things. We could use the strategy pattern for this.

public class EnemyPilot
{
    .. Other code here
    private IPilotAI _pilotAI;
    void Update()
    {
         _pilotAI.Update();
    }
}

In the above C# code, I have a class that is the EnemyPilot that contains the IPilotAI interface that we can set at runtime. We can now make a number of AI behaviours that use the Pilot AI interface. This is much better than inheriting from the whole EnemyPilot class each time and we are encapsulating the only thing that varies, i.e. the Pilot AI. And really it as that. Cool huh?

C++/UWP Tutorials – Introduction

As part of my own personal development plan one of the parts I want to continue getting better at is console development and also revise all my C++ development. One of the ways I can do that easily, whilst also share some tutorial posts is through UWP dev and C++.

Why UWP? In Lindsay Cox terms, I would say that UWP is like the gateway drug to console development. A bit more than XNA was back in the day. Why? Well it allows you to develop Xbox One Games in C++ and Direct X. Like the “big” boys.

Before I go on, I am a staunch believer in it DOESN’T MATTER HOW YOU MAKE VIDEO GAMES. If you use GameMaker, MonoGame, Unity, Unreal, Windows Forms, Pascal, whatever. So when I say “big boys”, I am being a little bit facetious.  This is another way to get games made.

So what are we gonna do? What is the end goal?

Back at Uni I was set the task of creating the above graphics demo. It is a little dated now, and the code is student level rushed, but I want to get something similar running on Xbox One.

Pretty cool.

Where do we start?

Well I am not going to go over the basics, Microsoft have done that for us. Before We get stuck into building our cool snow globe, first stop is here:

https://docs.microsoft.com/en-us/windows/uwp/gaming/tutorial–create-your-first-metro-style-directx-game

This is literally just to get familiarised with some concepts of UWP development. We will be starting from “scratch” later and the code will be on github.

See you soon!

Design Patterns – Observer

Today I am going to talk about the Observer Pattern. From Wikipedia once again:

“The observer pattern is a software design pattern in which an object, called the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods.”

In plain old English, the Observer pattern “Defines a dependency between objects so that whenever an object changes its state, all its dependents are notified.”

What does this amount to in the real world. So you know when you sign up to one of those voucher code sites for a specifc type of voucher and you get a notification whenever there is a new voucher type available? That is basically the observer pattern.

In game development a common use case is an Achievement system. It is an example that has been used multiple times, but hey, if it ain’t broke, don’t fix it. In a game, there are Achievements that can be obtained through a variety of different methods. Maybe you are working on Final Fantasy 12 and want to add an achievement that the player gets for shouting they are Captain Basch 1000 times.

If we aren’t clever about how we design this system, we could have a crazy spaghetti like thing that is linked to every part of our code base. This is bad, as the likely hood of you breakign the achievement system if you make a change or vice versa is pretty high. Are you thinking about using a Singleton for this? DON’T. This is a prime example of where not to use a Singleton. We want our nice Achievement system all lumped in one place and we don’t want to tightly couple the system to every single part of the code base. This is where the Observer pattern comes in. The pattern allows one piece of code to announce something has happenned without actually giving a damn who recieves the notification.

Let’s look at some nice C# code. Essentilaly the code can be broken down into two parts. The Subject  and the Observer.

First we will take a look at the subject. The subject holds a list of all the observers interested in getting information ewhen something cool happens. When said something has happenned, it sends a notificaiton to all the observers.

public abstract class Subject
{
    List<IObserver> _observers = new List<Observers>();
    
    public void Notify()
    {
        _observers.ForEach(x => x.OnNotify());
    }

    public void AddObserver(Observer observer)
    {
        _observers.Add(observer);
    }
    public void RemoveObserver(Observer observer)
    {
        _observer.Remove(observer);
    }
}

And to reiterate somewhat, the Observers are the objects interested in doing something when the event happens.

public interface IObserver
{
    void OnNotify();
}

In fact rather than going into the previously mentioned Achievement system, I am going to talk about the “I’m Captian Basch” bit in FF12.

What I want is the NPCs in a certain area to see if they hear it and increase the notoriety. In the below code I have already added the NPCs as Observers from some other system.

public class BaschShouter : Subject
{
...
    private void OnShoutedImBasch()
    { 
        Notify();
    }
...
}

So every time the player refutes Ondore’s lies:

public class NPC : IObserver
{
     public void OnNotify()
     {
          if (NPCIsInEarShotOfPlayer())
          {
              DontBelieveOndoresLies();
          }
     }
}

You also may have some NPCs that are loyal and stop you shouting and you have also registered those:

public class NPCLoyalToOndore : IObserver 
{ 
    public void OnNotify() 
    { 
       if (NPCIsInEarShotOfPlayer())
       {
            ChastisePlayerForLyingAboutMyLeige();
       }
    } 
}

And there we have it. Observer pattern.