Keeping persistent information is trivial, that’s just a GameManager of some type set to live through scene changes.
Why not start by making it all in one scene, roughing it out, iterating on it, and if it gets unwieldly, chop it all apart. It’s super-easy to have multiple scenes and use extra GameObjects (sort of as folders) to organize stuff.
ALSO, please consider using proper industrial-grade source control in order to guard and protect your hard-earned work.
Personally I use git (completely outside of Unity) because it is free and there are tons of tutorials out there to help you set it up as well as free places to host your repo (BitBucket, Github, Gitlab, etc.).
As far as configuring Unity to play nice with git, keep this in mind:
Here’s how I use git in one of my games, Jetpack Kurt:
Using fine-grained source control as you work to refine your engineering:
Share/Sharing source code between projects:
Setting up an appropriate .gitignore file for Unity3D:
Generally setting Unity up (includes above .gitignore concepts):
It is only simple economics that you must expend as much effort into backing it up as you feel the work is worth in the first place.
“Use source control or you will be really sad sooner or later.” - StarManta on the Unity3D forum boards
For a simple singleton construct, I always reach for this no-fuss no-muss 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
}