Writing Singletons, Help

I have 2 Singleton example scripts (A and B)

Is there any difference in the two?
Is one way better than the other, perfomance or otherwise?

Please explain

Singleton example A

Code (CSharp):

1. using UnityEngine;
2. using System.Collections;
3.  
4. public class gameManager : MonoBehaviour
5. {
6.  
7.     public int score;
8.  
9.     private static gameManager mySingleton;
10.  
11.     public gameManager Instance
12.     {
13.         get
14.         {
15.         return mySingleton;
16.         }
17.     }
18.  
19.     protected void Awake ()
20.         {
21.         mySingleton = this;
22.         }
23.  
24.         public void SetScore (int i)
25.         {
26.         score += i;
27.         }
28. }
29.  

Singleton example B

Code (CSharp):

1. using UnityEngine;
2. using System.Collections;
3.  
4. public class gameManager : MonoBehaviour
5. {
6.  
7.     public int score;
8.  
9.     public static gameManager mySingleton;
10.  
11.         void Awake ()
12.         {
13.         mySingleton = this;
14.         }
15.  
16.         public void SetScore (int i)
17.         {
18.         score += i;
19.         }
20.  
21. }
22.  

Are Singletons better than SendMessage and GetComponent?
context, I have 3 Triggers, when an object Enters each Trigger 1 is added to that Trigger's corresponding int variable in the Game Manager Script on a different object from the Triggers

Edit, sorry I had set my static to public instead of private in Singleton example A

 

In the case of Example A you may want to make the static singleton non-public or else it kind of defeats the purpose of making a property/getter for it that is public. Otherwise Example A seems like a smarter idea so that outside classes can't set the singleton.

 

Code (CSharp):

1. using UnityEngine;
2.  
3. public class Game : MonoBehaviour // Why "Game Manager"? Why not just call it "Game"?
4. {
5.     int Score;
6.     static Game Instance;
7.  
8.     void Awake()
9.     {
10.         if (Instance == null) Instance = this;  // If there is no instance, there is now.
11.         else Destroy(this.gameObject);            // If there is already an instance, destroy this new one.
12.     }
13.  
14.     public static void AddToScore(int points)
15.     {
16.         Instance.Score += points;
17.     }
18. }

Just write methods to do all your work. Let your singleton worry about referencing its instance, while all your other classes enjoy a wonderful, simple syntax.

Now you can do this:

Code (CSharp):

1. public class Test : MonoBehaviour
2. {
3.     void Start()
4.     {
5.         Game.AddToScore(10);
6.     }
7. }

 

The whole point of the singleton pattern is that outside classes can gain access to the same class without needing an explicit reference. It makes sense (at least to me) to do this for one game object that performs some higher level functions.

 

I wouldn't call any of both examples in the first post a real singleton.

 

Why because any instance that is instantiated wll become the single instance? Lol

 

I didn't quite understand if that was kinda ironic or not, but in Example A and B, the other instances keep 'living' (if not GC'ed) and he'd reset all the values being hold by the represented instance. That may not be want he wants.

Maybe it's just me, but I find singleton rather misleading in this case and call that approach 'hold a static reference to the latest created instance'.

Note that i was only referring to the first post, not to yours.

 

Another way is:

Code (CSharp):

1. public static Game Instance { get; private set;}

 

I thought the whole point of a singleton was to be able to grab a "single" instance of that class from somewhere else. The method that you use to set it shouldn't make a difference whether it be the latest instance or its hash code, name, etc. The instance that you get should be the most important instance.

 

I might be wrong of course, but I was actually pretty sure there's supposed to be only one instance at a time.

That's why you usually hide the constructor (implementing it as private) so that you cannot explicitly create a new instance from outside. Instantiating is the business of a method or a default initialization in this case. When trying to access that one single instance, you have a static method or property to check whether it has already been created and if so, return it and if not, create a new one and return that one.

In Unity this translates pretty much to what @Misterselmo has already posted as an improvement (imo).
In order to complete that, you could make the variable (which will hold the instance) private and implement a getter method instead.

 

If I am going to use a Singleton, I make it auto-destroy if it detects another instance. Right now, it seems like I could create 50 instances, and the "Instance" variable would simply point to the most recent created. while everything else just exists uselessly in the scene.

 

