Power-Ups and Singletons - Pro Unity Game Development with C# - page 134

 Line 38. Here the power-up is hidden (or removed) from the scene using the
SetActive function. SetActive does not technically delete or remove an object
from the scene, because any deactivated object can always be reactivated.
Objects can be deleted permanently with the function DestroyImmediate .
However, for performance reasons, I've avoided using that here. Instead, I'd
recommend getting into the habit of caching and batching your objects. That is,
create objects altogether in one large batch (such as a Scene Start), and then
just hide them when they're not supposed to be in the scene, instead of creating
and destroying objects as and when required during gameplay.
 Lines 41-44. These lines retrieve a PlayerController component from the
colliding Player object, to increase the collected cash. The PlayerController
class hasn't been created yet—it'll be made in the next chapter. But that's not
a critical issue, because for now you can comment out these lines until we
develop the class. The key issue to see is the OnTriggerEnter function will
increment the player's collected cash.
Introducing the GameManager
The Powerup_Dollar class implements the event OnTriggerEnter to respond to player collisions. This
program structure and functionality works well insofar as it goes, but it really doesn't go far enough.
While it's useful for the Powerup_Dollar class to respond to collision events as it does, there may
potentially be other classes that'll want to respond to and handle power-up collection. Perhaps,
right now, we cannot conceive clearly of what those classes might be and how they might work
exactly, but it'd be a good idea to structure our code now so that in the future, any other class has,
at least, the potential and opportunity to respond directly to power-up collection events, should
they need to. Thankfully, we already have the beginnings of a solution to this problem through the
NotificationsManager class, created in the previous chapter. This class allows an event-receiver,
such as Powerup_Dollar , to post event notifications to the NotificationsManager, which then relays
all notifications to all registered listener objects by way of function calls.
However, an important consideration arises here. Our CMOD project doesn't yet have any valid
instance of the NotificationsManager attached to an object in the scene. This means our project has
no valid instance of NotificationsManager to receive or broadcast events, even though the script file
is in our Project panel. I've deliberately put off discussing NotificationsManager instantiation until
now. This is because the NotificationsManager is a managerial, overarching class that applies not to
any one particular instance of an object, but to all objects generally throughout the game. It needs
to receive and post event notifications between potentially all objects in scene and a game. This
general and overarching quality is also likely to be shared by a range of other managerial classes.
One particular class is the GameManager .
The GameManger is a special class in the sense that it's the highest level class in a game. If we want
to restart or quit the game, then we'll need a GameManager. If we want to save or load game states,
we'll need a GameManager. And if we want an instance of NotificationsManager for handling events
throughout a game, then it'll be a member instance of GameManager. In short, any high-level,
game-wide functionality that we'll need should be implemented in GameManager. It's effectively
the “boss” of our game's logic. Given this, then, we'll now start to implement GameManager, and in
doing this we'll be able to handle game-wide events with NotificationsManager. So let's get started
by creating a new C# script file GameManager.cs .