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.
The info_landmark
The info_landmark
sets up a constant point of reference in the origin and destination maps. It must appear in both maps otherwise the level change will not work correctly. The origin and destination info_landmark
must both have the same Name (targetname).
The placement of the info_landmark
is important. The position of the player in the origin map, relative to the info_landmark
, will be his position in the destination map, relative to its info_landmark
. With this in mind, you must make sure that the player will not end up stuck in any brushes, or even outside the world, through careful placement of the info_landmark
.
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.
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
.
The trigger_transition
With all this talk of "level transitions", you'd probably think that a trigger_transition
was an essential part of every level change. In fact, it's rarely used. Its purpose is to control when and if a trigger_changelevel
will function, and what comes through to the new level. To use it, simply set it's Name ( targetname ) to the same value as the Name of the info_landmark
.
The trigger_transition
accomplishes two things. Its associated trigger_changelevel
will not work unless the player is in the trigger_transition
, and when the trigger_changelevel
does work, only those entities within the trigger_transition
will be taken to the new level.
The trigger_transition
is useful, for example, if you have a situation where a player must activate something then go stand in a certain place and wait a few seconds for the level to change. This is the premise for example map #3.
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.
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.
Global Entity Names
A global entity name allows you to specify an object that appears in two maps as the same object. Simply give the object in each map the same
Global Entity Name (
globalname) value.
If you are in an elevator going down a shaft, and you go through a level transition, this is where you'd want to use the global entity name. In both maps, the elevator would be drawn in the same position. Then, both elevators would be given the same global entity name. Now, when the elevator goes through the level transition from the origin map, the elevator in the destination map will take its properties (movement) and postion and carry on as if the player is still riding the same elevator (basically, he is). This is demonstrated in the example map, below.
example map #4
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.
EDIT: I got it working, I noticed it worked when I jumped, so I added a few brushes with the "brush" texture from ZHLT.wad that raises you up a bit, and now it works!