1. Fundaments of Game Design
Using Managers
Richard Gesick

2. Objectives
Concept of managers
Polymorphism with managers
Player Prefs

3. Managers Typical managers are game managers and enemy managers.
Be careful not to make too many managers, it gets confusing and you duplicate processes.
Using an enemy manager as the example. By using the manager, we have once point of control and it makes it easy to use inheritance and polymorphism.

4. The classes
abstract class enemy has abstract move and attack methods. Doesn’t inherit from monobehavior.
Subclasses Orc, Troll and Centaur inherit from enemy and each overrides the attack and move methods.
Prefabs of the 3 subclasses are made and the scripts assigned.
Enemy class is just in the script folder of assets without being assigned to a game object

5. The enemy manager
The enemy manager will have start or awake. In that method it will call a spawn method to create the enemy.
Spawn instantiates the enemy subclass objects and adds them to a list of enemies.
elist.Add( (Orc) Instantiate(eObj[0], position, rotation); //eObj is an array holding the prefabs

6. The polymorphic move and attack
foreach (Enemy e in eList) { if(e!=null) e.Move(playerPos); e.Attack(playerPos); }

7. PlayerPrefs
Allow storage of small amounts of info (strings, ints, floats) (about 1 MB total)
Save data using:
PlayerPrefs.SetFloat(“keyname”,variable name);
Load data into game using:
int pKills=PlayerPrefs.GetInt(“playerKills”);

8. PlayerPrefs.Save() From unity documentation:
Writes all modified preferences to disk.
By default Unity writes preferences to disk during OnApplicationQuit(). In cases when the game crashes or otherwise prematurely exits, you might want to write the PlayerPrefs at sensible 'checkpoints' in your game. This function will write to disk potentially causing a small hiccup, therefore it is not recommended to call during actual gameplay. Note: There is no need to call this function manually inside OnApplicationQuit().
PlayerPrefs.Save();