How to get a scene to ignore a reference

Unity Engine
1

At the moment I have my Screen Fader set up so when the screen fades to black, the player GameObject is deactivated, and when it un-fades, the player is re-activated. This is to stop the player from being moved whilst the screen fades in and out between a new scene. The player is in each scene, so it can be found …except in two of them… Those would be my Main Menu and Credits. However, with how I’ve set it up, those scenes can’t find the player, so gives me the ‘Object reference is not set to an instance of an object’ error.

What could I do to prevent the Screen Fader from trying to find the player in those two scenes?

This is the ScreenFader script I have:

using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using UnityEngine.UI;
using UnityEngine.SceneManagement;

public class ScreenFader : MonoBehaviour
{
    public Image blackScreen;
    public float fadeSpeed;
    public float waitForFade;
    public static bool black;
    public GameObject thePlayer
    {
        get
        {
            if (_thePlayer != null)
                return _thePlayer;

            _thePlayer = GameObject.Find("Player");
            return _thePlayer;
        }
    }

    private GameObject _thePlayer = null;
    private bool isFadeToBlack;
    private bool isFadeFromBlack;

    void Start()
    {
        thePlayer.SetActive(false);
        StartCoroutine("ScreenFade");
    }

    IEnumerator ScreenFade()
    {
        if (SceneManager.GetActiveScene() == SceneManager.GetSceneByName("level 1, room 1"))
        {
            isFadeToBlack = false;
        }
        else if (black)
        {
            yield return new WaitForSeconds(fadeSpeed);
            isFadeToBlack = true;
            yield return new WaitForSeconds(waitForFade);
            isFadeFromBlack = true;
            yield return new WaitForSeconds(0.1f);
            thePlayer.SetActive(true);
        }
        else
        {
            yield return new WaitForSeconds(fadeSpeed);
            isFadeToBlack = true;
            yield return new WaitForSeconds(waitForFade);
            isFadeFromBlack = true;
            yield return new WaitForSeconds(0.1f);
            thePlayer.SetActive(true);
        }
    }

    void Update()
    {
        if (isFadeToBlack)
        {
            blackScreen.color = new Color(blackScreen.color.r, blackScreen.color.g, blackScreen.color.b, Mathf.MoveTowards(blackScreen.color.a, 1f, fadeSpeed * Time.deltaTime));
            if (blackScreen.color.a == 1f)
            {
                isFadeToBlack = false;
            }
        }
        if (isFadeFromBlack)
        {
            blackScreen.color = new Color(blackScreen.color.r, blackScreen.color.g, blackScreen.color.b, Mathf.MoveTowards(blackScreen.color.a, 0f, fadeSpeed * Time.deltaTime));
            if (blackScreen.color.a == 0f)
            {
                isFadeFromBlack = false;
            }
        }
        if (black)
        {
            blackScreen.color = new Color(blackScreen.color.r, blackScreen.color.g, blackScreen.color.b);
            if (blackScreen.color.a == 1f)
            {
                black = false;
            }
        }
    }
}
2

Multiple solutions to that

Pretty dirty: Add a dummy object which can be found. This is similar to something called the null object pattern, which is sometimes used in programming. That is, the absence of an object is not “null”, but an object that can be addressed but doesn’t do anything useful.
In your case, that dummy object would take the place of such an empty implementation.
Downside: If you turn your player reference into a component, you’d need to provide a component which at least satisfies the interface you need.

Also dirty: Multiple implementations, for instance, via inheritance… I won’t spend any time getting into why this is not worth the effort…

Quick and halfway dirty (if you need to fix that ASAP):
Add a boolean to the script that indicates whether the player is required or not. If it is, access the player object, if it isn’t, let your code run into exceptions (indicates a bug), or log your own errors / throw your own exceptions.

Similar to the above (quick fix):
Always do the null-checl before you access it. This is probably the most appropriate, but it is certainly different to tell from code whether that scene’s screen fader should find a player.

Downside: You might forget the player object in a scene, or you may simply forget to name it correctly or to name it at all. Something might rename it. Or you change the structure or add multiple characters for a player…

