#1. A Static Script To Hold Data Only
You can create a static script to hold data only. Don't assign it to a gameobject, since it's static we don't need this. And simply access your data like `ScriptName.Variable = data;` etc.

###Pros: 

 - No instance or singleton required.
 - You can access data from everywhere in your project.
 - No extra code to pass values between
   scenes.
 - All variables and data in a single database-like script makes it easy to handle them.

###Cons:

 - You will not be able to use a Coroutine inside static script.
 - You will probably end up with huge lines of variables in a single class if you don't organize well.
 - You can't assign fields/variables inside editor.

###An Example:

    public static class PlayerStats
    {
	    private static int kills, deaths, assists, points;

	    public static int Kills 
	    {
	    	get 
		    {
		    	return kills;
		    }
		    set 
		    {
		    	kills = value;
		    }
	    }

	    public static int Deaths 
	    {
		    get 
		    {
		    	return deaths;
		    }
		    set 
		    {
			    deaths = value;
		    }
	    }

	    public static int Assists 
	    {
		    get 
		    {
			    return assists;
		    }
		    set 
		    {
		    	assists = value;
		    }
	    }

	    public static int Points 
	    {
		    get 
		    {
		    	return points;
		    }
		    set 
		    {
			    points = value;
		    }
	    }
    }

----------

#2. Don't Destroy On Load
If you need your script to be assigned to a GameObject or derive from MonoBehavior (for c#), then you can add `DontDestroyOnLoad(gameObject);` line to your class.

###Pros: 

 - All Monobehaviour jobs (i.e. coroutines) can be done safely.
 - You can assign fields/variables inside editor.

###Cons:

 - You will probably need to adjust your scene depending on script, which is hard imho.
 - You will probably need to check which secene is loaded to determine what to do in Update or other general functions/methods. For example, if you are doing something with UI in Update(), then you need to check if correct scene is loaded to do the job. This causes loads of if-else or switch-case checks.


----------
#3. PlayerPrefs
You can implement this if you also want your data to be stored even if game gets closed.

###Pros: 

 - Easy to manage since Unity handles all background process.
 - You can pass data not only between scenes, but also between instances (game sessions).

###Cons:

 - Uses file system.
 - Data can easily be changed from prefs file.


----------
#4. Saving to a File
This is really try-hard for storing values between scenes. If you don't need encryption, I discourage you from this method. 

###Pros: 

 - You are in control of data saved as opposed to PlayerPrefs.
 - You can pass data not only between scenes, but also between instances (game sessions).
 - You can transfer the file (user-generated content concept relies on this).

###Cons:

 - Slow!
 - Uses file system. And probably will abuse it if not implemented well.
 - Possibilty of reading/loading conflicts caused by stream interruption
   while saving.
 - Data can easily be changed from file, unless you implement an encryption (Which will make your code even slower.)