Now we have some places in the level flow we know we want to skip to, let's look at one of the ways this kind of system would be set up. One way to simply implement this system would be to have a single Game Token that enables any and all debug triggers that we place in the level. This allows us to enable the debug functionality via any condition we choose. When this token is true, we'll enable ProximityTriggers at every debug location (which can be jumped to either by a spawnpoint or a tag). When the player enters one of these triggers, we know that the debug functionality has been enabled. As a result, we can then trigger the various skipping logics required by each location. As we've already set up all of our gameplay systems with modularity in mind, it should be straightforward for us to retro-fit this concept into our level flow without unnecessary headaches. Let's dive in to setting up these debug triggers and their sister Game Token!
The first thing we need to do is place our ProximityTriggers. These should encapsulate the spawnpoint and/or tag locations that are placed around that debug point. As soon as either method is used to teleport the player, the trigger will instantly output. These should also have Enabled set to false by default on their entity parameters. We want to make sure that if the player progresses through the level as part of a regular playthrough, they don't accidentally trigger off our debug logic.
We do, however, want to make sure that the triggers are active when our debug functionality is enabled. The easiest and most common use case for this will be testing our content in the editor. In this case, what we want is for every trigger to be enabled for a short amount of time when game mode is entered. That way, jumping to a debug location and then pressing Ctrl + G to drop in to game will mean that regardless of which location we're at, the level progression will skip accordingly. Let's start implementing this by getting the state of the debug Game Token to follow those rules.
An example of this is shown in the following screenshot, where Time:Delay is used to allow the debug mode to be active for 2 seconds when entering the game and then it is disabled:
Tip
This is a good use case for modifying the InGame flag on the Game:Start node. Although it's unlikely that players would be able to make it to our debug triggers in the level before the timeout, unticking InGame (as shown in the previous screenshot) means that this will never fire at all when in pure game mode, preventing false positives.
We need to enable the ProximityTriggers via our Game Token. This is shown in the following screenshot:
From here, we are able to hook up any relevant logic that advances the level flow! In the previous example, I have a debug location placed at the beach where the encampment assault occurs. This allows testing the content further on from this without having to play the opening boat attack sequence. In this example, useful events that could be placed here include updating the active mission objective and forcibly killing all the AI within the encampment to simulate the successful attack. However, what if the accompanying NPCs from the boat sequence are integral to the next objective? We need to make sure they're with the player and not at the start of the level. Let's look at how we can achieve this.