Game Managers

Starting Date: 08/02/2025

Ending Date: 26/02/2025

The blog is about creating game managers that will be awake in the game, meaning that every manager should be in the board map.

Objective

The goal of this blog is to create game managers that can handle unique events, each manager must be globally accessible for other scripts to use and must ensure that every manager is inside of the board map. The manager include:

Turn - Manages the turn based system to change the turn of the current player to the next player
Space - Manages the space that the player has landed and calls the suitable space method
Music - Manages the music to be played on a loop and changes the music if playing a minigame or engaging with combat
Sound - Manages the sound effects in the game by providing a public method
Minigame - Manages to choose a random minigame when the player lands on a minigame space
Each Minigame - Manages the behaviour of the minigame itself
Scene - Manages the transitioning of scenes
Data - Manages to store new data and either loads or deletes existing data
Combat - Manages the combat by calculating the damage of the

The only objective is to create a general manager that each manager, this will involve scripts to inherit the general manager that can be globally accessed by other scripts and restricts the manager to only appearing once in every scene that it's required

Techniques

Singleton Pattern

Singleton patterns are ensuring that a manager can only be instantiated once as an instance which can be globally accessible to any of the scripts in the project, the manager can also be in the object as well in order to still be globally accessibly as well.

I used singletons to have the singleton script which uses a generic which identifies the type of manager to ensure that there's only one type of manager in the scene, meaning that the when the manager script inherits the singleton it'll need to provide a generic of itself to become a singleton instance.

This becomes very useful because the generic in the singleton allows each manager to inherits the singleton as itself to ensure that there are no duplicates of the same manager in a scene, meaning that I can openly add more managers without editing the general manager, which leads the managers to operate the gameplay in the game.

Static Class Variable

Static classes as variables are unique behaviour to the class that makes the class globally accessible for any script to reference outside of their object, this means that the script doesn't need to reference the class inside of the game object or use public variables to edit the reference in a difference object and instead reference the instance of the class.

I used the static class inside of the singleton script which will create a instance of the generic type (the manager) to check if the generic manager exists, if it doesn't then it'll instantiate a new object including the manager's script component, otherwise if there is an existing manager then the singleton will destroy the manager.

Using static classes are very useful for the singleton because this ensures that the board map only provides one of every manager and can be globally accessed for other scripts to use the managers, this leads the game to operate with the mangers for players to play the game.

Challenges

Music Manager Instantiating Managers during Tutorial Scene

One Issue I had when providing music in the tutorial was that when using the music manager, it'll instantiate multiple managers, this is because the music manager required the minigame manager which then the minigame manager instantiated the turn based system, which cause a lot of null reference expectations.

This is one of biggest flaws that the singleton has due to creating managers from other managers can cause issue, which to this is a major issue because with errors, the player cannot input anything in the game, which leads them stuck on the tutorial.

The issue was solved with a alternative solution of excluding the music manager and edit the audio source by dragging a audio clip and then putting the audio source on loop to play the music on a loop, which leads the player able to understand the tutorial whilst having background music.

Forgot to inherit the Combat System

One mistake I made on the combat system is that I made the system a static class rather than inheriting the singleton as the combat system, this was because I wasn't sure on how I was going to implement the combat system and during the middle of the life cycle it was too late for me to change due to multiple scripts referencing the instance of the combat system.

Personally, this is a very minor issue because the combat system is still behaviour as a singleton where there's only one combat system in the board map and the component is globally accessible, the difference being that the system isn't inherited to the singleton, which leads me to not have strong concerns on the combat system not inheriting the singleton pattern.

Achieved

Managers Complete

The game managers are complete by using the singleton pattern to have every manager to have one instance in the scene and become globally accessible for other scripts to use.

This makes the game function for the player to play because without managers the player can't do anything at all, meaning that with managers they can operate the behaviour of the game, which leads the game to become playable for the player to enjoy.

Conclusion

Overall, I have learnt a lot of how to use singleton patterns along with how to not use them such as using them to provide managers a meaningful times in certain scenes such as only applying the scene manager and sound manager in the tutorial to avoid instantiating irrelevant managers in the scene, I have also learnt how static classes can be use for being globally accessible for other scripts to reference and make one instance of a static class.

As a programmer, I should be relying on singletons if I only need to make one class such as managers for other scripts in different objects to reference.

For scripts that need only one in the scene and requires to be globally accessible, I feel like singletons should be my solution to provide those classes. If not then an alternative is to make the class similar to the combat system where it'll create a instance of the specific script.

Return to Card Craze Combat