What about the old school singleton pattern?

[Paulonium]

Ist there some unity specific disadvantages if I use just a regular “handmade” singleton instead?

Here is my example

1 My score container:

public class PlayerScoreSingleton
{
    private PlayerScoreSingleton() { }

    public int points = 0;
    private static PlayerScoreSingleton instance = null;

    public static PlayerScoreSingleton Instance {
        get {
            if (instance == null) {
                instance = new PlayerScoreSingleton();
            }
            return instance;
        }
    }
}

2 here how I use it:

public class GameController : MonoBehaviour
{
    [Range(0, 10)][SerializeField] float gameSpeed = 1f;
    [SerializeField] int blockPoints = 10;
    [SerializeField] TextMeshProUGUI scoreUI;

    private PlayerScoreSingleton scorePointsContainer;

    public void Start() {
        this.scorePointsContainer = PlayerScoreSingleton.Instance;
        this.updateGui();
    }

    public void addToScore()  {
        this.scorePointsContainer.points += this.blockPoints;
        this.updateGui();
    }

    private void updateGui()  {
        this.scoreUI.text = this.scorePointsContainer.points.ToString();
    } 
}

Are there some problems with that approach? Am I doing something against some not so obvious Unity mechanics or is it a legit solution?

[Nina]

Hi Paulonium,

Welcome to our community!

That’s an interesting question. I think the big “disadvantage” of the “singleton” with the static field is that we cannot know if the PlayerScoreSingleton object is active in the scene. We need an active object.

Rick’s alternative approach looks only for active objects in the scene but it is less performance than yours because of the “expensive” FindObjectsOfType method call. In our little game, we won’t notice any difference in the performance, though, so this is not an issue for us.

Both approaches are valid. Decide yourself which one you want to use.

---

See also:

• Forum User Guides : How to mark a topic as solved

[Paulonium]

Hi Nina,
yeah, I see what you mean, but I instantiate my ScoreContainer singleton when I need it. Then it just stays in memory outside my scene and I can use it in any scene. Thank for the answer

[Nina]

Oops, you are right. For some reason, I thought your PlayerScoreSingleton inherited from MonoBehaviour and was located in the scene. Since that’s not the case, forget what I wrote. (There is also a Unity “singleton” version with a static instance variable.)

I, personally, would use your approach if this was my game because all the PlayerScoreSingleton object does is holding the score value. It does not have anything to do with Unity, so a “normal” C# object is sufficient.

However, if you wanted to make this object interact with things in the scene, it would not be possible directly. That’s not a disadvantage per se, especially not if you know OOP and if you are familiar with programming.