Enter a trigger and the door opens. After building that in the Level Blueprint, when you want the same door in another room, how much do you copy?
What you want to separate here is "how the door opens" from "what opens it in this room." Put the opening on the door's Blueprint Class and the Level Blueprint can hold just the pairing "when you enter this trigger, open this door."
This article compares the Level Blueprint as "this level's script" against the Blueprint Class as "the plan for a reusable part." At the end we build a door that rises over 1.5 seconds when the player approaches and confirm why separating the roles matters.
What You'll Learn
- How to split level-specific logic from reusable logic
- How to designate a placed Actor with a reference
- The procedure of building the door's motion first, then connecting the trigger
- How to add more doors of the same plan and try a shared change
Level Blueprint: this level's script
A Level Blueprint is a dedicated graph provided per level. Open it from the "Blueprints" menu at the top of the level editor with "Open Level Blueprint."
It gathers events that happen in that place, such as "when you enter this room's trigger, open the door at the back" or "play a camera sequence when this map starts."
What is convenient is that Actors placed in the level are easy to designate right in the graph. Select an Actor in the Outliner and choose "Create a reference to [Actor name]" from the Level Blueprint's right-click menu to place a node pointing at that instance.
That reference designates "which door to ask." Even with three doors made from the same BP_Door, a reference to the entrance door settles the target to that one.
But what it references is the instance placed in this level. Creating a different level does not automatically give you the same placements and pairings.
Blueprint Class: the plan for a reusable part
A Blueprint Class gathers the appearance, variables, and logic of a door, enemy, or pickup item. Here we deal with a Class whose parent is Actor.
Say you make one plan called BP_Door and place three of them in a level. Each placed one is an instance. Even with shared opening logic, state such as "am I open now" and the placement position are held separately (→ UE5 Core Concepts).
Prepare logic called OpenDoor inside the door and the caller can ask "open" without rebuilding the internal nodes each time.
Gathering data and logic inside a part and calling only the needed operations from outside like this is called encapsulation. Here, rather than the level nudging the door's coordinates, it asks the door itself for OpenDoor.
Split by how widely you want to share it
The axis is not just whether it looks like "a thing" or "an effect." Consider whether you want the same mechanism elsewhere and want to fix it in one place.
| What you want to build | Example place to gather it |
|---|---|
| A door that opens the same way in any room | A Blueprint Class called BP_Door |
| The pairing of this room's trigger with that door | This level's Level Blueprint |
| Win and loss rules shared across stages | A shared class such as GameMode |
| Warning lights and effect devices used anywhere | A reusable Blueprint Class |
Thinking "the door part goes in a Class, this location's pairing goes in the Level" reveals our split. Where to put game-wide rules and score is also organized in Game Framework.
Copied logic becomes logic you fix separately later
Copy the same door logic into each level's Level Blueprint and, when you later want to standardize the opening speed, you have to fix every level.
Gather the opening into BP_Door, on the other hand, and fixing that definition reaches every door using the same Class. Prototyping in the Level Blueprint is fine. Wanting similar logic somewhere else is the cue to move it into a shared part.
Duplicating a level copies its Level Blueprint too, but the copies do not become a shared definition. Distinguish "being able to duplicate" from "a fix in one place being reused."
Hands-On: a door that opens when you enter a trigger
We build a mechanism where the door rises 300 cm over 1.5 seconds when the player enters the volume in front of it. Leaving and re-entering does not reopen it during that play session.
A trigger here is a volume that detects entry. Even without a floor switch's visuals, an invisible box volume can detect it. Here we build the door, get it moving on its own, then connect the level-side trigger.
1. Prepare the door's appearance
Use a Third Person Blueprint project. Choose None if there is a Variant option and open a level you can walk in with the template character.
Create a "Blueprint Class" in the Content Browser with Actor as parent, named BP_Door. Leaving DefaultSceneRoot in place under Components, add a Static Mesh as its child named DoorMesh.
| DoorMesh setting | Value |
|---|---|
| Static Mesh | The engine's Cube |
| Relative Location | X=0, Y=0, Z=0 |
| Relative Rotation | X=0, Y=0, Z=0 |
| Scale | X=0.2, Y=1.5, Z=2.2 |
| Mobility | Movable |
| Collision Presets | BlockAll |
| Simulate Physics | Off |
If you cannot find Cube, enable "Show Engine Content" in the asset picker's settings and choose the Cube in Engine's BasicShapes.
Relative Location is the position as seen from the parent component. Here we keep DefaultSceneRoot as a fixed reference and move only its child DoorMesh upward. We do not replace the Root with DoorMesh so that reference remains.
Create a Float OpenHeight under Variables and set its default to 300.0 after Compile. That is "how many cm above the closed position it moves."
2. Build how the door opens
Add a Custom Event in BP_Door's Event Graph and name it OpenDoor. A Custom Event is an entry point for logic you name and call yourself.
Then create TL_Open with "Add Timeline" from the right-click menu and double-click it. A Timeline is a node for changing a value over time. Here we change an "openness" value from 0 to 1.
- Add a Float track and name it
Alpha. - Set the length to 1.5 seconds and turn Loop and AutoPlay off.
- Right-click in the track to add two keys, then select each and enter the Time and Value from the table below.
- Select both keys and set interpolation to Linear. Here we open at a constant speed.
| Key | Time | Value |
|---|---|---|
| Start of open | 0.0 | 0.0 |
| End of open | 1.5 | 1.0 |
A key marks "at this time, be this value." Alpha is the openness name we gave it: 0 is closed, 1 is fully open, and 0.5 is partway.
Back in the Event Graph, connect OpenDoor's white output to TL_Open's "Play from Start." Now calling OpenDoor starts opening from time 0.
Next place a Float Lerp with A at 0.0, B at Get OpenHeight, and Alpha at TL_Open's Alpha output. Lerp finds a value between A and B at Alpha's proportion. Between 0 and 300 here, Alpha 0.5 gives a height of 150.
Drag DoorMesh from Components into the graph and create Set Relative Location from that reference. DoorMesh connects to Target. Right-click the New Location pin and choose "Split Struct Pin" to split it into X, Y, and Z.
| What to connect or set | Value / source |
|---|---|
| Set Relative Location's white exec input | TL_Open's Update |
| Target | The DoorMesh reference |
| New Location X / Y | Both 0.0 |
| New Location Z | The Lerp result |
| Sweep / Teleport | Both off |
Update is the exec output for updating the position while the Timeline plays. Update's white line handles "change the position now," the value from Lerp handles "to what height," and Target handles "which component moves."
Since we aligned DoorMesh's initial relative location to 0 in this example, X and Y stay 0 and only Z changes. Moving from a different relative location is covered in the Timeline article.
3. Confirm the door works on its own first
Compile, save, and place one BP_Door on flat floor. Leave the Actor's Rotation at 0 and Scale at 1. The Cube is 220 cm tall with its center at the origin, so putting the Actor's position 110 cm above the floor surface puts the door's underside on the floor.
Temporarily connect Event BeginPlay → OpenDoor (Target: self) in BP_Door's Event Graph. That calls the door's own OpenDoor at Play start to confirm it moves without a trigger.
Play, and success is the door moving 300 cm above its start position and stopping after 1.5 seconds. Once confirmed, stop Play, remove this connection from BeginPlay, and Compile and save. Next we change it to be called only on approach.
If it does not move here, there is no need to investigate the Level Blueprint yet. Check whether DoorMesh is Movable and whether Update's white line, Target, and New Location Z are connected.
4. Place a trigger in the level
Place a Trigger Box from Place Actors or similar. Put it in front of the door where it does not overlap the player start.
| Setting | Value |
|---|---|
| Box Extent | X=100, Y=100, Z=100 |
| Collision Presets | OverlapAllDynamic |
| Generate Overlap Events | On |
| Actor Scale | X=1, Y=1, Z=1 |
| Height | Center 100 cm above the floor surface |
Box Extent is the length from the center to the edge, so this box is 200 cm per side. Place it about 200 cm in front of the door and adjust so you can walk across it.
Overlap detects the overlap of volumes instead of pushing back on collision. Turn Generate Overlap Events on for the entering character's Capsule Component as well as the detecting Trigger Box.
A Trigger Box's outline is normally invisible during Play. If you are unsure where to walk, confirm the door's and trigger's positions in the editor first.
5. Connect "when, and which door" in the Level Blueprint
Select the Trigger Box in the Outliner and open Blueprints → Open Level Blueprint. Right-click the graph and add On Actor Begin Overlap from Collision under "Add Event for [trigger name]."
This event's Other Actor is whoever entered the volume. From that pin, create Cast To BP_ThirdPersonCharacter and connect the event's white exec output to the Cast too.
Cast checks whether the passed object can be treated as the specified Class. In this template the playable character is BP_ThirdPersonCharacter, so we continue only on success. If you place several characters of the same Class it reacts to them too, so we confirm with the template's single character.
Connect the Cast's success side to DoOnce and turn Start Closed off. DoOnce lets only the first execution through until Reset. Here we leave Reset unconnected so re-entering does not reopen it.
Next go back to the level and select the placed BP_Door. Right-click in the Level Blueprint graph and choose "Create a reference to [door name]." The key point is to choose the placed door in the Outliner, not the plan in the Content Browser.
From that reference's output pin, create a node calling OpenDoor, and connect DoOnce's Completed to its white exec input. OpenDoor's Target is the placed door's reference. The Cast Failed side does nothing.
The next diagram extracts the same graph from DoOnce onward. There is no need to add another DoOnce.
Here the Level Blueprint does not compute the opening. It confirms who entered and asks the designated door for OpenDoor, exactly once.
6. Compare re-entering and adding another door
Compile and save BP_Door and the Level Blueprint, then Play.
| What to check | Expected result |
|---|---|
| Before entering the trigger | The door stays closed |
| Walking into the volume | It moves 300 cm up over 1.5 seconds |
| Leaving and re-entering | It stays open. It does not replay |
| Stopping Play and playing again | You can start over from closed |
If it worked on its own but does not open on approach, put a Print String right after the Overlap event. If nothing shows, check the volume and collision settings; if it does, investigate the Cast's target, DoOnce, and OpenDoor's Target in that order (→ investigating with Print String).
Once it works, try placing another BP_Door in the level. What the current trigger opens is only the door designated in Target. Swap the reference to the second door and the same mechanism opens that one.
To build two trigger-and-door pairs, give each pair its own DoOnce and reference. Then, in BP_Door's Timeline, change both the second key's Time and the Timeline's total length to 3 seconds and both doors open over 3 seconds. Confirm you changed the shared opening without touching the level-side calls, and set both back to 1.5 seconds at the end.
Bonus: Good to Know Up Front
A Blueprint Class can designate a placed target too
We put the pairing in the Level Blueprint, but if you use the same mechanism across many rooms, the trigger side can also be gathered into a Class such as BP_DoorTrigger.
Create an Object Reference variable of type BP_Door inside it, turn on "Instance Editable," and you can choose the target door from each placed trigger's Details. Overlap and Get All Actors Of Class are not the only ways to designate a target.
Passing references and choosing a communication style is covered in three ways Actors communicate.
Making just one door rise higher
Make OpenHeight Instance Editable and you can set 300 or 400 per placed door. "Sharing the opening logic" and "making every instance's value the same" are different things.
Changing the Class default leaves values already overridden on an instance as they are. When trying a shared change, also confirm where the value was set (→ how to use Class Variables).
When you want the same request for things other than doors
For our door-only mechanism, calling OpenDoor through a reference is enough. When you want the same "interact" request for doors, chests, and drawbridges, you can consider a Blueprint Interface.
An Interface standardizes the operation names a target accepts. How each part actually reacts is left to it. Even with one, you still need a reference to "which target to send to" (→ Blueprint Interface).
There are still situations where a Level Blueprint fits
Starting a cutscene unique to this map, or small pairings between placed Actors, are helped by the Level Blueprint's direct references. Rather than avoiding it excessively, split into parts once the reused scope grows.
Starting effects with Sequencer and directing Level Streaming are also uses for it.
Summary
Our BP_Door holds "how it opens," and the Level Blueprint decides "when something enters, which door opens." Since the opening is shared, placing it elsewhere only requires changing the trigger that calls it.
If similar logic is lining up in your Level Blueprint right now, look at where you would want to make one shared fix. That group is a candidate for extraction into a Blueprint Class.