Those are all valid but dirty and actually really bad solutions, they cannot satisfy your needs in the long run, if you asked me.

If I had to choose one of those above solutions, I’d take the latter but would exchange the Find call with an inspector field.

A different perspective…

If I had the choice to improve that now when it’s still not a complex setup, I’d completely decouple the screen fader from the player. After all, you’ve already ran into the situations in which the player does not exist in some of the scenes that need a screen fader.

In order to improve that for more flexibility and long term maintainance, you’ll need remove the responsibility from the screen fader.
Simplest approach is to introduce a component that controls that specific aspect of the application. Give that very specific component the references for all that stuff that needs to complete before controls of the player and other stuff will be enabled.
You can do that by event subscriptions or polling, no matter what you choose … the screen fader does it’s own thing it’s supposed to do, and it lets the “outer world” (i.e. the rest of your application) know when it’s done… that “outer world” then decides how things go on.
You’ll see how easy it’ll be to extend that, as opposed to the solution you’re currently stuck with. If another component needs to complete its work as well, you’ll have a conflict and need to re-do everything. Because that screen fader would set the character controllable, whereas another component would’ve needed the opposite.
In contrast, the controller would just wait for another component to be ready, and until then, keep the player controls disabled.

3

Thanks for the lengthy response. So, what you’re saying in the end, is to not have my Screen Fader control whether or not the player is active…? To just let it do its own thing, which is to control whether the screen fades to black or not? As for the component that should control specific aspects like that, I’m not sure how I’d do that. I’m not familiar with event subscriptions or polling. :-\

4

Exactly. It’s a small component which you can use to construct a more complex system. It shouldn’t even know in which context this is used.

The other component is just another script which references your fader, and (for now) the player, as an example.
Events are not complicated at all, just look them up. As an alternative, you can start with either Update or a coroutine and check a boolean value once per frame, which is the indicator for being ready.

5

I’ve only looked into Events briefly, so I still don’t quite understand them, how they work, or how to implement them properly, but I’ll continue to research.

I have thought of a possible alternative solution though. Would pausing the in-game timer work fine in this case? Like with the pause menu, the game is paused until resumed. Maybe whilst the screen fader is doing its thing, the game timer could be paused to prevent the player from being able to move, and then it’s un-paused once the screen fader has finished…? Unless pausing it prevents the screen fader from working too…

6

That’s another approach, but the fader needs to depend on the unscaled time if you do that.

They are usually very intuitive once you get a hang on them. It’s just a different way to communicate between objects.

I recommend to try out some examples, and experiment with it a little bit.

It certainly makes sense to have a direct comparison of

  1. direct dependency / your version (screen fader knows the exact instances it needs to operate on, in this case a gameobject)

  2. some sort of observer pattern (screen fader also knows the type of the objects it needs to notify, but usually limited to a small interface that the observers implement)

  3. events (screen fader raises an event, which indicates the fade in / fade out is complete), doesn’t need to know any of the specific type of the ones who subscribe to it

  4. polling (screen fader exposes properties that you can frequently check in Update or in a coroutine), so it doesn’t need to know anything either

Perhaps I can post some examples later.

7

Okay, I have a bit of an understanding of how they work and how to set them up, however in this case, I’m struggling to figure out how I’d incorporate it. :-\

I also tried adjusting the in-game timer and it’s not a viable option; everything pauses, which stops the fader from working.

8

I’d just disable input and movement of the character instead of the entire object. Worst case I’d disable all the object’s components, and re-enable when faded back in.

If I didn’t like those, I’d have another gameobject with DontDestroyOnLoad set, which just contains a reference to the player gameobject. When loaded in the new scene you just get the reference from there.

9

That’s what I did initially - disable input/movement of the character, but I could never get it to last long enough before the screen fader finished. Even with a coroutine and WaitForSeconds, the movement would be disabled, but it would re-enable before the fader finished. Just couldn’t get it right.

I’m still a bit confused with setting up references. I have done it countless times, but I’m still not 100% sure/confident on the best procedure to do it. I’d prefer doing it via code instead of having to keep dropping an object into the Inspector, especially if a new scene has all of its own objects and it can’t find the reference from the previous scene.

