🤑 Indie game store🙌 Free games😂 Fun games😨 Horror games
👷 Game development🎨 Assets📚 Comics
🎉 Sales🎁 Bundles

Quick question

A topic by gualt created 127 days ago Views: 74 Replies: 5
Viewing posts 1 to 5


What is the general feeling towards Singletons? Because i know they have a very bad stigma but i quite like them so i'm wondering if using one (or two) is a bad idea?

Thank you, Gualtiero

Given the starting project makes use of static members (the Arena class uses static members to convey the arena width/height, if you have more than one arena at the same time it can cause issues) in a number of scripts, you're probably fine.

Though you should in general use programming patterns as appropriate, and not depending on how popular they are.
If a singleton makes sense in your case I'd say use it.

Yeah, that's what i thought and what I'm doing but there's more than one person in my uni that just goes mental whenever i try to use a Singleton, so i wanted to make sure xD

Singletons can be amazing and I make good use of them, I have never come across anyone with such a stigma against them but I also know they can cause lots of problems in handled badly.

Use them well and they can make everything much easier!

Hi All,

Singletons are used often in the game industry, in some projects I've worked on they have been used too often and can end up creating confusion. One or two can be helpful but the more you add the more difficult to follow the code can become. Additionally, you can often achieve the same effect with different approaches.

For example, if you want to force a class to have only one instance, then you can store a static instance on Awake and if you find the instance has already been set then print an error and destroy the extra copy. This method of ensuring a class doesn't exist more than once does not require public access to the instance. If you want a set of helper functions that you can reuse anywhere, this can be a class of public static functions which are accessible from everywhere but the class itself has no state and no instance is required.

When the Gang of Four wrote the original design patterns book they stressed that Singleton should be used sparingly. When it isn't used sparingly it usually indicates that code has been poorly thought out before being written, as there is almost always a more elegant solution.

Also remember that Unity is based on the Object Component pattern, if you do not know what this is then look it up, you should avoid OOP methods when using Object / Component. Write small components that can be reused on multiple objects, rather than inheritance. I'm not suggesting that you can't use inheritance only that there may be better / smarter ways of reusing your code.

If you have any questions then lets discuss them!


Hello, thank you for your answer, I am currently using a couple Singletons for my Managers mainly because I assume you wouldn't ever want two game managers to be present at the same time and for ease of use, I find it nicer to use GameManager.Instance then to find it within Unity. But again using the method you suggested, and since all the objects in the original projects were made child of the game manager, they already have a reference to the game manager without it being public...

In retrospective using a system similar to the one that in the original project communicates between the SceneManager and the Game might have been better and, if I manage to finish tweaking the final things before the submission, I might try change it to be more similar to that even though that could mean creating a lot of events for a lot of possible situations which isn't probably the best ether.

But for now it's probably better to focus on making sure the game doesn't break and is at least a bit fun to play.

Thanks again,