I’m finishing a very simple match 3 game. In this game I made two different game modes. These game modes are choosen before the game starts, so during the game you can’t change them.
I had all the game rules in one class called gameManager, and the class had some if statements checking if a variable was set to the game mode one or two, the class would act differently depending on it. Now I have two separate classes for each game mode and both is inherited by one gameManager class.
But before this change the script that handles the logic of the game only needed one reference of the gamemanager, and would ask for the gamemanager do some things depending on that old variable.
Now I don’t really know how to do it with two different classes to handle, sure I could just have two different variables and have if statements checking it, but this won’t fix the problem that I wanted to resolve.
I know about inheritance, composition, generics, and more, but because I came back from some months without developing a game it’s hard to me to find a solution to this?
Should I change the whole logic? How do you guys handles this?
One handy way is to make a ScriptableObject class that contains all your mode-controlling items as variables.
Then you make as many instances as you have different game modes.
This is also a place to centralize logic such as bool IsBeginnerFriendly(); which can consider a bunch of different properties to return true / false, and then everywhere in your game that uses IsBeginnerFriendly() gets the same answer.
You can even go nuts with it and make a master “game mode” thing that contains other mode controlling objects, which you can composite together.
Here’s an example control preset for my Jetpack Kurt game, a mode called “Ultra Chill”:
The Usable For Tutorial: checkbox is an example of something different parts of my game use in different ways, to decide if it counts for scoring, to decide if it should show in the tutorial area, etc.
Some of the entries are just enums just because that’s how I originally did it… but be careful using enums in serialized fields:
Enums enums are bad in Unity3D if you intend them to be serialized:
It is much better to use ScriptableObjects for many enumerative uses. You can even define additional associated data with each one of them, and drag them into other parts of your game (scenes, prefabs, other ScriptableObjects) however you like. References remain rock solid even if you rename them, reorder them, reorganize them, etc. They are always connected via the meta file GUID.
Collections / groups of ScriptableObjects can also be loaded en-masse with calls such as Resources.LoadAll<T>();
Best of all, Unity already gives you a built-in filterable picker when you click on the little target dot to the right side of a field of any given type… bonus!