Unity - Game modes as state machine?

This question is quite open and opinion-based. However there are few "common" approaches, one of the most important is to make game "data-driven".

What? Why? How?

Imagine you are having space shooter, where you have your ship flying around and picking guns. Each time you add new gun, you will have to code its damage, kind of projectiles and how many of them you shoot, their color, in what pattern they spawn, speed, size, ...

Everytime you would want to add a new gun, you would need to enter the code and change it there, compile, ... Lot of work.

Instead people thought, "why don't we create simple class that holds all the parameters? We will make it editable from Unity, instatiate it in the project and we won't need to code that much."

This is when Unity brought Scriptable objects.

Scriptable objects

A ScriptableObject is a data container that you can use to save large amounts of data, independent of class instances. One of the main use cases for ScriptableObjects is to reduce your Project’s memory usage by avoiding copies of values.

The idea is to create scriptable object for your mode and set up multiple kinds of modifiers that will the mode use. Folder structure might look like:

> ScriptableObjects
| |--> Modes
|    |-> NormalSO (instance)
|    |-> HardWithLotOfExpSO (instance)
|    |-> EasyWithLowerExpSO (instance)
> Script
  |--> ScriptableObjects
     |-> ModeSO

ScriptableObject is class that doesn't really have the logic inside, just creates "structure" for keeping data. Example of such class would be:

public class ModeSO : ScriptableObject
{
    public string modeName;

    public float scoreMultiplier;
    public int numberOfEnemiesMaxAlive;
    public int numberOfEnemiesTotal;

    public Vector3[] spawnPoints;
}

In the Unity itself you would then create instance of such objects. And what about interaction with other classes? Well, they would just work as:

• Game manager hold single instance of active mode
• Class that would be handling score (e.g. player / scoreboard) or Enemy would ask GameManager what is current multiplier for score
• WorldSpawner would ask GameManager how many enemies should he spawn, where, and when to spawn next ones
• At the beginning of the game you would be able to select difficulty by its name

Example of one of the classes (Scoreboard):

public class ScoreBoard: MonoBehavior
{
    GameManager manager;

    private float totalScore;

    OnEnemyDestroyed(float scoreForEnemy)
    {
        totalScore += scoreForEnemy * (manager?.activeMode?.modifier ?? 1);
    }
}

And the best is, whenever you will change some data, you will just modify the existing instance in the Unity. No need to go into code. No need to recompile whole game.

I think having different scenes for each game mode, especially if the modes are very similar save for a few settings, is unnecessary. I'd have to see more of your design to know how your game logic is being handled (is it all managed in one GameManager script? Or are there multiple scripts in the scene that take values from this manager script to handle game mechanics?)

One way I've handled different game modes before is to use a public int value in the GameManager that represents the different modes (i.e 1 = easy, 2 = medium, 3 = hard). I would then use a switch statement in any scripts whose behavior/values depend on this mode and reference that public int to determine game settings.

Game Manager:

public class GameManager: MonoBehavior
{
    public int gameMode = 0; //set to 1,2, or 3 by UI
    [...] //rest of game manager code
}

Example Behavior Script:

public class EnemySpawn: MonoBehavior
{
    public GameObject enemy;
    GameManager gm;
    
    private float spawnRate;
    Start()
    {
        switch(gm.gameMode)
        {
            case 1:
                 spawnRate = 15f;
                 break;
            case 2:
                 spawnRate = 10f;
                 break;
            case 3:
                 spawnRate = 5f;
                 break;
            default:
                 spawnRate = 10000f;
                 Debug.log("invalid mode");
                 break;
         }
    }
    Awake()
    {
        InvokeRepeating("SpawnEnemy", spawnRate, 0f);
    }
    [...] //rest of EnemySpawn code, including a SpawnEnemy() function.

}            

This example would reference the GameManager's gameMode int to determine what speed to spawn enemies at, assuming there is a SpawnEnemy() function somewhere down in the code. I can't verify if this example is syntactically correct, but it's just to show one way to handle game modes.