I would not even put it in a scene. I would make it a pure Unity singleton (see below) that comes into being either by simply accessing it, or else by calling an InitGame method.
Why not make a special UI camera in the scene with UI? Use layers to keep it from seeing everything else, and vice-versa.
This is always a bespoke solution (totally dependent on your game) and really only incidentally affects the additive scene loading choice.
Here are my notes on standing up this sort of a persistent system… start small and build up on it, testing EXTENSIVELY at each step of the way:
Load/Save steps:
Don’t use the binary formatter/serializer: it is insecure, it cannot be made secure, and it makes debugging very difficult, plus it actually will NOT prevent people from modifying your save data on their computers.
When loading, you can never re-create a MonoBehaviour or ScriptableObject instance directly from JSON. The reason is they are hybrid C# and native engine objects, and when the JSON package calls new to make one, it cannot make the native engine portion of the object.
Instead you must first create the MonoBehaviour using AddComponent() on a GameObject instance, or use ScriptableObject.CreateInstance() to make your SO, then use the appropriate JSON “populate object” call to fill in its public fields.
ULTRA-simple static solution to a GameManager:
OR for a more-complex “lives as a MonoBehaviour” solution…
Simple Singleton (UnitySingleton):
Some super-simple Singleton examples to take and modify:
Simple Unity3D Singleton (no predefined data):
Unity3D Singleton with a Prefab (or a ScriptableObject) used for predefined data:
These are pure-code solutions, do not put anything into any scene, just access it via .Instance!
If it is a GameManager, when the game is over, make a function in that singleton that Destroys itself so the next time you access it you get a fresh one, something like:
public void DestroyThyself()
{
Destroy(gameObject);
Instance = null; // because destroy doesn't happen until end of frame
}