Just like this, to be called from within Transition():
// Note: We cannot cache the player here because the cached reference
// would be stale all the time. Actually we might want to have the
// player auto-disable itself in Awake() and wait to be called into
// action when a scene has finished loading... We would still have to
// disable the player instance in the originating scene of a
// transition...
private void DisablePlayerControl()
{
GameObject player = GameObject.FindWithTag("Player");
// Debug.Log($"freeze player({player.GetInstanceID()})");
player.GetComponent<PlayerController>().enabled = false;
}
private void EnablePlayerControl()
{
GameObject player = GameObject.FindWithTag("Player");
// Debug.Log($"thaw player({player.GetInstanceID()})");
player.GetComponent<PlayerController>().enabled = true;
}
(Disabling the collider on the transition entrance portal is something I added very early (when we were adding the portals in the first place), and I would think that’s still a very valid thing to do…)
One possible optimization that came to mind is having Disable() return the player and have a PlayerController parameter in Enable(), but one single Find...() doesn’t make that much of a difference in performance for the whole scene-loading process. And one might find other uses for this…
Actually, the best way would be to turn them into static events, so the transition could just call out “any player present, please freeze”, and at the end of the transition “any player, you’re good to go, again”. And the CinematicControlRemover should be refactored to do just the same.
I guess in the later course parts something like that will be added, eventually. With having an inventory UI screen, or doing some conversation with an NPC, or shopping, one would want to move the interaction focus to those screens (and away from the player), and also do some similar pausing for the enemies as well…