Yeah, the whole point of the singleton is really just to hack your way out of the rigid C# class/reference box. How can my custom class inside of "Item.cs" that doesn't inherit from MonoBehaviour because it doesn't need to for any reason call a method in Game class in "Game.cs"?

They have no relation.

So I create a reference to a GameObject that may not even exist, or duplicates may exist... through the UnityEngine namespace and call scripts through the reference? Pointless step, repetition, slows down scripts and costs more than just having a single static reference inside the class itself.

Plus, syntax is sweet as candy with singletons.

What's better?

Find a game object of this type and the create a reference to its script and then call this method of that script.... 15 null reference exceptions later... Your head explodes from sheer inefficiency.

Or

Game.Save();
Game.Load();
Game.AutoSave();
UI.SetHudOpacity(0.7F);

 

for theOk so most of this is over my head, but I'm getting the sense that my 2 examples are inefficient

@Suddoha
you always post short answers with no explanation
In this post you only posted to say you didn't think my examples were real Singletons, without bothering to explain why, in fact if @Misterselmo hadn't commented on your post you probably wouldn't have explained your logic

Well, thanks for the help guys

 

For OP's question.

The difference is that A is encapsulated making it that only GameManager can set the singleton instance.

B has the instance as a public field, so it can be set by anyone.

I also agree with Suddoha, it is not a true Singleton. A Singleton restricts the instantiation of a class to one instance.
http://en.wikipedia.org/wiki/Singleton_pattern

But because you can't control the constructor of components/monobehaviours in Unity, it's a little convoluted to do so. You can't just make the constructor private. Most people monitor on the 'Awake' method to see if an instance already exists and destroys the new instance if it does (or favor the new instance and destroy the old).

Because you lack any code that enforces the single instance. Then in option B I could create 3 GameManagers, the newest GameManager is the 'instance'. BUT if I were to get a reference to the 1st or 2nd for whatever reason, I could then set the instance to one of those if I so desired.

This breaks the OOP idea of 'encapsulation'.



Note the 'instance' static getter isn't what makes something a singleton. I could create a singleton that only ever one instance of exists... but is not globally accessible.

So when Misterselmo says:

That is a situation where you may consider creating a Singleton that has a global point of access. But that doesn't mean that's the "whole point" of a singleton.

Lets say I were to have a class within a class with an access modifier of private. I then only create a single instance of it, and give no way to create a second instance. But this single instance of this class is used only in the scope of the class that wraps the private class. The mechanism for forcing the single instance is the fact it's a private class within another class.

Code (csharp):

1.  
2. public class SomeClass
3. {
4.     private static SubSingleton _singleton = new SubSingleton();
5.  
6.     public void Foo()
7.     {
8.         _singleton.Foo();
9.     }
10.  
11.     private class SubSingleton
12.     {
13.          public void Foo()
14.          {
15.          }
16.     }
17. }
18.  

This is effectively a singleton, but has no global access. It's only accessible within the scope of inside SomeClass. Furthermore SomeClass is not global and needs an instance to even be called.

You might ask why in the heck this would even be needed... I'm not sure. How about maybe SubSingleton is a specialized database interpretor, and SomeClass is a factory class that uses said interpretor. The database should only ever have one connection, and it should never be accessed directly from anywhere but within the factory.

This example may sound convoluted. But that's more a result of the fact that Singleton is inherently flawed as a design pattern. I'm not saying it should be avoided at all costs... I'm just saying it is flawed and that fact should be considered when implementing it.

 

You lost everybody a long time before this, but here you even lost me. The point of explaining something is to make it easier to understand. I once heard someone say, and I agree, if you can't explain it to a five-year-old... you don't really understand it, yourself.

 

That's why I posted example code.

 

You said it! Just 'cause you can doesn't mean you should, unless you're just trying to be a smarty pants... in which case, kudos.

 

You take that out of context ignoring the sentences afterward. The statement "I'm not sure" is rhetorical.

 

Okay, well it's probably inherently flawed. But WHY am I using it in the first place? The reasons I said above. I can't get around the fact that in Unity I don't have a Main() entry point... I'm effectively living in a universe where I have no starting points, bearings, etc. So, a Singleton is my way of creating a spaceship that travels through this universe of chaotic MonoBehaviors and GameObjects.

