Managing projects beyond a single scene become infinitely more complex and quickly require you to consolidate your code into Manager classes. These classes help centralize your code and help enforce DRY (Don’t Repeat Yourself) as well as simplify the number of scripts you have running around.
Often you’ll want to call Manager classes from around the project in other scripts there is a variety of ways of doing that such as using Events and Delegates, making the Manager a Singleton which we’ll explore in another article, or in this case just making the manager class static.
Here’s an example of a very simple Audio Manager that’s simply a static class. As you can see you set the static instance named current to the this in Awake() (so it is set before anything else) and then anywhere in the program a script can call the Audio Manager to play the Audio Manager’s public methods like below.
In about two lines of code you can make a pretty easy to follow and centralized place to run your project’s functionality. When the player enters the collider assuming the voice over hasn’t played, call the PlayVoAudioClip method passing in the clip on the Audio Manager. However this way of handling a manager is a fairly brittle and can break if something goes wrong such as the Manager not initializing, being removed by accident, or it’s static instance being called before it can be set.
Next up we’ll talk about Singletons, these are similar to static manager classes but are little less brittle, more useful outside individual scenes, and a tad more complicated to set up. They are not without controversy but we’ll discuss that a later date, until next time. Happy coding.