A quick and dirty guide to perfect level changes

✔️ Download example

Level changes are often over explained, and too complicated for their own good. There really is nothing to them and if you follow this tutorial step by step, you should have absolutely no trouble whatsoever.

What is a level change?

A level change is, simply put, a transition or displacement from one map (.bsp file) to another. And the reason you're reading this is because you're lost or trying to get a level change to work properly.

Why do I need level changes?

If you're thinking to yourself: "I can get by without them, and save myself a lot of hassle...", then think again!

Half-Life maps have limits. These limits should never be reached or pushed, you can read more about these in the general MAX_MAP limits part of Tommy14's errors page. If your levels are getting too big you should consider splitting them into 2 or more separate levels to avoid reaching these limits. This can be really useful for reducing r_speeds when working with two or more complex areas, or just to help you keep track of where you are in your map. Huge detailed maps are really difficult to work with in Hammer, as you probably already know.

How do I create level changes?

There are 3 types of level changes:

• Seamless: The simplest level change you can have - walk through a corridor, see some loading text, end up in another map, but your position in the corridor and the environment around you does not change. The place you end up in is a carbon copy of the place you have come from.
• Teleport: Same as above only the environment changes - i.e. go through a corridor in a lab and end up in your office/classroom searching for the 'check for problems' button in your life...It is a bit like teleporting, but you are doing it across maps.
• One-way: You can get there, but you can never return.

Seamless level changes

The only entities you'll need - since you just want a simple level change - will be trigger_changelevel (one in each map) and an info_landmark (also one in each map).

Start by making a suitable corridor: Now to add the info_landmark. Read very carefully is these details are critical:

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) So basically, it's the same info_landmark in both maps. To avoid this problem, make sure the level change triggers in the two maps have at least 56 units between them. Players are 32 units wide and long, but their bounding box can become larger if they walk through at an angle. 56 units is enough space to avoid this problem. Now, compile the maps through hammer or any other front-end compiler but remember not to run the game!, fire up hl with the console, and test the transition. If you did this correctly you should seamlessly jump from one map to the next no matter how you enter the trigger_changelevel.

One way level changes

You would think a one way level change would only require one trigger_changelevel?

Wrong.

You have to set the level change up exactly as you would for a normal change. The difference is that in the second map, reduce the size of the trigger_changelevel brush and move it somewhere that the player cannot get to it. That is what stops the player from going back. Also check the Use Only Flag just to make sure those NoClipping players still can't get back.

Teleporting level changes

A teleporting level change is a bit more involved but is actually a lot less of a headache, provided you're only going to make it a one-way affair. It can also be a cheat a modding team can use when passing between chapters where team A work on the previous chapter, and team B work on the next, without worrying about passing the transitional level geometry between the two.

We will assume 2 maps map1 and map2 and the setup is a one-way teleport from map1 to map2.

map1 setup

In map1, the setup would involve a tiny player-sized room (slightly above 32x32x72), textured with BLACK (or WHITE, whichever you fancy), with these three entities overlapping each other:

• info_teleport_destination placed at least 36u above the floor
  • Name: tp_to_map2
  • Pitch Yaw Roll or Angle: (facing where you want the player to face in the destination map map2)
• trigger_changelevel placed covering the whole room
  • New map name: map2
  • Landmark: tp_landmark
• info_landmark placed the exact same position as the info_teleport_destination
  • Name: tp_landmark

And then elsewhere in map1, have a trigger_teleport target tp_to_map2 in our setup (with delay if desired).

map2 setup

In map2 the setup can go two ways; the easy way (with favourable conditions) or the other way.

If in the previous map's teleport room the player's position is well constrained close to the info_landmark and the info_teleport_destination is already facing the correct way, then it's simply a matter of placing a single info_landmark at the destination point:

• info_landmark placed at least 36u above the floor
  • Name: tp_landmark

Otherwise, another teleportation room is warranted to "catch" the player and place them in the correct position. This room should be bigger than the room in the previous map (about 2x, but can go higher just to be safe). Place the following entities:

• info_landmark placed at the center of the room
  • Name: tp_landmark
• trigger_teleport covering the room
  • Target: tp_dest

And finally, in the main level:

• info_teleport_destination placed at least 36u above the floor
  • Name: tp_dest
  • Pitch Yaw Roll or Angle: (facing where you want the player to face)

And don't forget the obligatory [non-functional] return trigger_changelevel!:

• New map name: map1
• Landmark: tp_landmark
• Flag: ☑️ USE Only (2)