Now that we have got a better understanding of scripting level events, we should be able to script up any level ideas our imagination throws at us. However, if our level turns into a 30-minute epic and we need to tweak the timing of a sequence 25 minutes in, testing can soon become a huge headache. Having already covered logic modularity in our progress so far, let's take a look at the ways in which we can exploit that to make testing a simple, manageable process. We will cover the following topics:
- Skipping through the level flow
- Advancing the states of other level elements
- Debugging pure game issues
Before we get to the actual events and entity progressions that make up our level design, first let's look at how we want to trigger these skip events so that they are quick and accessible for us as developers, but immune to people playing the level via the regular flow. To achieve this, we'll set up some triggers at various locations in the world that fire off some skipping logic when used. These locations are generally in "safe" areas in the world, so as to allow us to test the content that follows. For example, the transition space between action bubbles before entering a large combat arena. However, to use these, we need to be able to get to these locations precisely and easily. There are a few ways for us to quickly jump around the world in CRYENGINE. Let's take a look at how these can be set up.
Spawnpoint entities are not just used as spawn locations for multiplayer game modes—they can also be used to move through the level in a single player development environment too. By simply pressing F2, you can jump sequentially to every spawnpoint entity in the level. These are processed alphanumerically, that is, the order is determined by the entity names of the spawnpoints. This will work in pure game mode too, allowing us to skip content even when running from the launcher. Spawnpoints can be found at RollupBar | Objects Tab | Entity | Others | Spawnpoint, and any number of them can be placed in the level.
Note
Remember that spawnpoints are also how the game determines where to start the player when they load into the level in a single player session. If you decide to place extra spawnpoints to facilitate skipping content, make sure that only one has the InitialSpawn flag ticked in its entity parameters. The player will be placed here when the level is finished loading.
Another system that offers a lot of versatility within Sandbox is the tags system. The premise is straightforward: press Ctrl and a function key (for example, F4), and a tag position is saved. Press Shift and the same function key, and the player is moved to that tag position. This works in both edit mode and game mode, which means the system can also be used to preserve exact positions for screenshots or quick locations to jump around whilst editing the level. The reliance on function keys does mean the quantity of tags is limited to your number of keys. However, if you have relatively few skip locations within the level, then the tags system can be invaluable for debug skipping in editor and in-game.
Note
Tags information is not saved in layers or into editor settings; it is saved into a tags.txt file within GameSDK/Levels/yourlevelfolder. This will save the list of camera positions and rotations in plain text, allowing you to back up or send versions of tags to other people, or even carry camera positions across levels.
There's no right or wrong system to pick here—we can even have both set up at once to complement each other. Spawnpoints allow quick and unlimited sequential progression, while tags offer extra functionality in the editor and more precise selection. With a few debug locations set up with either system, we can now move on to having moving to these areas progress the required level content.