How to handle many event triggers without hard-coding checks for all of them into the game loop?

Question

Let's say I'm developing a horror game. For a jumpscare when entering room #1, the easiest way would be like this example:

void gameLoop() {
    if (playerEntersRoom1 && !playerHasBeenInRoom1) {
        playerHasBeenInRoom1 = true;
        jumpscareForRoom1();
    }
}

However this doesn't seem like a good solution to me, especially because the code would become quiet large when adding more and more of such events at some point. What's the way to go in a game engine like Unity?

Answer 1

I think using trigger objects with their own behaviour scripts, as suggested by @Zibelas, is probably the easiest way to manage this in unity. So, you would have a GameObject in your room1 that has a Collider marked as trigger (technically, you might be able to do this with a normal collider as well, as long as you are not using physics, but whatever). That object would also contain a script (lets call it JumpscareScript for the sake of argument) like this:

public class JumpscareScript : MonoBehaviour{
    bool playerHasBeenInRoom1;
    
    void Start(){
        playerHasBeenInRoom1 = false;
    }

    void OnTriggerEnter() {
        if (!playerHasBeenInRoom1) {
            playerHasBeenInRoom1 = true;
            jumpscareForRoom1();
        }
    }

    void jumpscareForRoom1(){
        // boo!
    }
}

That way, the rest of your code does not even need to know that this jumpscare stuff exists, it's all perfectly encapsulated in this one object. Of course, you could make the jumpscare class more generalizable by either having the jumpscare method be virtual, so you could override it in every object that has a jumpscare, or even have it be a delegate so each instace of the class has its own jumpscare without having to create lots of inheriting classes. But I'll leave those details to you, since I don't know your project or how you like to work.

The thing is, Unity is kind of "meant to" be used through this component-based way of organizing your code, where separate scripts are completely autonomous. So, a lot of the time, you wouldn't even have a main loop (of course, one does probably exist on the hidden C++ code of the engine) but you mostly are meant to use the "magical" functions in monobehaviours (Start, Update, OnCollisionEnter, etc) as the way to control the flow of the execution.

That is, of course, not to say it is wrong to circunvent all of this and make your own game loop, but it is definitely swimming against the tide.

Answer 2

Here is a short script which is surprisingly simple, yet surprisingly powerful:

using UnityEngine;
using UnityEngine.Events;

[RequireComponent(typeof(Collider))]
public class TriggerArea : MonoBehaviour
{
    public GameObject triggeredBy;
    public UnityEvent TriggerEnter;

    private void OnTriggerEnter(Collider other) {
        if (other.gameObject == triggeredBy) {
            TriggerEnter.Invoke();
        }
    }
}

What does this script do? When you add it to a game object with a collider which has "Is Trigger?" enabled (important!), you will see this in the inspector:

First you have a "Triggered By" field for a GameObject. Assign the object you want to detect, which is probably your Player.

The box below that is a collection of event actions. When you click the plus icon, then you can assign any method* of any components of any game object in your scene. And you can assign as many as you want. When those methods take parameters, then you can even state what values you want to pass to them.

Then, when the object you assigned enters the trigger-collider, all those methods will be called at once.

This allows you to do... basically anything you can think of. Activate objects, deactivate objects, play animations, play sounds, call your own methods of your own scripts... whatever. And you don't need to write a single additional line of code for that. You can do it all in the inspector. So it's a super designer-friendly script which enables level-designers without programming knowledge to create simple scripted events.

Want the event to trigger only once? Easy, then just assign GameObject.SetActive(false) of the trigger area itself, so the trigger area just disables itself when triggering.

Here is an example use-case of this script which plays an audio clip, activates a previously deactivated monster, causes a door to open and then disables itself so it does not trigger again:

Happy jumpscaring!

_{* OK, most methods. It is limited to methods which take either no parameters or a single parameter that is either an elementary type or some kind of Unity Object. But that covers quite a lot.}

Answer 3

I don't use unity, but you wouldn't put that kind of thing directly in your main game loop for the reasons you already cite: the game loop gets too large and too difficult to keep organized. The archetypal game loop example is usually given as:

while running == True: #or maybe while state == 'running'
    processInputs();   #process inputs and events
    updateWorld();     #calculate things and update world state
    renderView();      #actually draw things to the display

Both your processInputs() and updateWorld() functions would dispatch out to lengthy lists of things like processEventQueue(), checkPlayerLocation(), checkMobs(), checkForJumpScares(), etc.

For a real-time first-person player moving through a live map you would probably want to have a playerEntersRoom event, with data indicating which room was being entered (room 1), and which gets added to the event queue when the player crosses an arbitrary point on the map. (By this point you would have created your own map format, probably based on an existing format, and written a map editor to help create and edit your maps.) That event would get processed by processEventQueue() to initiate jumpScareForRoom1().

If your game is a turn-based graphical horror instead of real time then your processing gets a lot easier. You may not necessarily have an event queue. processInputs() would get you into the room with a simple keypress or mouse click, and updateWorld() would take that information and initiate jumpScareForRoom1().

So you're correct that you wouldn't want to put that kind of thing directly in your main game loop. Also, I believe that this question is more one of general game organization than for unity specifically.