Design Patterns: Object Pooling

Image result for Golf Story

Today’s image is from Golf Story, a Nintendo Switch Game that reminds me a lot of Mario Tennis, one of my favourite GBC games.

This article is going to talk about Object Pooling.  The idea behind Object Pooling is to improve Memory usage by reusing object from a “pool” of a fixed size instead of allocating and freeing them individually. I am going to put this in Unity terms as it is what I do professionally every day and the best way I can explain it.

In Unity you have Instantiate and Destroy methods that are used to Create and Destroy objects. For objects that have quite a long lifespan, these methods don’t cause a massive CPU overhead or at least don’t really interrupt the experience (there are of course various scenarios where this case be the case, but for this example let’s go with this). For objects with a short lifespan, this can cause issues. If you have a lot of objects that are created and destroyed per second then

You're going to have a bad time

The CPU needs to allocate more time to dealing with this creation and destruction. With Unity and also managed languages in general like C#, there is also the magic of Garbage Collection, i.e. a system that deallocates memory that is no longer in use. Depending on what you are working in, Garbage Collection can happen without you really knowing and also in ways under the hood you don’t expect. If you are calling Destroy a lot in Unity you are going to trigger the garbage collector. And triggering the garbage collector likes to slow down CPUs and can cause noticeable slowdowns in gameplay.

Object Pooling can be a way around this. The idea is to create all the objects you’ll need before the gameplay. Instead of actively creating new ones and destroying old ones, the objects get reused from a pool.

To put it another way, you are creating a pool that has a collection of reusable objects inside of it. Instead of creating and destroying these, the objects have a state of whether the game is actively using them or not. Before your gameplay you initialize the pool which creates all the objects you will need up front and sets them to the not being used state. When you need a new object, you ask the pool for one. It finds an available object that is not currently in use and returns it. When the game is finished with the object it is freed up again. Objects can be used without having to create and destroy them all the time.

There is a caveat to this though. You are essentially deciding how many you need of a certain amount of object before you run the game. You could get into one of two scenarios. You may have a smaller pool of objects that save on memory however when you get to your gameplay, you find you have too many. On the other hand, you may assign the number for the pool to create to be more than you will ever need, using more memory.

There is a way to get around this. You can make an object pool that expands if it runs out of objects. If you reach the maximum amount of objects in the pool, the pooling system can create one and add it to the current pool. Although there will be a very small overhead of creating the object, it is better than creating and destroying these object all the time like a maverick.

The thing we haven’t addressed though is when we should use them. Well, object pools are designed for when you need to frequently create and destroy objects that are of a similar size (ideally identical). If you look at a bullet hell game, you don’t want to be creating and destroying all those bullets all the time as it will most likely kill your performance. Similarly with particle systems. That continuous smoke cloud coming out of your Volcano will want to use pooling.

Essentially, that is a brief overview of Object Pooling. If you are creating and destroying lots of similar objects in your game, then Object Pooling is for you!


No one cares about your indie game. So let’s make them!

It has been a very long time since I have done a blog post, for various reasons, however it is 11pm on a weds and I am waiting for the train. Now is a better time than ever.

So why the sudden post. Well a couple of my fav devs wrote an interesting article about a reverse indiepocalypse. For those of you that don’t know, it is a theory that making indie games is impossible and they won’t exist soon for various reasons. What I just said is a massive over simplification amd if you want to dig deeper, gooogle is your friend.

In reality right now, there are too many indie games. 
The app stores, itch, steam, psn are all filled to the brim of games. Yes I go to PSN on console and it tries to sell me some unknown game I have no idea about.

And why the hell should I buy them? There are so many titles and I have a finite amount of time and money. 

For example, let us say you are a developer at a relatively well known company and you make a cool puzzle game. You even document really well how you made it and release it to the world. You release it on store x y and z. You make a grand total of 30 quid and you wonder why.

In blunt terms. The majority of consumers do not really give a damn about you. And in reality why should they. This is nothing new. Your mechanics may be awesome. Your presentation spectacular. That does not sell a game alone. And it is upsetting how many people think “it will all be ok” in this way.

How do you solve it? 

Realise that noone cares. Seriously. Once you do that you will actively want to make people care. Your gane will not sell on merit alone in 2017 when everyone and their mum can make a game.

How do you do that? Well ask yourself, who is the audience. You are not going to get everyone to play the game. If it is an adventure game, why not send a free copy to those that stream adventure games. 

My example here is a small win, but a win none the less. I released Storm Ship Shiro on mobile. I made very little but it was a night out worth of cash. And I had a good one. Regardless, I was already following a PS Vita specific streamer. I asked him if he would stream my game. I was 2nd in the PSMobile store for a long time after that stream.

Now, I can prempt your argument. Yes that store was dead and Shiro was fun. Fundamentally though, if I hadn’t made the effort I would have been bottom of that store. 

I am not saying it is that easy. Of course it is not. What I am saying is you have to know that noone is gonna care and you have to make them. 

A hard recap of you making the game is not gonna do that either unless you are already well known. Making and finishing games is hard. Funnly enough it is pretty similar for everyone in some shape or form. As a consumer, I kind of do not really care you lived off beans on toast for months because you did not have time to feed yourself properly because you were making your game.
Harsh but true. 

In 2017 in a massively overcrowded market, you cannot just upload your game to itch, google play, the app store or whatever and expect consumers to care. There are a lot of games released everyday. Use marketing and other creative ways you can think of to make your game stand out. Or even better, when you are at the inception of the game, ask who your audience is and think at the start how you are going to make those people. Earlier the better. Analyse those markets. 

I hope this helps someone. I know it may not be presented in the best of ways but I hope the underlying point gets across. Your game may br awesome (amd if it is let me gace a play :p), but in the crowded markets of today, competition is tough. I want to see cool, new, unique  games and I do not want them to die on something as simple as this 🙂


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()

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?