10

Okay, after a bit of procrastinating, as well as working on other projects, I’ve looked a bit more into Delegates and Events and have a bit more of an understanding of them and how they work. However, I’m having issues getting the player to reactivate. I’ve noticed that if I put ‘if’ statements in an invoked method, the event doesn’t get called. I take it they don’t work for invoked methods for an event…? Secondly, if I want the player deactivated and then reactivated, I will need to set up two separate delegates and events…? Lastly, I’m guessing you can’t invoke two separate methods within the same block of code, or in a coroutine…? I’m thinking that’s why I can’t get the player to reactivate…

PlayerController:

void OnEnable()
    {
        ScreenFader.deactivatePlayer += DisablePlayer;
        ScreenFader.reactivatePlayer += EnablePlayer;
    }

    void OnDisable()
    {
        ScreenFader.deactivatePlayer -= DisablePlayer;
        ScreenFader.reactivatePlayer -= EnablePlayer;
    }

void DisablePlayer()
    {
        gameObject.SetActive(false);
    }

    void EnablePlayer()
    {
        gameObject.SetActive(true);
    }

ScreenFader:

public delegate void PlayerDeactivated();
public static event PlayerDeactivated deactivatePlayer;
public delegate void PlayerReactivated();
public static event PlayerReactivated reactivatePlayer;

IEnumerator ScreenFade()
    {
        if (SceneManager.GetActiveScene() == SceneManager.GetSceneByName("level 1, room 1"))
        {
            isFadeToBlack = false;
        }
        else if (black)
        {
            Invoke("DeactivatePlayer", 0.5f);
            yield return new WaitForSeconds(fadeSpeed);
            isFadeToBlack = true;
            Invoke("ReactivatePlayer", 0.5f);
            yield return new WaitForSeconds(waitForFade);
            isFadeFromBlack = true;
        }
        else
        {
            Invoke("DeactivatePlayer", 0.5f);
            yield return new WaitForSeconds(fadeSpeed);
            isFadeToBlack = true;
            Invoke("ReactivatePlayer", 0.5f);
            print("reactivated player");
            yield return new WaitForSeconds(waitForFade);
            isFadeFromBlack = true;
        }
    }

    void DeactivatePlayer()
    {
        deactivatePlayer();
    }

    void ReactivatePlayer()
    {
        reactivatePlayer();
    }
11

Sorry for not posting back earlier. I tend to forget about threads when I say something like I’ll try to add example later.

You should debug the code and check what is being executed. Make sure the subscriptions are done, and that they’re done early enough.

Also, four things that immediately stand out are these:

  1. Your events are static.

I’d try to avoid that, unless you absolutely have to. Generally, statics are often misused.
There’s a lot to say about it, but that’d be a long post.

  1. I know you’re new to events. And this is probably just a first approach and not so important. However, the names of your events should be changed, because the names kind of suggests what should happen / what should be done when they’re raised, instead of telling any arbitrary subscriber what the instance itself is doing done, or what the instance itself has done.

  2. events should always be null-checked before invocation. Reason being, that there can be zero subscribers. Depending on the language version, you have more or less convenient ways to do that. There are also workarounds, but IMO it’s cleaner to just null-check, as that’s also the standard.

  3. I recommend to use a wait instruction in your coroutine rather than “Invoke” with a delay.

Unfortunately I don’t have the time to code up some examples for all the various approaches I mentioned in a previous post.

12

I did do some, and the event was/is being called when the player is deactivated, but not the reactivate event, which is why I asked earlier if multiple invokes can be used in the same block of code. It doesn’t appear as though the second one is.

Oh. All the tutorials I’ve watched seem to have the events static so they can be called/accessed in other scripts.

I don’t understand this one; I thought they could be called anything like a variable or function…?

I did do this initially, but the code changed to a darkened grey colour in Visual Studio and the tooltip says ‘Delegate invocation can be simplified’. And that’s just from using

if(deactivatePlayer != null)
13

Consider this:

OnEnable is only called when

  • component comes alive AND the component starts enabled
  • component was disabled, and it is re-enabled
  • component itself is enabled, but its GameObject was inactive and is now activated