I have to say, I'm not sure if I'd ever use a singleton outside of Unity. It's kind of like Goto Line 17, just looks kind of trashy to see in code.

 

Yes, that's why you're using it. That's why I said:

You didn't say that's 'why you are using it in the first place'. You said that your reason for using it is the whole point of the singleton pattern:

I was clarifying what the whole point of the singleton is. And the whole point of the pattern is to enforce only one instance of a class to ever exist.



And if you can't think of a reason to ever use it outside of Unity means you don't have experience with coding outside of Unity. I have almost a decade of experience programming games, business software, rich internet applications, database systems, and more. And Singleton has been used in all of those settings... not always my choice, but that's what happens on a team. The boss says jump, you say how high.

 

k

 

I don't wanna sound rude or so, but isn't it enough to give a hint that something might be wrong (in this case, that's is not really that design pattern according to it's definition)?
I know you've asked what could be improved and as i didn't quite understand your approach to implement the singleton pattern, i simply commented that it doesn't quite match the idea of the pattern.

At this point, if you are convinced that it does fullfill the idea and the other person, which is me in this case, is wrong, you can simply ignore it. Noone's perfect.
Nevertheless, if you feel confused, it's time to look things up on the internet, documentations or literature because it's the 'extra' on top if someone takes the time to explain something (which could have been a pretty long post in this case - so it's better to look it up either way).
I personally do not have the time, maybe not even the ability, to explain such things in a 100% correct and detailed way, as I'm not even a native English speaker which means it takes additional time to find the correct terms to explain it.

As i mentioned, it's not meant to be rude, disrespectul or offensive.

 

There's really no great way to create a Singleton that derives from MonoBehaviour. I would personally avoid it unless you have a really, really good reason or a use case that demands MonoBehaviour functionality.

That being said - if you do need it then I would throw an Exception in Awake if Instance isn't null instead of just silently covering it up by destroying the object. I'd rather know upfront that I muffed something instead of trying to track down obscure behavior later.

@Misterselmo - Why are you being unnecessarily combative? In either case, you may argue that Singletons are "trashy" but I'd argue that your Singleton implementation certainly isn't helping the situation any. You've essentially created a mutant static-singleton hybrid under the guise of "clean syntax".

 

Using Singletons in Unity I would take with a pinch of salt. If you are determined to use the pattern I suggest having only 1 in the entire program. Then, if you need access to other global managers, i.e. UI,ScoreManagers etc. give that 1 singleton references to those things instead of making them singletons themselves.

Code (CSharp):

1. public class Game : Monobehavior
2. {
3.   private static Game Instance;
4.  
5.   [SerializeField]
6.   private UIManager m_uiManager;
7.   [SerializeField]
8.   private ScoreManager m_scoreManager;
9.  
10.    public static ScoreManager Score
11.    {
12.      get
13.       {
14.          return m_scoreManager;
15.       }
16.    }
17.  
18. public static UIManager  UI
19.    {
20.      get
21.       {
22.          return m_uiManager;
23.       }
24.    }
25.   void Awake()
26.   {
27.      if(Instance == null)
28.      {
29.         Instance = this;
30.      }
31.      else
32.      {
33.        Destroy(this.gameObject);
34.      }
35.    }
36. }

 

I agree with @A.Killingbeck:
Do not have more than 1 singleton. (Game/GameManager/God/whatever you want to call it).. otherwise it will complicate inheritance hierarchy and you will find yourself running everywhere trying to understand that should be simple.

It might be tempting to use multiple singleton, but trust me.. you don't want to have to go through singleton rehab!


By the way @Misterselmo, nice explanation! Kudos!

 

Could you explain why it complicates the inheritance hierarchy? I never created anything without having several manager classes that inherit MonoBehaviour that were singletons. I don't understand what the issue here could be at all.
Of course everything can be abused and everything can be used in ugly ways. Having singletons for everything is certainly not a good idea, but having them for well defined classes makes a lot of sense.
In my opinion there is no difference between having one singleton which stores the references to objects that are also supposed to be unique or making them directly singletons.

 

Unnecessarily combative according to you... I think you're being unnecessarily intrusive about my conduct and how I choose to word my posts. I use a lot of hyperbolic arguments, and I tend to be satirical. Ultimately I'm here for discussion and to have a good time, not to discuss the way people perceive me and my attitude. If I wanted that I go to a psychiatrist. Clearly some people appreciate my help and contributions, so maybe that should be a hint.

Yes it is a mutant static singleton hybrid under the guise of doing whatever I have to do so that I can code in a way that makes sense to me in unity. It's a monster but its my monster and I think we're going to get along just fine.

The whole point is that this object will be present in the editor. I understand that you're a real programmer, unlike the rest of us, but I like using the Unity editor for stuff. You can do everything in code and never use the editor, also, it's really your call.

 

For me it's mostly preference. But I also use a System loader which instantiates a prefab which contains my main singleton and has internal references stored to instantiate the other managers. So it keeps everything nicely packed and easy to manage. Also, I just don't like having singletons everywhere as it makes me feel icky!

It would also cause a problem if you decided to store a reference to 1 singleton in the Start function of another, before the 1 you're trying to store has been executed. Having 1 main singleton can allow you to notify scripts wanting to store references when nothing is null etc. Albeit, if you manage to get yourself in that situation you're doing a poor job of coding it's the only legitimate reason I can think of of what would make it better.

 

I agree. First of all, it is a matter of taste, but the taste ends as soon as it gets chaotic. That's why there need to be some conventions and that's it.

 

All of these Instantiate calls don't help with visualization, why use Unity if you aren't going to take advantage of the editor?

 

It's actually quite a transparent implementation. Easy for a programmer of any level to understand. Visualisation in Unity also leads to clutter. But like I said, it's mainly preference.

 

That's a cop out. Write custom inspectors, extend the editor, maximize productivity. I don't know if inefficiency is just a matter of preference... but I suspect preferred inefficiency is just as bad as the unintentional kind.

 

What's a cop out? Minimizing clutter in Unity?

 

Not utilizing features and calling it simplifying.

 

If reading and judging the content of a post on a public forum is considered intrusive then...I guess so?

When did I accuse you of not being helpful?

This would be an important disclosure when recommending it as a potential solution. As would a concise explanation of your reasoning and the advantages/drawbacks of this approach.

Again - not sure where this is coming from. Nothing in your solution enables or bars functionality in the Editor. Deriving from MonoBehaviour gives you an Inspector regardless of how you set up your singleton. I will agree that this is a nice feature, regardless of the wonkiness associated with MonoBehaviour singletons.

 

Instantiating objects, storing data in Scriptable objects and leaving the Editor view free of all clutter except what artists need to tweak is how we utilize the features of Unity. It is in no way a cop out. It is the correct way to use Unity in my opinion.

 

I think that's a big part of deriving from MonoBehaviour. Having a global object that is independent of the current scene is important to me, as well. So, I want a global, scene independent object with an inspector, sub objects, etc.

We're not talking only about mobile games, or flabby birds, but games that can't be so ridiculously simplified as to instantiate everything from Start().

As the number of unrelated, semi autonomous classes grows, the game becomes not one program but a collection of smaller programs. My inventory doesn't have any relation to enemy AI, so an explicit link shouldn't be made. If it is, it's convoluted. However, both are part of the Game and both need information about Player. I'm just trying to create an attractive structure that will make the code read well, will facilitate editor scripting, etc.

I think some of the usual coding concepts of insulation, encapsulation.... they need to be bent in order to serve my needs.

 

That is one way to use Unity. Another way is to code to allow an inexperienced member of the dev team build levels, customize elements, etc.

It's hard to accept another point of view, sometimes, but Unity's most powerful feature is that you can customize the editor to allow a 9 year old to build levels, create scenarios, etc. Instead of you building everything in code, you can have technically inferior, but still creative, people make content. For every programming wizard there are a hundred people who can make better games who can't write a lick of code.

 

Using instantiate instead of having something in the scene has nothing to do with making things more complicated, it can indeed be the exact opposite. If you have e.g. several scenes between which you switch and you always want to have the same fade in and fade out time, you could easily achieve that by using a prefab that is placed in every scene where you can modify the time it is supposed to take.
But this approach has a drawback, you are able to override the time in each scene by directly modifying the value. This is clearly not an optimal solution in all cases. Using a scriptable object instead means that you don't have a prefab that exists in each scene, but you have a file that exists once in the whole project. If you select the file, you can modify it like anything else in the inspector and there is just one place where you can modify it.

 

I have not once said we build everything in code. If we abstract most/all of the logic away from the editor window it leaves less clutter for artists/non-tech savvy people to open the scene and see what's going on. I also didn't disagree with writing custom inspectors etc. but we see those as the View(per MVC pattern) in which users modify how the logic performs, not the logic itself.

 

Oh, well sorry I'm not well versed in the lingo.

 

No, it's not, that's not what I asked for. My question, I have 2 scripts here, tell me which is better, what should I change, I even added "Please explain", and what do I get from you, a stupid hint?
If you don't understand the question, ask for clarification

Isn't that the whole point of these forums, of this site, to make getting answers to your specific questions faster and more convenient, and you'd rather I go look it up in a book, google search my questions when they're people here who can answer them?

If you can't be bothered to answer my questions properly, then I'd rather you not answer them at all. After all they aren't directed at you specifically anyway

You've been dogging my posts, acting rude and condescending
No, you don't get to hide behind a language barrier, your English is just fine

Btw, just cause you say "no offense", it doesn't make what you say any less offensive

 

Yeah, unless you're a pro... you're going to need help now and then and it's o.k. to ask. I've asked many questions in the past and that's how you get through newbie territory. For something general, like "explain how these work" or "which is better" is too opinion based for answers. And it's not like OP was saying "write my program for me it doesn't work hurry it up plz", either.

 

Well if forums are supposed to get you your answer faster... it fails miserably at that job. Just the wait time alone takes a while.

Personally I consider forums more a place to share information, help direct towards the best places to find answers, and to get answers that have very specific nuance that can't be easily found in a book/website/resource.

It's more about discussion, opinions, and general communication amongst peers in a field of interest that you otherwise can't get in person. If we were meeting up in a library IRL, and you asked a question that could be answered easily by grabbing a near by book... I'd probably tell you to grab said book.

 

And yet knowing how to use resources without the help of others is pretty much an advanced skill.

 

That it is... schools fail at teaching people how to use resources.

That's why I think it's more helpful to show newbs where to find answers. You know... teach a man to fish.

 

Guys, programming is hard.

True story. I was in Junior High with a book of K&R C. I gave up after a couple of weeks because I couldn't figure out how to friggin' COMPILE Hello, World!

I couldn't do Hello, World! >.>

Now we have the Internet. I won't forget that experience, how I almost gave up programming forever. People are at all sorts of stages of learning. Sometimes even *knowing* about resources is hard to figure out!

Personally, being able to get the joy of seeing code come alive is most important for learning. The key is when reading a person's post trying to figure out what response is too easy, just right, or too hard for the poster.

Eg: Someone has problem with syntax, the first thing we learn as programmers. I'll type out the code exactly so they can see exactly where the problem is. If I get the sense they can poke around syntax okay, then maybe I'll start linking some docs somewhere so they can get used to looking that stuff up. Pretty much anything harder than that becomes "interesting" for us and a discussion breaks out. =) Anything that seriously pisses people off is anathema to learning! (Goes for the noobs as well as the old hats.)

 

If it seems like they've tried to fix it, or tried looking it up, I'll bite. All depends.

 

@lordofduct "Well if forums are supposed to get you your answer faster... it fails miserably at that job. Just the wait time alone takes a while"

Personally I think forums are faster than looking for the right book, right site, right person, right whatever to answer the question

Sure you have wait times, but most of the time your questions are answered really fast, if they're easy or clear enough, it's only when you ask complex questions that you have to wait a little longer for the older members to answer

and you can still get the answer you're looking for even if it becomes a discussion

 

But you could learn so much more researching.

Of course you do need to know where to start. And forums are a great place to start. And if someone comes along linking to a reference, I'd suggest reading through it.

You can learn so much more that way.

One of the hardest things when teaching yourself is not knowing what questions to ask because you know nothing of the subject. Just reading through text on the subject will introduce you to concepts you never dreamt were things in the first place.

Don't get me wrong, I'm not disparaging forums. Just don't think of them as a question/answer machine. That's what "Unity Answers" is for (often if you just google your question a 'unity answers' page comes up. Just prefix your question with the word unity when you google it). Forums are more for community discussion. It's why it's called a forum.

http://en.wikipedia.org/wiki/Forum

Note the 'Roman' and 'Legal' versions of the word that predate the internet forum.