Learning Unity — The Singleton Design Pattern
How and why to implement the Singleton in your Unity games
Today we’re going to talk about a design pattern — the Singleton. What is a design pattern? A design pattern is a known reusable solution to a commonly encountered problem. In the field of software engineering, many common problems have been identified and design patterns have been formulated to address these common issues.
Now, I know some of you are probably thinking that you’re not a professional programmer, you’re new to Unity, how can I expect you to understand these advanced computer science techniques?
To that I will say: don’t sweat it. This particular pattern is very simple and we’re going to step our way through it.
Games built in Unity are prone to many of the same issues that plague software development of all sorts, so learning this pattern gives us an excellent tool for our future efforts.
Why Singleton?
In software, it’s important for there to be only one instance of certain things. For instance, if there were more than one instance of the file system, matters could very easily get confused and huge problems could result.
The stakes may not be quite so high with Unity projects, but nevertheless there are definitely some things that would be best achieved with only a single instance.
For example, let’s think about audio sources in-game that may not have any particular in-game origin, such as the music. We wouldn’t want multiple music sources each playing their own tracks, would we? Probably not.
How Singleton?
Now for the real question: how do we do this? Fortunately, as I wrote earlier, this is very simple.
First, create a new script in Unity, then open it in your editor of choice.
We can get rid of this default code if we want — none of it is necessary for making a singleton class.
The first thing we’ll need for a singleton is a variable to hold the singleton’s single instance. There are three things that are needed for this variable.
The first is that it is of the same type as the class we are creating. In my example, I’ve named the class MySingleton. Therefore the variable needs to be of type MySingleton.
The second is that it is private level access. We do not want any other objects messing with the value of this variable.
Finally, the variable needs to be of static type. Why it needs to be static will be apparent soon.
Once the variable is created, we next need to make a property to access that variable. This property will be static like our variable, but public instead of private. Having the property be both public and static will allow us to access our singleton class freely from other scripts.
This property will also only implement the get accessor. Once again, we don’t want other objects changing the value of this property or the instance variable.
Within the get accessor, we want our code to be fairly straight forward. The main thing is to return the instance variable. One other nice thing to do, however, is to check if the instance variable is null or not. If it is, that’s an issue and should be logged for further investigation.
Next we want to actually assign the value of the instance variable. We want to do this at the earliest possible opportunity, so we will implement the Awake method and do it there. All we need to do here is assign to the instance variable the value this. In this context, this represents whatever object the script has been attached to.
Speaking of which, now that our singleton script is complete, the last thing we need to do is attach this script to an object in Unity to put the singleton class into play.
What next?
What we have accomplished here is implement the singleton pattern on this script, but at this point the script doesn’t really do anything. What comes next is giving the script purpose.
As I stated earlier, the point of the singleton design pattern is to ensure that there is only one of something. It’s perfect for scripts that manage certain aspects of your game, such as the audio, player controls, or quest management.
Conclusion
Learning design patterns such as the singleton can really help us with keeping up best practices and getting ahead of potential issues with our projects. The singleton is an excellent starting point, and I highly recommend looking into additional design patterns.
In the next article, we’re going to see how we can implement a “loading screen” that helps us transition more smoothly between Unity scenes. Until then, thanks for reading.