If you think about it, this could be your bug:

Your player GameObject and the component come alive => subscribes to the events.
Screen fader raises the event which indicates the action is complete, player unsubscribes.

Now, you’re sitting there with an inactive player GameObject, and a player component that has no active subscription, since we unsubscribed when it was disabled.

Screen fader starts fading to black, but the player is not subscribed, because it always unsubscribes when it is disabled.

For a quick test, try to subscribe in the player components Awake/Start and unsubscribe in OnDestroy.

Unfortunately, many tutorials tend to use shortcuts and uncommon or even improper coding techniques for the sake of brevity and simplicity, because they focus on demonstrating the general concept of a specific feature.

Yes, they can have arbitrary names.
However, you usually don’t want to express what the subscribers should do. Instead, you want to express what the event sender is doing/has done.

So it’s just about the semantics.
I mean, check your event names.
Intuitively, you’ve chosen imperative names. They read like instructions, like “do that”, “process that”.
But most of the time, you want to notify subscribers about your own actions or state, “im starting”, “I’m done”.

Suppose you also want to play a sound when the screen fades out.

Do you subscribe to “DeactivePlayer”, or does your screen fader suddenly declare a second event “PlaySound”?
Both is not desired. It couples the screen fader semantically to things it should probably not know anything about.

Yes, as I stated earlier, it depends on which version of the language you’re compatible with.

The recommended way to raise an event used to be lengthy

var handler = SomethingHappened; // thread-safety measure in multi-threaded environments
// from now on, use the copy
if (handler != null)
{
    handler(...);
    // or
    handler.Invoke(...);
}

Since the introduction of the null-propagation operator, this overly lengthy event raising pattern can be shortened:

SomethingHappened?.Invoke(...);

Note the ? operator. You’re missing that one in your examples. :slight_smile:

1 Like
14

You were absolutely right! Having the player unsubscribe in OnDestroy allowed him to disable and then re-enable. Thank you. :smile: So, if the player GameObject is disabled at any point, it can’t access the events and they’re immediately disabled…?

If I’m honest, I don’t really see how it matters regarding their names, but I’m still a newbie to all of this. :stuck_out_tongue: You might have to show me some examples. All the ones I’ve seen have used arbitrary names and I know of no other way when it comes to variable and function names.

I’ve only come across the ‘?’ operator once. In this case, I don’t really know how to use it properly. I tried, but it gave me an error. :-\

15

No, they can always react to the events, unless you unsubscribe.

Before you moved that to OnDestroy, your player unsubscribed when it was disabled, so it could not receive the reactivation event.

Names don’t matter for the technical part. It works the same with all the names you that are valid

However, we already decoupled the fader from the other parts of your game, so that’s why you should also change the semantics of that event in order to make it absolutely self-contained.

Compare yours: “reactivePlayer” with “FadeOutCompleted”

The former does still semantically know something it doesn’t need to care about. It should not know what’s going to happen when it faded in or out (you know it, but the fader should not). It also does not express clearly when it’s going to be called, leaving subscribers in the dark of whether that’s what they’re looking for.

The latter eliminates both disadvantages: it doesn’t assume there’s something like a player, so it still keeps the fader self-contained (semantically) and doesn’t take it beyond its own problem domain. It also mentions when it is raised.

In addition to that, you can also parametrize events so that they can pass some useful data to the subscribers.

Perhaps you’re not working with the most recent API compatibility level. You can either check and fix that, or use the long version I posted earlier.
Like I mentioned, there’s also a trick which allows to omit the null-checking, which can be accomplished by always having at least one empty subscription. But that’s up to the conventions you’re using, or at least it’s up to your personal preference.

16

I’m still a bit confused with this. How exactly did it unsubscribe when it was disabled? Was that due to it being null…? I don’t think I put anything about what it should do if it is null, only when it’s not equal to null. :eyes:

So… is naming them correctly just for the purposes of making the code tidier…? For anyone else reading the code to see that the Screen Fader is its own thing and that it’s not referring to something it can’t possibly know about…?

I’m not sure how I’d do that. :face_with_spiral_eyes: