Design Patterns – Singleton

Have you player Nier: Automata yet? Do it! It is currently on my shortlist for my Game of the Year. Just not on PC, that version is… well.. broken… and will probably never be fix becasue budgets and game development.

Anyway, I want to talk about the Singleton pattern, a somewhat controversial pattern. Many people say it is overused and have various opinions why they are bad. I am probably going to get labeled as a paraiah for this and say they are not THAT bad, but can be abused. Many people consider it as an “anti-pattern”. On the flip side, I have worked in code bases that have gone to great lengths to avoid them and have actually just made the maintenance of the porject more of a pain than if the singleton pattern was used in a sensible way. In practice, like all design patterns, it is a programming technique that is part of your toolbox and you may find an ideal solution to use it! You may also find terrible ways to use it!

So firstly what IS the Singleton pattern?

Wikipedia tells us that:

“In software engineering, the singleton pattern is a software design pattern that restricts the instantiation of a class to one object. This is useful when exactly one object is needed to coordinate actions across the system.”

In other words it “ensure a class has one instance, and provide a global point of access to it”.

OK, here is a real world example. Here in sunny England we have a Prime Minister. There can only be one PM of the country at a time. Whenever the PM needs to do something, the same PM is called. The PM is a singleton. Yeah, ok, not a great example because politics, but you get the idea. I prefer my Maccys example in the last post…

There are some genuine use cases for a singleton. These can include Input Systems and File Loading systems. These 2 examples in particular are good candidates for singletons as a lot of other areas of the code base will want to access them. They are also likely to maintain their own state. File Systems may be busy loading files asynchrounously and Input Systems are managing the state of the controllers. You don’t really want multiple instances of these guys. What is going to happen if you suddenly have 2 Input Systems? Which one do you pick?

It is worth noting that there can be several different “kinds” of singleton as well.

Ones that exist all the time:

public class Singleton<T> where T : class
    {
        private static readonly T _instance = Activator.CreateInstance(typeof(T)) as T;
        public static T Instance { get { return _instance; } }
    }

Some that are created when needed, saving memory if they are never called.

public abstract class LazySingleton<T> where T : class
{
       private static T _instance = null;
       public static T Instance
       {
            get
            {
              if (_instance == null)
              { 
                    _instance = Activator.CreateInstance(typeof(T)) as T;
              } 
              return _instance; 
            }
      }
}

And some explicit to working with Unity that I won’t go into here.

Like all design patterns, the Singleton is good at solving a certain type of problem.

However, as I mentioned they can cause issues. Yes, Singletons provide a nice point of access to a point in you program so you don’t have to pass refs to everything. However, the main porblem in my opinion is they encourage coupling. Now while not all coupling is bad, it can be from an architectural standpoint. For example, say you have a racing game that you have a beautifully architected so it is all loosely coupled. Inside is Audio Manager that has been made a Singleton. A brand new, fresh-out-of-uni grad joins your project and is given the task to make the cars make a horrible, expensive-souding crunch noise play when the cars collide. What does he do? He goes into the physics code and couples the audio to the physics. Architecture broken.

There are a lot of other reasons not to Singleton. If you used all the information provided when you type into google “why are singletons bad” you could write a whole book on the subject. They may have emerged from a book that was written in 1994, may not be thread safe, they can be misused, etc. But at the end of the day, they are a tool to solve certain problems. And to be honest, in the right scenarios they can be pretty good tools. Although it is nice to have a really beautiful, loosely coupled and architected system, this could be the most complex thing in the world you have to deal with and when it comes to actually getting stuff done, it could be a massive pain. Yes, bugs maybe harder to track down becasue of Singleton state, but hang on, if you architect them correctly they can perform a single point of contact for a certain system. Which if you find the bug is in that system, it is potentially easier to find?

Basically, although you will read every other book saying Singletons are bad, if you are smart with them, they can actually be pretty powerful tools. Also most of the arguments you will see are around OOP, and in games, there are reasons in 2017 not to go down the OOP route. I have also seen in my time “clever” OOP design make everything a hell of a lot more complicated to jsut get stuff done. In summary, like all patterns, Singletons are a tool, theya re good for some scenarios, but don;t right them off.

Until next time!

Share

Story so far and Work/Life Balance – 184 days remaining

I haven’t spent the whole 16 odd days making the video game. I 1) have a full time job and 2) have a life outside of video games.

And the second one is an important part of the process. In fact it is actually the most important part of the process. As this is an exercise of finishing a game whilst also having a life and not crunching.

My point is, you can still make something from start to finish that is cool in a certain time period whilst still having a life. In the past couple of weeks or so since I have started this I have been out with my friends, had a date, been home to see my family (to be fair that is every weekend), worked a full time job and played games like Nier, Persona and FFXII.

And I am pretty happy with where I have got to now, but for sort of different reasons.

So, the last couple of weeks have been interesting.

I started off by getting my basic stealth mechanics back in place with some basic camera movement. All the logic is there but at time of writing not all hooked up yet as, like I always do, was still trying to nail down the design. Eventually, after chatting to my mates about games like Age Of Empires II and playing games like Shadow Tactics, I went back to trying out the point and click mechanics.

 

Which overall I enjoy. It is making it a unique style of game.

I then went about implementing some more of the mechanics, in particular the player’s abilities


Actually, what I forgot to mention is that I got some cool level building from Tiled, so there is that too 🙂

Today however, which has led to me writing this post, I had  a serious think about the content. Over lunch I started looking through various other Indie games on itch.io. I also played Undertale a bit. I was also reading “How to be fucking awesome” by Dan Meredith on the train home. I consumed a lot of media today:P. The main point that resonated with me in the latter though was “Figure out where you’re at right now”. In the case of the book it is about being brutally honest with yourself about all aspects of your life. It resonated with me as the brutally honest truth was that I was not going to realistically produce all the content I wanted in the time I had if I had to do everything in 3D.

So I called it. I would actually do it in a way that I can do. I can do alright Gameboy colour style pixel art, so that is what I will stick with. I had a few friends offer to help me with the 3D, but they all have lives as well and I didn’t want to subject their free time to my deadline.

So what I have now is something like this:

For those of you who follow me on twitter and are about to dig though my timeline, I will save you the trouble.

 

So yes. It has taking me a couple of weeks to get back to a similar point I was at in February. Albeit with nicer code and using slightly different tech, but that doesn’t matter. Is this much progress? Probably not. Do I regret doing it? Absolutely not. I looked at some of the guys I follow like Ed McMillen and Butterscotch Shenanigans and I took a step back. For refence, you can go into the Basement Collection

I looked at what could be feasibly done in the time I had and what the skills I already had and made a call. I maybe kicking myself later for not. However, the more and more I look at these guys, the more they grow on me.

 

Share

200 days to make a video game

So a couple of people did mention or have said that I like to jump between projects I work on at home and I actually need to finish a game. So, I took a look at what designs I had, what assets and resources I had and what games I knew how to make.

Eventually it came down to my old action stealth game. The 2D one was ok but it seemed like a cop out for what I actually wanted to make. So it was the 3D one that was gonna be the candidate.

In this little experiment I have set myself the target of 200 days to make the game. The definition of “made the game” is something that is playable from start to finish with at least some of the final assets. So not quite the finished product, but also not just a vertical slice. You might say an “early access” kind of thing. An alpha build.

I am not sure how this is going to go, it may be an utter catastrophe, but hey there it is. It is written down, in ink, on the internet. Let’s go!

Share