architecture

Aims:

To have ints / floats / strings manage saving & loading their own state.
To have ints / floats / strings be reference-able in the inspector
To separate data (e.g. currency, health, score) from components (displays, calculators, shopfronts, managers).

Let’s remind ourselves of the problem. You’re storing “coins” as an int and you stick it on a GameManager singleton:


public class GameManager{
public static GameManager Instance;
public int coins;
}

public class GameManager{

public static GameManager Instance;

public int coins;

}

All the other things that need to know how many coins there are will reference it with GameManager.Instance.coins .

Ok, but now the GameManager also has to persist that data so it starts to look like this:


public class GameManager{
public static GameManager Instance;
public int coins;

void Awake(){
Load();
}

void Load(){
// load from disk / playerprefs / cloud
}

void Save(){
// save to disk / playerprefs / cloud
}

}

public class GameManager{

public static GameManager Instance;

public int coins;

void Awake(){

Load();

}

void Load(){

// load from disk / playerprefs / cloud

}

void Save(){

// save to disk / playerprefs / cloud

}

Suddenly our GameManager is not only managing the game but also looking after data. Also, now your Shop UI or coin display can’t work on its own because it needs the GameManager to know how many coins you have. Things have become coupled (one cannot work without the other). If we made a scene just for the shop, our team would have to remember to drag the GameManager into it as well. That might not sound like a big deal but it quickly gets out of control as more managers are introduced.

Like in real life, managers quickly become a dump for all the leftover tasks.

Since we are striving for clean, decoupled, single-responsibility code – we can do better than this! Let’s start by creating a scriptableobject that just stores an int:


[CreateAssetMenu(fileName = "newInt", menuName = "Variable/Int")]
public class IntVar:ScriptableObject{
 public int Value;
}

[CreateAssetMenu(fileName = "newInt", menuName = "Variable/Int")]

public class IntVar:ScriptableObject{

public int Value;

}

This step on its own already gets rid of the need for a manager & singleton. Once you create an instance of this class through the right click menu, some shop UI can reference and use it directly:


public class ShopUI: MonoBehaviour{
public IntVar Coins;
public Text CoinDisplay;
void UpdateUI(){
CoinDisplay.text = Coins.Value.ToString();
}
}

public class ShopUI: MonoBehaviour{

public IntVar Coins;

public Text CoinDisplay;

void UpdateUI(){

CoinDisplay.text = Coins.Value.ToString();

}

Let’s go a step further and get our ints to look after their own state. There are many options to storing data, but for demo, let’s store this int in Playerprefs.


[CreateAssetMenu(fileName = "newInt", menuName = "Variable/Int")]
public class IntVar:ScriptableObject{
 public int Value{
 get{return PlayerPrefs.GetInt(name, 0);}
 set{PlayerPrefs.SetInt(value);}
 };
}

[CreateAssetMenu(fileName = "newInt", menuName = "Variable/Int")]

public class IntVar:ScriptableObject{

public int Value{

get{return PlayerPrefs.GetInt(name, 0);}

set{PlayerPrefs.SetInt(value);}

};

}

Alright, now the int’s are managing their own persistence. How about an event notifying listeners of a value change?


[CreateAssetMenu(fileName = "newInt", menuName = "Variable/Int")]
public class IntVar:ScriptableObject{
 public Action OnChange = delegate {};
 public int Value{
 get{return PlayerPrefs.GetInt(name, 0);}
 set{
 PlayerPrefs.SetInt(value);
 OnChange();
 }
 };
}

[CreateAssetMenu(fileName = "newInt", menuName = "Variable/Int")]

public class IntVar:ScriptableObject{

public Action OnChange = delegate {};

public int Value{

get{return PlayerPrefs.GetInt(name, 0);}

set{

PlayerPrefs.SetInt(value);

OnChange();

}

};

}

Registering a callback to OnChange lets us write a counter as small as this:


public class IntDisplay: MonoBehaviour{
public IntVar TargetInt;
public Text DisplayText;

void OnEnable(){
TargetInt.OnChange += UpdateText;
}

void OnDisable(){
TargetInt.OnChange -= UpdateText;
}

void UpdateText(){
DisplayText.text = TargetInt.Value.ToString();
}
}

public class IntDisplay: MonoBehaviour{

public IntVar TargetInt;

public Text DisplayText;

void OnEnable(){

TargetInt.OnChange += UpdateText;

}

void OnDisable(){

TargetInt.OnChange -= UpdateText;

}

void UpdateText(){

DisplayText.text = TargetInt.Value.ToString();

}

Now let’s cache the value from Playerprefs so we’re not going in and out all the time:


[CreateAssetMenu(fileName = "newInt", menuName = "Variable/Int")]
public class IntVar:ScriptableObject{
 public Action OnChange = delegate {};
 int cachedValue;
 public int Value{
 get{return cachedValue;}
 set{
 if(cachedValue == value) return;
 cachedValue = value;
 PlayerPrefs.SetInt(cachedValue);
 OnChange();
 }
 };

