should my static class be derived from UnityEngine.MonoBehaviour instead?

Question

I am working on creating an object to maintain state of the game, player data, etc. It is static (singleton lifecyle) through the life of my game.

I started down the path of a static class, with a static instance, like this:

public class PlayerState
{
    private static PlayerState DATA_INSTANCE = new PlayerState();
    public static PlayerState Instance
    {
        get { return DATA_INSTANCE;  }
    }
}

Then I started looking around and I see implementations that derive from UnityEngine.MonoBehaviour and implement the instance handling differently, adding the script to a game object and using DontDestroyOnLoad() to ensure it stays in memory.

So I am wondering: what is the correct idiomatic pattern in unity for a singleton type?

Do I really need all of the unity functionality of a UnityEngine.MonoBehaviour derived type (eg: Update()) for my static type?

I admit I am uneasy about static classes, in general. In this case, I am equally uneasy adding another type that potentially gets in the frame cycle when its not needed (I mean that unity will call the methods like Update() for every cycle).

Thnx Matt

Answer 1

Not every class in a Unity project must necessarily inherit from MonoBehaviour. If there is no good reason to attach an instance of your class to a specific GameObject and you don't have a reason why you would need it to implement any Unity event, then there is no reason why you need to make it one.

In fact putting the whole game state into a static class (implementing the singleton pattern or not) is my favorite way to share data between scenes.