VERC: In Depth: Level Transitions Last edited 5 years ago2019-04-13 10:22:59 UTC

An issue constantly surrounded in questions is that of level changes. They remain a mystery to many designers, and for no real reason as their concept is rather simple.

Level Change Mechanics

Regardless of what style of level change you're setting up, every level change will be based on the same premise. Every level change will contain two trigger_changelevel entities (one in each level), and two info_landmark entities (again, one in each level). The info_landmark entities will both have the same Name (targetname), and this name will be used as the value for both trigger_changelevel's Landmark name (landmark) property. The value of the New map name (map) property for the trigger_changelevel in the origin map will be the map name ('change2' for example) of the destination map, and vice versa for the trigger_changelevel in the destination map. In the example map below, you start in a section of hallway. If you walk forward, you will pass through a level transition. You will see some "loading..." text, then you'll be in the second map. Generally, you wouldn't notice that you're in a new map except for the "loading..." text, but I've placed a biohazard sign at the end of the hallway of the second map to make it more apparent. You can walk backward to go back through the level transition into the first map.

• example map #1 (Link: change_ex1.zip)

Above is the most basic kind of level change. Whenever you need to split a large level into smaller sections, it can be done like that.

Note: this is very important - when testing level transitions, you should not run your map from the editor or through a frontend-compiler. Compile the map(s) without running the game, then load Half-Life manually and load the maps from the console. If you don't know how to access the console, refer to the Accessing the Half-Life Console article.

There are basically three types of level transitions:

• seamless (as described above)
• displacement
• one-way

All of these can also be triggered. If you are going to trigger a trigger_changelevel , give it a Name (targetname) and set its ' USE Only ' flag. This will prevent it from working until it has been activated by another event.

The only other variation on level transitions is with using a trigger_transition.

Displacement Level Transitions

A seamless level transition is when the player goes to a new level but his environment stays the same. A displacement level transition, therefore, is when a player not only changes to a new level, but his actual physical environment is different as well.

This would be useful for making a level transition disguised as a teleporter or portal. The main difference here between the basic transition mentioned above is that you need to make sure that the player doesn't end up stuck in anything when he switches to the new level. This means you need a clear area around the info_landmark in the second map equal to any area in the first map that the player could teleport from.

In the example map below, two "room" levels are linked by teleport portals. You can change levels simply by walking through the portals.

• example map #2 (Link: change_ex2.zip)

The One-Way Transition

A one-way transition is any transition where you go from the origin map to the destination map, but you cannot return to the origin map. This is the type of transition that usually gives people headaches. Logic would seem to tell you that you don't need a trigger_changelevel in the destination map, just the info_landmark. For some reason, this isn't correct. The destination map must have a trigger_changelevel in it that correctly references the previous map in the New Map Name property, and identifies the info_landmark in the Landmark Name property.

The example map below demonstrates a one-way transition, modeled loosely after the Star Trek teleportation style. The transition is setup like the above displacement transition, except that the trigger_changelevel is a small cube positioned just above the info_landmark (to keep easy track of it), and its "USE Only" flag is set so that it will never accidentally be activated by the player.

Global Consistency

There's one more thing to discuss, and that's how to carry brush-based entities through a level transition. For example, say you're riding an elevator down a shaft and you want to do a level change. You would have to use a Global Entity Name.

• example map #3 (Link: change_ex3.zip)

Note: a newer version of the game date files added the Global Entity Name property to many of the func entities. It will be much easier to use them if you have the most current game data file]]. If you want to manually add the Global Name property to an entity, access its properties and deselect SmartEdit, then add a globalname key and value.

Redux

As you can see (I hope!), the concept of level transitions really isn't all that complicated. The basic elements involved are all quite easy to use and setup. Whenever problems arise, they can usually be attributed to either not putting a trigger_changelevel in the destination level (in the case of one-way transitions), or some error with the info_landmark entities - either not placing them correctly, or not referencing them correctly. By knowing the information presented here, you should be able to make level changes easily.

Additional Notes

A very common problem people experiene is when a level transition doesn't work and the following error message appears in the console ...

CHANGE LEVEL: map1 landmark1

... where map1 is the name of the map you are trying to change to, and landmark1 is the name of the info_landmark being referenced in the change.

Note: You will only see the above error in the console if you've run the game with the -dev parameter, or manually specified developer 1 in the console prior to loading the map.

This problem occurs because the area in map1 where the player would spawn is already occupied, in whole or in part, by another trigger_changelevel. When setting up level transitions, it is a good idea to put a bit of dead space (that is, space not occupied by a trigger_changelevel) around the landmarks, like this:If the error is already occurring, the solution is simple, move the trigger_changelevels futher away from the info_landmark.