 void OnEnable(){
 cachedValue = PlayerPrefs.GetInt(name);
}
}

[CreateAssetMenu(fileName = "newInt", menuName = "Variable/Int")]

public class IntVar:ScriptableObject{

public Action OnChange = delegate {};

int cachedValue;

public int Value{

get{return cachedValue;}

set{

if(cachedValue == value) return;

cachedValue = value;

PlayerPrefs.SetInt(cachedValue);

OnChange();

}

};

void OnEnable(){

cachedValue = PlayerPrefs.GetInt(name);

}

And maybe a few Odin buttons for resetting the stored value and testing:


[CreateAssetMenu(fileName = "newInt", menuName = "Variable/Int")]
public class IntVar:ScriptableObject{
 public Action OnChange = delegate {};
 int cachedValue;
 public int Value{
 get{return cachedValue;}
 set{
 if(cachedValue == value) return;
 cachedValue = value;
 PlayerPrefs.SetInt(name, cachedValue);
 OnChange();
 }
 };

 void OnEnable(){
 cachedValue = PlayerPrefs.GetInt(name);
 }

 [Button("Reset")]
 void ResetValue(){
 Value = 0;
 }

 [Button("Increment")]
 void Increment(){
 Value++;
 }
}

[CreateAssetMenu(fileName = "newInt", menuName = "Variable/Int")]

public class IntVar:ScriptableObject{

public Action OnChange = delegate {};

int cachedValue;

public int Value{

get{return cachedValue;}

set{

if(cachedValue == value) return;

cachedValue = value;

PlayerPrefs.SetInt(name, cachedValue);

OnChange();

}

};

void OnEnable(){

cachedValue = PlayerPrefs.GetInt(name);

}

[Button("Reset")]

void ResetValue(){

Value = 0;

}

[Button("Increment")]

void Increment(){

Value++;

}

And there we have it. From here, you can add other features like saving to the cloud instead of PlayerPrefs, string formatting, and so on. Most importantly – data and behaviour is separate and scenes are easier to reason about and test.

Happy scripting!

In an ideal dev environment, we want to be able to drag any object into an empty scene, press play, and be able to test it by itself. Characters, UI, everything.

Turning Monobehaviours into singletons makes that dream unachievable. Countless times playing an empty scene with a simple character spits out a null reference because there’s no Gamecontroller.Instance.StartingHealth.

Inspired by Richard Fine’s GDC talk, a great way around this is to keep all this stuff on a scriptable object.

Here’s a simple GameSettings script, which inherits from our magic ScriptableSingleton class:


using UnityEngine;

[CreateAssetMenu(menuName = "Game Settings")]
public class GameSettings : ScriptableSingleton<GameSettings>
{
    public int StartingHealth;
    
    public Color PrimaryColor;
    public Color HighlightColor;

    public float HeaderFontSize;
    public float BodyFontSize;

    public bool IsDebugMode;
}

using UnityEngine;

[CreateAssetMenu(menuName = "Game Settings")]

public class GameSettings : ScriptableSingleton<GameSettings>

{

public int StartingHealth;

public Color PrimaryColor;

public Color HighlightColor;

public float HeaderFontSize;

public float BodyFontSize;

public bool IsDebugMode;

}

On it, we keep normal, basic information we need across our game.

The magic is in the base class:


using UnityEngine;

public abstract class ScriptableSingleton<T> : ScriptableObject where T: ScriptableObject {

	static T _instance;
	public static T Instance{
		get{
			if (!_instance)
				_instance = Resources.LoadAll<T>("").First();
			if (!_instance)
				Debug.LogError(typeof(T) + " singleton hasn't been created yet. ");
			return _instance;
		}
	}
}

using UnityEngine;

public abstract class ScriptableSingleton<T> : ScriptableObject where T: ScriptableObject {

static T _instance;

public static T Instance{

get{

if (!_instance)

_instance = Resources.LoadAll<T>("").First();

if (!_instance)

Debug.LogError(typeof(T) + " singleton hasn't been created yet. ");

return _instance;

}

Here, we are inheriting from ScriptableObject instead of Monobehaviour so we can create a .asset file from the right-click menu. The where T: ScriptableObject is something we must have when creating a generic class. Info here. In this case, we’re just saying that children inheriting from this class are also ScriptableObjects but this could be anything else e.g. implements an interface.

The getter for the instance variable is not much different to classic Monobehaviour singletons. On line 10, if there’s no instance already, instead of instantiating one, we load an object of type <T> from the Resources folder in our Unity project and on line 12, we’re logging an error to remind ourselves to create one because we still couldn’t find one.

As long as we’ve created a GameSettings.asset in the Resources folder, we can call GameSettings.Instance.IsDebugMode even from an empty scene, and values changed during play mode are saved.

ScriptableObject architecture series part 2 – fancy variables

ScriptableObject architecture series – ScriptableSingletons