很多刚开始用 UE5 做游戏的同学，都会把“门”当成一个很简单的功能：放一个 Static Mesh，按一下键，门开了，走过去，门关了。
但真正做起来就会发现，门系统横跨了蓝图通信、碰撞检测、动画插值、玩家交互、甚至关卡流转好几个领域。尤其是加入“传送门”机制之后，问题立刻从“怎么开门”变成“门后空间怎么加载”“如何防止玩家反复触发”“传送时怎么保持玩家朝向和速度”。
这篇文章就从零开始拆解 UE5 交互式门系统的完整开发过程：先用蓝图做一个带碰撞检测和按键交互的自动门，再实现一个传送门机制。如果你已经会一些蓝图基础，但不知道门系统该怎么设计才规范，这篇文章可以直接给你一套可以扩展的模板。
1. 为什么门系统是 UE5 学习的“最佳练习项目”
先说一个判断：门系统是 UE5 游戏开发里性价比最高的练习项目，没有之一。
原因有三个：
**第一，它强制你理解 Actor 的交互本质。**UE5 里几乎所有场景物件都是 Actor。门、箱子、NPC、任务触发器，底层交互逻辑都是同一套：谁进入了检测范围、谁按了键、该物件如何响应。把门做明白，等于把 UE5 交互系统的地基打了一遍。
**第二，它会让你直面“状态管理”问题。**门有开、关、正在开、正在关四种状态。如果玩家在门开到一半时再次按键怎么办？如果玩家走出触发区域时门还没关完怎么办？这些都是真实项目中一定会遇到的状态竞争问题，而不是教程里那种一次性跑通的理想情况。
**第三，传送门机制会让你重新理解 UE5 的关卡和坐标体系。**门背后的目标点可能不在同一个 Level，传送本质是修改 Actor 的 World Transform，同时处理子关卡加载和玩家控制权切换。这一套逻辑学会之后，电梯、密室、快速旅行、副本入口，全都可以复用。
2. 核心概念与引擎工作原理
写蓝图之前，先把四个核心概念理清楚。
2.1 Actor 与蓝图类
在 UE5 中所有能被放到关卡里的东西都是 Actor。蓝图类则是一种基于 Actor 的可视化脚本资产，它把“数据”（变量）和“行为”（事件图表）打包在一起。
做门系统时，你最好新建一个继承自 Actor 的蓝图类，而不是直接在一个空 Actor 上乱拖组件。这样做的好处是：同一个门可以被复制成多份，每一份都有独立的开门状态，修改蓝图类时所有实例同步更新。
2.2 Collision：碰撞检测的三个层次
UE5 的碰撞体系分三层：
- Collision Preset（碰撞预设）：给物体一个预设身份，比如 WorldStatic、Pawn、OverlapAll，决定它默认和谁碰撞。
- Collision Responses（碰撞响应）：针对不同对象类型的响应方式，Block（阻挡）、Overlap（重叠）、Ignore（忽略）。
- Collision Events（碰撞事件）：运行时真正触发的事件，如 OnActorBeginOverlap、OnHit。
门系统需要两层碰撞：门体本身的碰撞（防止玩家穿模）和交互检测区域的碰撞（感知玩家进入和离开）。这两层碰撞的预设和响应完全不同，后面的实操会有具体配置。
2.3 Timeline：门动画的核心工具
纯用蓝图旋转门轴，结果通常是门“瞬移”到目标角度。要做出顺滑的开合效果，需要使用 Timeline 节点。
Timeline 在蓝图里相当于一个简易动画曲线。你可以定义 0 到 1 的 Time Range，再指定一个 Value Track，让门从 0 度旋转到 90 度。Timeline 的优势是它天然支持 Play、Reverse、Stop 操作，正好对应开、关、暂停三个动作。
2.4 交互检测：从 Blocking Volume 到 Trace
门系统的交互检测有两种思路：
- Trigger Volume（触发区域）：玩家走进区域就显示“按 E 开门”，离开隐藏提示。适合固定位置的门。
- Line Trace / Sphere Trace（射线检测）：从玩家视角向面前的物体打射线，判断是否命中门的交互点。适合 FPS 类游戏。
本文章节先实现 Trigger Volume 方案，因为它的逻辑更直观，也方便调试；后面会补充射线检测的替代思路。
3. 环境准备与项目配置
本文使用的环境是 UE5.3 版本，蓝图为主，没有额外插件。
如果你是 UE5.0 或 UE5.1，操作基本一致；如果是 UE4.27，部分节点名称略有差异，但整体思路可以迁移。版本细节请以自己项目的实际环境为准。
准备步骤：
- 新建一个 Blank 项目，选择Blueprint类型，Target Platform 选 Desktop，Quality 可以选 Maximum 保证后期烘焙效果，但开发时选 Scalable 即可。
- 关卡选用自带的 ThirdPersonMap。
- 在 Content Browser 里新建文件夹
DoorSystem，下面再建Maps、Blueprints、Meshes三个子文件夹。
如果你打算后面做传送门和子关卡切换，建议开启Level Streaming相关功能。UE5.3 的项目设置里通常默认支持，不需要额外插件。
| 配置项 | 推荐值 | 说明 |
|---|---|---|
| 项目类型 | Blank / Third Person | Blank 需要自己放 Pawn 才能测试；Third Person 自带角色方便验证交互 |
| Target Platform | Desktop | 方便窗口模式调试 |
| Starter Content | 保留 | 门模型可以用自带 Cube 和 Door 模型 |
| 蓝图类 | 继承自 Actor | 方便复制和复用 |
| Collision 可视化 | 开启 | 编辑模式下按Alt+C切换碰撞可视化，排查碰撞问题必备 |
4. 基础门 Actor 的创建与组件配置
在 Content Browser 中找到DoorSystem/Blueprints，右键选择Blueprint Class，父类选择Actor，命名为BP_DoorBase。
打开蓝图编辑器，添加以下组件：
BP_DoorBase（Actor 根节点） ├── DefaultSceneRoot（根组件） ├── DoorMesh（StaticMeshComponent） │ └── DoorCollision（BoxComponent，交互检测区域） └── DoorFrameMesh（StaticMeshComponent，门框，可选）4.1 DoorMesh 的碰撞配置
选择DoorMesh组件，在 Details 面板找到 Collision 分组：
- Collision Preset：选择
BlockAllDynamic，默认会阻挡角色移动。 - Collision Enabled：保持
Query and Physics。
如果你的门模型自带碰撞体，也可以手动删掉后重加一个简单碰撞体。复杂碰撞体在门旋转时容易出现碰撞抖动，这是很多新手会踩的坑。
4.2 DoorCollision 的交互区域配置
新建一个BoxComponent，挂载在DoorMesh下，命名DoorCollision。
它的作用不是阻挡物体，而是检测玩家是否进入交互范围。所以配置完全不同：
- Collision Preset：选择
OverlapAll或者自定义，保证只 Overlap 不 Block。 - Box Extent（范围）：根据门的大小调整。通常 X 设为 100，Y 设为 150，Z 设为 200，保证玩家站在门前不会穿到门里。
- Generate Overlap Events：必须勾选为
true，否则OnActorBeginOverlap事件不会触发。
4.3 为什么不建议把 Trigger Volume 单独放门外
有一种常见做法是在门外再拖一个TriggerVolume蓝图。缺点是：每扇门都要手动摆放一个触发器，门多了以后场景混乱。
把 BoxComponent 挂在门的子节点下，门移动或旋转时，交互区域会跟随移动，这样每个门自包含，方便复制。
5. 蓝图事件图表：状态机与开门逻辑
这一节是核心。我们要在 Blueprint 里建一个简单的门状态机，包含四个状态。
5.1 定义变量
| 变量名 | 类型 | 默认值 | 说明 |
|---|---|---|---|
| IsDoorOpen | Boolean | false | 门是否开着 |
| IsAnimating | Boolean | false | 门是否正在动画中 |
| DoorTargetYaw | float | 0 | 目标旋转角度 |
| OpenYaw | float | 90 | 开门角度 |
| CloseYaw | float | 0 | 关门角度 |
| DoorTimeline | Timeline | 无 | 控制开关门动画 |
在 Variables 区域点击+创建上述变量，变量类型通过下拉菜单选择。DoorTimeline变量是在事件图表中创建 Timeline 节点后自动生成的，也可以提前手动创建变量，类型选择Timeline。
5.2 添加 Timeline 节点
在事件图表中右键输入Add Timeline，得到一个 Timeline 节点，双击打开：
- 在 Track 栏点击
Add，选择Float Track，命名DoorAlpha。 - 点击曲线图标进入曲线编辑器。
- 在曲线编辑器里添加两个点：
(0, 0)和(1, 1)。 - 将曲线类型设为
Auto，实现平滑缓动效果。
Timeline 的DoorAlpha输出值会在 0 到 1 之间变化。我们用它来控制门的旋转角度：
DoorRotation = FMath::Lerp(CloseYaw, OpenYaw, DoorAlpha)对应蓝图节点是Lerp (Float)，输入 A 是CloseYaw，B 是OpenYaw，Alpha 接 Timeline 的输出。
然后设置DoorMesh的 RelativeRotation：
DoorMesh -> SetRelativeRotation(0, DoorRotation, 0)注意：门旋转的是 DoorMesh 而不是 Actor 本身。这样 Actor 的 Location 和朝向保持不变，后续做触发区域、传送点都更稳定。
5.3 开门的按键交互逻辑
回到事件图表，处理玩家交互逻辑。
使用BoxComponent 的 OnActorBeginOverlap / OnActorEndOverlap来感知玩家进入和离开。
当玩家进入门的交互范围时，判断这个 Actor 是不是 Pawn：
OnActorBeginOverlap -> CastToCharacter (或者 Is A PlayerController) -> 是：设置变量 CanInteract = true，显示提示文本当玩家离开时：
OnActorEndOverlap -> 设置变量 CanInteract = false，隐藏提示文本在 Tick 里检测按键 E 会污染逻辑，不推荐。更好的办法是用PlayerController 输入绑定。不过为了演示清晰，我们可以先采用事件驱动思路：
在 Level 蓝图里调用BP_DoorBase的公开函数ToggleDoor，然后门蓝图自己判断状态。
如果偏好在门蓝图内部处理输入，可以在 Event BeginPlay 时获取 PlayerController，然后调用EnableInput，在InputAction E事件里调用ToggleDoor。
下面给出标准版 ToggleDoor 逻辑：
ToggleDoor（自定义事件 / 函数） -> If IsAnimating is true: Return（防重复触发） -> IsDoorOpen = NOT IsDoorOpen -> If IsDoorOpen: -> DoorTimeline: Play（从当前播放到末尾，也就是开门） -> Else: -> DoorTimeline: Reverse（从当前反向播放回 0，也就是关门）Timeline 的 Play 和 Reverse 自然会处理“门开到一半时反悔”的情况，因为 Play 从当前值继续向上，Reverse 从当前值往回走。
5.4 完整 Blueprint 逻辑示意
[OnActorBeginOverlap] -> Cast to Character -> IsValid -> Set CanInteract = true -> Print String "Press E to open" [OnActorEndOverlap] -> Set CanInteract = false -> Print String "" [InputAction E - 或者通过 Level Blueprint 调用] -> ToggleDoor [Timeline DoorAlpha] -> Lerp(CloseYaw, OpenYaw, DoorAlpha) -> SetRelativeRotation(0, Result, 0) -> Set IsAnimating = true [Timeline Finished] -> Set IsAnimating = false实际蓝图节点连接如下：
// 事件：OnActorBeginOverlap // 参数：Other Actor // 逻辑：Cast 判断是否 Character EVENT OnActorBeginOverlap -> Branch (Is Valid Cast) -> True: Set CanInteract TRUE -> True: PrintString("Press E to Toggle Door") -> False: 忽略 // ToggleDoor 函数内部 FUNCTION ToggleDoor -> Branch (!IsAnimating) -> True: SET IsDoorOpen = !IsDoorOpen Branch (IsDoorOpen) -> True: DoorTimeline.Play() -> False: DoorTimeline.Reverse() -> False: 拒绝操作5.5 如果组件旋转轴不对怎么办
门正常情况下绕 Z 轴旋转 90 度打开。如果发现门向后开或者向里开，有两种修正方法：
- 调整 DoorMesh 的 Relative Rotation，使门正面的朝向符合预期。
- 调整 OpenYaw 的正负值：正数向外开，负数向内开（取决于模型默认朝向）。
调试时建议在门旁边放一个 Debug 文本节点，实时打印 DoorMesh 的角度，这样能快速确认旋转是否正常。
6. 传送门机制：从“门”变成“空间跳跃入口”
基础门完成后，我们来扩展传送门功能。
传送门机制的本质很简单：当玩家与门交互时，把玩家传送到目标坐标，同时保持玩家面对的方向符合视觉预期。
但在实际项目中，有几个很容易出问题的点。
6.1 传送门蓝图的设计
新建一个蓝图类BP_TeleportDoor，继承自BP_DoorBase。
增加以下变量：
| 变量名 | 类型 | 说明 |
|---|---|---|
| TargetDoor | Actor Reference | 目标门（配对使用） |
| TeleportLocation | SceneComponent | 目标传送点组件 |
| bOnlyTeleport | Boolean | 是否只传送不开门 |
实现逻辑时，覆盖ToggleDoor函数：
FUNCTION ToggleDoor（BP_TeleportDoor） -> If bOnlyTeleport: -> Teleport Player to TargetDoor.TeleportLocation -> Return -> Else: -> 先调用 Super 的 ToggleDoor（继承父类逻辑） -> 延迟 0.5 秒后 Teleport Player问题在于：如果门还没完全打开就传送，玩家可能被门夹住，或者穿过门体时产生碰撞抖动。所以更好的做法是：等待 DoorTimeline Finished 后再传送。
6.2 传送代码的核心节点
传送的关键节点是SetActorLocation或TeleportTo，推荐使用TeleportTo，因为它会处理物理状态和碰撞更新。
// BP_TeleportDoor 内部 EVENT OnTimelineFinished（覆写） -> If bEnableTeleport && CurrentTarget != None -> Get Player Character -> TeleportTo( TargetDoor.TeleportLocation.WorldLocation, TargetDoor.TeleportLocation.WorldRotation, true, // 是否 sweeping（碰撞检测） true // 是否传送后投弹？视需求 )注意：TeleportTo的Sweep参数建议设为true，避免传送到目标点时被卡进墙体。实际项目中，如果同时有多个物体要传送，可以使用Unreal Engine 的 Gameplay Teleport插件，或者自己维护一个传送列表，逐个调用 TeleportTo。
6.3 双门配对
双门配对是传送门最常见的问题：两扇门互相传送，玩家 A 进入门 1 到门 2，门 2 的玩家 B 也可能同时进入门 2 传送到门 1，形成无限循环。
解决方案：
- 给传送门添加一个冷却时间变量
TeleportCooldown，默认 0.5 秒。 - 玩家完成传送后，给玩家设置一个短时间的不可交互状态。
- 或者使用
LastTeleportDoor引用，传送后记录上一次传送的门，冷却时间内如果再次进入，不做处理。
// 定义变量 LastTeleportTime（Float 类型） FUNCTION TeleportPlayer -> If (GetWorldTimer.TimeSince(LastTeleportTime) < TeleportCooldown) -> Return -> Teleport Player -> LastTeleportTime = GetWorldTimer.CurrentTime6.4 面向旋转处理
传送到目标点后，玩家默认会保持传送前的朝向。如果目标门面朝北，玩家传送后却看着南边，视觉上就会很怪。
所以传送后要手动设置玩家旋转：
// 获取目标旋转 FRotator TargetRotation = TargetDoor.TeleportLocation.WorldRotation; // 设置 Pawn 的 Controller 旋转 GetController()->SetControlRotation(TargetRotation); // 设置 Pawn 自身旋转 Pawn->SetActorRotation(TargetRotation);最好的方案是以目标门的旋转作为玩家新的朝向，这样玩家穿过门后，自然面向门的另一侧空间。
7. 运行结果与验证方式
完成蓝图后，保存并编译蓝图，然后拖一个BP_DoorBase到场景里，把门放在 ThirdPersonCharacter 出生点附近。
7.1 测试清单
| 测试项目 | 预期结果 | 判定标准 |
|---|---|---|
| 走进设施范围 | 屏幕显示“Press E”，或控制台输出日志 | Overlap 事件触发 |
| 按 E / 按键绑定 | 门平滑旋转到 90 度 | 门动画流畅，无跳帧 |
| 再次按 E | 门反转到 0 度 | Reverse 逻辑生效 |
| 门开启时角色保持站立 | 玩家不被门撞飞或穿模 | 碰撞配置正确 |
| 双击 E | 门不会瞬间开关，会等待当前动画完成 | IsAnimating 判断生效 |
| 快速反复进出触发区域 | 不会有逻辑错乱 | 状态机稳定 |
7.2 运行排查
如果按 E 没反应，优先按顺序检查：
- 检查
DoorCollision的 Generate Overlap Events 是否勾选。 - 在
OnActorBeginOverlap事件里加一个 Print String 节点，确认事件本身是否触发。 - 检查键盘输入绑定是否启用了
Enable Input。蓝图 Actor 默认不接收输入，需要手动开启。 - 如果只是面板不显示，检查是否为 UI 层问题，建议先用 Print String 验证逻辑，再接 UI。
8. 常见问题与排查思路
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 门动画瞬间完成，没有渐变 | Timeline 曲线未设置缓动，或曲线点全部重合 | 打开 Timeline 检查曲线编辑器 | 设置 0 到 1 两个关键帧，曲线类型改为 Auto |
| 玩家进不了门，被挡在外面 | DoorMesh 碰撞仍为 BlockAllDynamic | 进入碰撞可视化模式查看碰撞体 | 把门开启过程中的碰撞设为 Overlap，或使用 Ignore Pawn |
| 玩家进门后卡在门框内部 | 门框碰撞体和门体碰撞体同时阻挡 | 检查组件的 Collision Preset | 门框使用 BlockAll，门体在开门时设为 Ignore Pawn |
| 按 E 无响应 | Actor 没有接收输入 | 在 BeginPlay 里调用 EnableInput 并传入 PlayerController | 确认 Input Action 映射已配置 |
| 传送后玩家方向不对 | 没有同步 ControlRotation | 观察传送后玩家视角朝向 | 传送后设置GetController() -> SetControlRotation |
| 双门无限循环传送 | 没有冷却时间 | 观察日志中重复传送记录 | 添加 LastTeleportTime 变量和冷却判断 |
| 门旋转后碰撞体位置不正确 | 碰撞体挂在 DoorMesh 子级但未同步旋转 | 检查组件层级 | 确保 DoorCollision 是 DoorMesh 的子组件，且 RelativeTransform 正确 |
| 多人联机时门不同步 | 蓝图没有复制属性 | 检查是否开启网络复制 | 为 IsDoorOpen 和 DoorRotation 添加 Replicated 属性，并用 Multicast 广播动画 |
8.1 关于“门开到一半，碰撞要如何处理”的思考
如果你门开启过程中还想保留碰撞，玩家会顶在门板上被推着走，体验很差。
常见做法是：开门前把 DoorMesh 的 Collision Enabled 设为 NoCollision，关门后再恢复。但也有副作用：门开启时，玩家可以穿过门框，这在 FPS 游戏里会有些不自然。
更好的方案是：给门添加WalkThrough Open Door的判定——如果门开角度超过 70 度，把门的碰撞改为 Overlap，允许玩家穿过；低于 70 度时保持碰撞。
9. 最佳实践与工程建议
9.1 命名与目录规范
UE5 中的门蓝图建议命名前缀BP_Door、BP_TeleportDoor，材质命名带M_，贴图带T_。场景中每扇门命名时加上区域前缀，如BP_Door_Hallway_01，方便后期查找。
9.2 用函数而不是事件驱动
交互逻辑应当尽量放到函数（Function）而不是事件（Event）里。事件只能被事件源触发，函数可以被任何逻辑调用，且可以设置返回值。ToggleDoor应该做成函数，这样它可以被 NPC、远程触发器、剧情脚本统一调用。
9.3 碰撞体不要密密麻麻
很多新手会把门的碰撞体做得和模型完全贴合，结果门旋转时每一次碰撞都触发物理模拟，性能白白浪费。
实际的碰撞体应该用简单的 Box、Sphere、Capsule 组合，能挡住玩家即可。门框区域复杂度高，可以考虑用成组碰撞，不要用模型默认的三角形碰撞体。
9.4 关于传送点的坐标管理
传送门要维护一个TeleportLocationSceneComponent，而不是直接用某个门组件的 WorldLocation。原因是组件可能随门旋转，直接取门的位置会导致玩家传送后出现在错误位置。建议单独设置一个子组件，指向目标空间的中心点。
生产环境中，如果传送空间很大，还可以在这个点上添加一个TeleportDirection箭头工具，显示玩家传送后的朝向，方便美术和策划调整。
9.5 多人联机的门系统要怎么做
UE5 多人环境下，门系统需要注意：
IsDoorOpen、DoorAlpha必须标记为Replicated。- 开门动画使用
Multicast，所有客户端同时播放。 - 碰撞交互只允许服务器处理，客户端发起请求后由服务器确认。
- 传送逻辑要在服务器端执行，然后客户端通过
OnRep同步位置和旋转。
如果不做多人，这一步可以跳过；但如果项目后期有联机需求，一开始就把变量复制属性设置好，比后期重构省事得多。
10. 总结：门系统的下一步扩展方向
这篇教程的核心逻辑其实就两条：状态机管理 + Timeline 动画驱动，传送门则是在状态机基础上增加了“目标空间跳转”的能力。
把这两条跑通之后，你可以继续扩展这些方向：
- 密码锁门：在
ToggleDoor前增加一个密码验证面板，验证通过才执行开门逻辑。 - 自动感应门：用 OnActorBeginOverlap 直接触发开门，不加按键交互，适合科幻风场景。
- 双开门：把两扇门组合到同一个 Actor 中，用两个 Timeline 分别控制左右门板的旋转。
- 门后加载子关卡：用 Level Streaming 实现门后大世界加载，传送点使用子关卡激活。
- 可破坏门：用 Physical Material 和 Damage 事件实现门被攻击后碎掉的效果。
我建议你把这个门系统作为一个通用模板保存下来。后续做任何含交互物的游戏原型，都可以直接复制蓝图类，替换模型和输入绑定就能跑。
只要状态机、Timeline、碰撞配置这三个核心点不出错，门系统就能稳定运行。下一步，你可以试着把按键交互改为 LineTrace 射线检测，练习一下点击交互门的写法——那是另一个很有价值的小课题。
