企业官网建设流程全解析

简介：这是一份面向 Unity 开发者的完整 2D 迷宫冒险解谜游戏源码，采用 C# 编写，支持 Unity 2017.4.36f1 及以上版本，适合刚开始接触 Unity 或想学习完整休闲游戏项目的读者。项目以“火男孩与水女孩”双角色合作闯关为核心，包含开关门、冰冻、火焰机关等谜题机制，玩家需收集全部钻石才能过关；同时接入 AdMob 与 AppLovin Max 广告聚合，可直接面向 Android/iOS 发布。源码中包含角色移动、双人切换、机关响应、钻石收集等核心玩法模块，动画与音效资源齐全，便于直接改造。压缩包共 2000 个文件，核心包括 595 个 C# 脚本（玩家控制、机关逻辑与广告管理等）、29 个预制体、43 个 Unity 场景、30 个动画控制器，以及材质、着色器、音效和动画资源，整体大小约 251.33MB，目录结构清晰，便于按模块拆解学习。资源已有 475 人学习/下载，适合希望快速获得可运行模板、研究双人合作解谜关卡设计与商业化配置的开发者。

1. 森林冰火人迷宫源码：这套 Unity 冒险解谜项目到底能给你什么

Red Boy And Blue Boy（森林冰火人）迷宫听起来是个小游戏，但它背后的技术点一点也不小：双人协作、冰火机关、迷宫地图、物理碰撞，正好把 Unity 2D 开发的几块硬骨头全占齐了。标题里这串名字，指的是一套用 C# 写的 Unity 冒险解谜项目源码——你拿到的不只是「一个能玩的游戏」，更是一个怎么组织双人解谜玩法的参考框架。想抄作业的 Unity 新手能直接改参数跑通原型，做过一两款小游戏的熟手则能研究它的关卡机制划分方式，拿来改成自己的关卡框架。后面内容我按「先看清结构，再写角色，再做地图机关，最后排错」的顺序，把整套方案掰开讲。

2. 拿到 Unity 源码先看哪里：项目结构与双人协作机制拆解

很多人在 Unity 里打开别人写的项目，第一件事就是按 Play，结果报错一堆。我不太建议这么做。先花十分钟把目录扫一遍，搞清楚脚本、场景、预制体三个核心块在哪，后面改起来才不翻车。这类冒险解谜源码包的常规组织方式，通常围绕 Assets 展开，场景、脚本、预制体和地图分开存放。我一般拿到手先做一件事：在项目根目录用 tree 把目录结构拉出来看一眼。

tree -L 3 Assets/

输出里重点盯四类路径：Scenes（看有几个关卡场景）、Scripts（看 Player、Mechanism、Manager 是不是分了文件夹）、Prefabs（角色和机关是不是预制体）、Tilemap（地图资源放在哪）。如果Scripts下面全是几十个.cs堆在一个文件夹里，说明作者没怎么整理；如果分成了 Player、Mechanism、Manager 子目录，那整个项目的读起来会轻松很多，也意味着角色代码、机关代码、状态管理代码是解耦的，正是这类双人解谜项目该有的样子。

2.1 跑通前的环境检查：Unity 安装版本、输入设置与目标平台

打开项目的第一个坑往往不是代码，而是 Unity 安装的版本对不上。这类 2D 解谜项目大多基于 2021 LTS 或 2022 LTS 制作，如果你本机的 Unity 主版本和项目不一致，会触发一次「打开时自动升级」的对话框。我的习惯是：先用 Unity Hub 安装对应大版本（比如项目记录的是 2021.3.x，就装 2021.3 的最新小版本），把升级风险降到最低。

版本对上之后，进Edit > Project Settings > Player确认两项：Scripting Runtime Version 用 .NET Standard 2.1 或 4.x 都可以，但别随意切换，切换会导致第三方库重新编译报错；还要确认 API Compatibility Level 和你本地预期的目标平台一致。再看Input Manager的轴定义里有没有Horizontal和Jump，这类老式项目通常还是靠默认轴跑，新建的空工程如果删过轴，角色会直接动不了。这步检查花不了五分钟，却能避开一半的「代码没报错但角色就是不动」问题。

提示：如果打开项目后出现大量The type or namespace name 'Input' could not be found，先别改代码，八成是项目用了新 Input System 包而你的工程里没安装，去 Package Manager 补上com.unity.inputsystem即可。

2.2 双人合作解谜的状态机：角色分工、机关条件与胜负判断

森林冰火人这类游戏的核心是「两个人必须互相配合」，源码里支撑这套配合的通常是三个东西：角色预制体上的移动脚本、机关触发器上的条件检测、一个全局的 GameManager 来跟进关卡状态。我倾向于把 GameManager 写成场景内的单例，它只干三件事：登记当前场景的红蓝角色、接收机关触发的解谜进度、统一处理过关和重置。下面是一段可落地的 LevelStateManager 写法：

using UnityEngine; public class LevelStateManager : MonoBehaviour { public enum Phase { Waiting, Playing, LevelCleared } public static LevelStateManager Instance { get; private set; } [SerializeField] private Transform redPlayer; [SerializeField] private Transform bluePlayer; private Phase currentPhase = Phase.Waiting; private int activatedMechanisms; private int requiredMechanisms; private void Awake() { if (Instance != null && Instance != this) { Destroy(gameObject); return; } Instance = this; currentPhase = Phase.Waiting; } private void Start() { // 机关数量由场景里的对象自动统计，避免手填配置出错 requiredMechanisms = FindObjectsOfType<MechanismTrigger>().Length; currentPhase = Phase.Playing; } public void RegisterMechanismDone() { activatedMechanisms++; if (activatedMechanisms >= requiredMechanisms && currentPhase == Phase.Playing) { currentPhase = Phase.LevelCleared; Debug.Log("Level cleared"); } } }

这段代码的用意是把「谁触发、谁计数、谁判胜」从机关脚本里拆出来。每个机关只负责上报自己的状态，GameManager 统一做计数；这样后面加新机关不用改 Manager。参数上，requiredMechanisms是运行时统计的，所以你在场景里放几个机关，过关条件就自动变成几个，不用手动改序列化字段。这里的MechanismTrigger是所有机关脚本的公共基类，按钮、门、压力板都会继承它，第 4 章写机关时我会把它的具体形态补上。

2.3 预制体与场景的引用关系：为什么角色和机关不能散着放

我见过不少「源码运行报空引用」的案例，八成不是代码逻辑错，而是预制体丢失或引用断掉。原因很简单：角色和机关被做成了预制体，但在场景里却直接修改并删除了预制体实例的某个脚本引用。避坑做法是：打开Prefabs目录，把 RedPlayer、BluePlayer、Door、Button 这些核心预制体逐个检查 Inspector 里的引用是否完好；凡是脚本字段显示的None (GameObject)，都要先补引用再运行。

另外建议先在场景里只保留教学关的前两段，确认移动和开门都正常，再去后面的迷宫关卡。这样如果报错，你第一时间能判断是物理问题还是机关配置问题，而不是在几十个开关里查黑匣子。做双人解谜项目，角色和机关一定要做成预制体，而不是每个关卡里重新摆一份；不然你会陷入「改了一个按钮脚本，结果另外五关里全是旧逻辑」的泥潭。

3. 用 C# 写角色控制与物理参数：移动、跳跃、碰撞判定怎么调才像原版

森林冰火人手感好的原因，不是美术多强，而是物理参数调得克制：移动有惯性但不大，跳跃高度刚好跨过一格砖，下坠略带加速度但不夸张。这套手感在 C# 代码里主要由三块决定：输入读取、刚体施速、地面检测。写脚本前先说结论：角色控制不要直接改transform.position，而是通过Rigidbody2D施加速度，这样才能吃到 Unity 物理引擎的碰撞判定，避免高速穿墙。

3.1 PlayerController 最小实现：速度驱动、切向摩擦与地面检测

下面这段脚本是这类横板解谜项目里最常用的角色控制器写法。我把它压到只有移动和跳跃，方便你对照改参数。注意脚本里用了新的rb.linearVelocity，这是 Unity 2022.2 之后的命名；老版本请换成rb.velocity，我会在代码后面说明两者区别。

using UnityEngine; [RequireComponent(typeof(Rigidbody2D))] public class PlayerController : MonoBehaviour { [Header("移动")] [SerializeField] private float moveSpeed = 6f; [SerializeField] private float acceleration = 12f; [SerializeField] private float airControlFactor = 0.6f; [Header("跳跃")] [SerializeField] private float jumpForce = 11f; [SerializeField] private float fallMultiplier = 2.2f; [SerializeField] private float lowJumpMultiplier = 1.6f; [SerializeField] private LayerMask groundMask; [Header("地面检测")] [SerializeField] private Vector2 groundCheckOffset; [SerializeField] private float groundCheckRadius = 0.18f; private Rigidbody2D rb; private float horizontalInput; private bool isGrounded; private void Awake() { rb = GetComponent<Rigidbody2D>(); rb.freezeRotation = true; } private void Update() { // 老 Input Manager 读横轴，和项目原有轴设置直接对接 horizontalInput = Input.GetAxisRaw("Horizontal"); if (Input.GetButtonDown("Jump")) { TryJump(); } } private void FixedUpdate() { ApplyMovement(); CheckGrounded(); ApplyVariableGravity(); } private void ApplyMovement() { float targetVelocityX = horizontalInput * moveSpeed; // 加速度用 Lerp 模拟惯性，空中和地面使用不同系数 float factor = isGrounded ? acceleration : acceleration * airControlFactor; float newVelX = Mathf.Lerp(rb.linearVelocity.x, targetVelocityX, Time.fixedDeltaTime * factor); rb.linearVelocity = new Vector2(newVelX, rb.linearVelocity.y); } private void TryJump() { if (!isGrounded) return; rb.linearVelocity = new Vector2(rb.linearVelocity.x, jumpForce); } private void CheckGrounded() { Vector2 origin = (Vector2)transform.position + groundCheckOffset; isGrounded = Physics2D.OverlapCircle(origin, groundCheckRadius, groundMask) != null; } private void ApplyVariableGravity() { if (rb.linearVelocity.y < 0f) { // 下落阶段重力放大，落地更干脆 rb.gravityScale = fallMultiplier; } else if (rb.linearVelocity.y > 0f && !Input.GetButton("Jump")) { // 短按跳跃键时重力加大，跳得矮 rb.gravityScale = lowJumpMultiplier; } else { rb.gravityScale = 1f; } } private void OnDrawGizmosSelected() { Gizmos.color = Color.green; Gizmos.DrawWireSphere((Vector2)transform.position + groundCheckOffset, groundCheckRadius); } }

逻辑说明分四块。移动：用Mathf.Lerp把当前水平速度逐步逼近目标速度，acceleration越大手感越「黏」，越小越「飘」；空中把加速度乘以 0.6，是为了让角色在空中只能小幅修正落点，不至于变成飞行模式。跳跃：只在isGrounded时触发，配合groundCheckRadius做地面检测，防止无限跳。变重力：下落阶段gravityScale加大，让角色坠地干脆；短按跳跃键时空中重力也加大，这样轻点跳会跳得低，这就是「可变量跳跃」的实现方式。

参数上，moveSpeed设 6 是大多数横板解谜的平衡点，迷宫关卡里建议 5～7，别超过 8，不然机关触发区会跟不上角色速度。jumpForce设 11，跳跃高度大约 2～3 格 Tile，具体要看你的 Grid cell size 定，先按这个跑，再微调。groundCheckRadius0.18 适合 1×1 单位大小的角色，角色缩放过就按比例调整。OnDrawGizmosSelected 是调试利器，它会在 Scene 视图画出地面检测的圆圈，你看得到检测范围，就不会凭感觉瞎猜。

补充一个 Unity 版本细节：老版本脚本读刚体速度写rb.velocity，2022.2 之后linearVelocity才是规范写法。你在网上搜「unity物体速度怎么获取」会看到两种答案，先确认自己的 Unity 大版本再决定用哪个，两个都能编译，但旧 API 在 2023 以上的版本里会有告警。

3.2 双人同屏控制与碰撞分层：一键盘操作两个角色还不打架

双人解谜的输入映射没有标准答案，常见做法是：Player1 用 WASD + 空格，Player2 用方向键 + 右侧 Ctrl 或 Shift。老 Input Manager 里新增轴最省事，不用改代码，只要在Edit > Project Settings > Input Manager里复制一条 Horizontal，改名 Horizontal2，把 Negative/Positive 按键改成左右方向键即可。对应代码用Input.GetAxisRaw("Horizontal2")读取，逻辑和 3.1 的 PlayerController 完全一致，只是输入源不同。

接下来是物理层。两个角色必须互不碰撞，否则推来推去会把机关站位带偏。操作路径：给两个角色建两个 Layer，分别命名RedPlayer和BluePlayer，然后打开Edit > Project Settings > Physics 2D > Layer Collision Matrix，把RedPlayer行和BluePlayer列交叉处的勾取消。这一步经常被忽略，不少双人项目角色一碰就粘在一起，排查一圈最后都落在这个矩阵上。

还要注意：机关触发器大多用 Trigger 实现，角色用 Dynamic Rigidbody2D，地形应该是 Static。如果地形也挂 Rigidbody2D，物理引擎每帧都要额外结算一次碰撞响应，关卡一复杂就掉帧。地形的正确姿势是只挂 Collider 2D，不挂刚体；通过 Inspector 把 Body Type 设为 Static 不是必须的，没有刚体就是静态。

4. 迷宫地图与机关解谜：Tilemap 碰撞、按钮门和冰火判定怎么搭

地图是解谜游戏的地基。森林冰火人迷宫这种横板关卡，地图信息可以拆成两层：静态的砖块、冰块、岩浆区域，和动态的门、按钮、挡板。静态层用 Unity 的 Tilemap 做，动态机关用预制体放，两层各管各的，后面调关卡才不乱。这也是源码类项目里最常见的组织方式，比整张图用一个图片拼碰撞体要灵活得多。

4.1 Tilemap 手绘迷宫：Composite Collider 合并碰撞网格

我倾向于手绘地图而不是运行时生成地图，因为机关位置、跳台高度这些是设计出来的，不是随机出来的；迷宫关卡尤其如此，手绘能保证每一格都经过推敲。用 Tile Palette 把砖块刷进 Tilemap 后，给它加一个Tilemap Collider 2D，再挂一个Composite Collider 2D，记得把 Tilemap Collider 上的Used By Composite勾上。这一步做完，原本上百个小方块的碰撞体就被合并成几块大一统多边形，物理计算量大幅下降。

Composite 还有一个隐藏好处：碰撞体边界合并后，角色不容易被 Tile 之间的接缝卡住。如果不合并，两块砖中间的细缝在高速移动时可能把刚体卡一下，表现就是角色偶尔抖一下。参数上，Composite Collider 的Geometry Type选Polygons，Physics Material留空或放一个摩擦系数 0.05 的材质，否则角色站在斜坡上会莫名刹车。网格尺寸就用 Tilemap 默认的 1×1，方便你按格子数算跳跃距离。

4.2 机关触发器：按钮按颜色放行，门用状态机响应

机关是解谜玩法的裁判，最常见的组合是按钮加门：一个按钮控制一扇门，按钮有颜色属性，只有对应角色能激活。要让第 2 章的LevelStateManager生效，按钮这类机关应该继承MechanismTrigger基类。下面这组脚本是按钮与门的最简实现，可直接放进预制体使用。

using UnityEngine; using UnityEngine.Events; public class MechanismTrigger : MonoBehaviour { // 子类触发此方法，由 GameManager 统一计数 public void ReportDone() { if (LevelStateManager.Instance != null) LevelStateManager.Instance.RegisterMechanismDone(); } }

using UnityEngine; using UnityEngine.Events; public class MechanismButton : MechanismTrigger { public enum ButtonColor { Red, Blue, Any } [SerializeField] private ButtonColor colorType = ButtonColor.Any; [SerializeField] private UnityEvent onPressed; [SerializeField] private UnityEvent onReleased; private int touchedCount; private void OnTriggerEnter2D(Collider2D other) { if (!CanInteract(other)) return; touchedCount++; if (touchedCount == 1) { onPressed?.Invoke(); ReportDone(); } } private void OnTriggerExit2D(Collider2D other) { if (!CanInteract(other)) return; touchedCount--; if (touchedCount == 0) onReleased?.Invoke(); } private bool CanInteract(Collider2D other) { // 按 Tag 判断角色颜色，比硬编码类名更稳 bool isRed = other.CompareTag("RedPlayer"); bool isBlue = other.CompareTag("BluePlayer"); if (!isRed && !isBlue) return false; if (colorType == ButtonColor.Red) return isRed; if (colorType == ButtonColor.Blue) return isBlue; return true; } }

这段脚本的核心是计数式触发：touchedCount保证按钮在双人同时踩上时不会重复触发，最后一个角色离开时才执行onReleased。CanInteract用 Tag 而不是类型判断，因为场景里的角色预制体可能挂多个脚本，Tag 判断更直接。ReportDone()只在按钮第一次被按下时上报，防止把关卡通关条件提前判真。onPressed和onReleased是 UnityEvent，在 Inspector 里把门的OpenDoor方法拖进去即可，门不需要知道按钮的存在。

using UnityEngine; using System.Collections; public class SlidingDoor : MonoBehaviour { [SerializeField] private Vector2 openOffset = new Vector2(0f, 2f); [SerializeField] private float moveTime = 0.4f; private Vector2 closedPos; private Coroutine moveRoutine; private void Awake() { closedPos = transform.position; } public void OpenDoor() { StopAndClear(); moveRoutine = StartCoroutine(MoveTo(closedPos + openOffset)); } public void CloseDoor() { StopAndClear(); moveRoutine = StartCoroutine(MoveTo(closedPos)); } private void StopAndClear() { if (moveRoutine != null) StopCoroutine(moveRoutine); } private IEnumerator MoveTo(Vector2 target) { float elapsed = 0f; Vector2 start = transform.position; while (elapsed < moveTime) { elapsed += Time.deltaTime; transform.position = Vector2.Lerp(start, target, elapsed / moveTime); yield return null; } transform.position = target; } }

注意MoveTo里用Time.deltaTime而不是Time.fixedDeltaTime，因为门的动画是表现层的，不需要参与物理步进；如果放在 FixedUpdate 里驱动，低帧率下门会一卡一卡。moveTime控制在 0.3～0.6 之间，太慢会拖解谜节奏。这里如果想让机关触发时带一点淡出效果，可以在协程里同步修改 SpriteRenderer 的 alpha，这就是「unity脚本控制逐渐消失」的常见做法；消失动画用协程做比 Animator 更轻量，适合按钮、收集物这类一次性机关。

4.3 岩浆、冰面和障碍物：Tile 层级的碰撞差异

森林冰火人里火人不能碰水、冰人不能碰岩浆，这种规则用两层碰撞体实现最干净。静态 Tilemap 只画可以站立的砖块；水、岩浆这类危险区域，单独用一个 Trigger Tilemap 画，给 Tilemap 挂Tilemap Collider 2D并勾选Is Trigger。角色走进触发区域，由角色身上的DangerZoneDetector判断死亡并回到最近检查点。

危险区域判定脚本不需要写复杂逻辑，在OnTriggerStay2D里按 Tag 检查角色，然后调用 GameManager 的Respawn即可。要注意 Trigger Tilemap 和实心 Tilemap 不能放在同一个 Tilemap 上，否则碰撞和触发两个属性会串，角色可能既站不稳又死不掉。把实心砖、水域、岩浆分成三个 Tilemap，是这类项目最常见的分层方式，看着目录多一点，调试省心很多。

4.4 检查点 Checkpoint 与重置逻辑：死一次别从头开始

迷宫解谜没有检查点会让人想砸键盘。检查点是场景里的一个 Trigger Box，角色进入后更新 GameManager 的出生点，并播放一个亮灯动画。复活时要把坐标向上偏移 0.5 格，防止角色刚好生成在砖块碰撞体内被顶出去，这 0.5 格的偏移看着小，却能省掉大量「复活卡墙」的排错时间。我一般会把检查点做成一个独立预制体，带一个 Sprite 切换状态（未激活灰、已激活亮），这样策划摆关卡时直接拖预制体就行。

5. 跑通森林冰火人迷宫项目的 5 个坑：碰撞穿透、相机抖动与重置翻车

这套项目技术跨度比较大，从 2D 物理到关卡重置都有容易翻车的地方。下面这五条是我在跑这类横板解谜源码时反复遇到的，每一条都按现象、原因、解决展开，可以直接当排查清单用。

5.1 碰撞相关：角色高速穿墙、冰面滑失控、按钮触发乱跳

现象：角色速度一快，就从砖块里穿出去，或者直接掉出地图。

原因：Rigidbody2D默认的碰撞检测模式是Discrete，它只检测每个物理帧结束时刚体是否穿透；角色单帧位移大于碰撞体厚度时，物理引擎会直接跳过碰撞。另外，移动代码如果直接改transform.position，刚体根本没参与运动，碰撞自然失效。

解决：把角色的Collision Detection改为Continuous，同时在ApplyMovement里对水平速度做一次Mathf.Clamp(newVelX, -moveSpeed * 1.2f, moveSpeed * 1.2f)兜底，避免给到异常大的速度。再确认地形挂的是静态碰撞体而不是 Dynamic 刚体，Dynamic 对高速物体会产生推挤而不是阻挡。

现象：角色走到冰面区域就一直滑停不住，按钮上站不稳。

原因：冰面 Tile 给碰撞体加了摩擦极低的物理材质，但角色移动是速度驱动的，物理材质里 friction 对速度驱动型刚体的影响非常有限，看起来就是「滑起来就刹不住」。

解决：不要指望靠改Physics Material 2D的 friction 解决，那会把别的地面手感一起改坏。更稳的做法是给冰面区域放一个静态触发器，角色进入后把acceleration临时降到 2、moveSpeed降到 4，离开后恢复。冰面在玩法上应该是一种「减速手感」，而不是「零摩擦滑冰」，这样解谜节奏才可控。

现象：红蓝角色同时踩到按钮，按钮反复触发，机关状态乱跳。

原因：按钮脚本只做了touchedCount加减，但两个角色交替进出时，Enter 和 Exit 的顺序可能倒挂，计数在 0/1/2 之间抖动，UnityEvent 被反复调用。

解决：把计数换成HashSet<Collider2D>，只有集合从空变非空时执行onPressed，从非空变空时才执行onReleased。这样不管几个角色进出，按钮只认「有没有人被压住」这一个状态。

5.2 表现与重置：相机跟随抖动、慢动作误伤 UI、重置后机关状态没还原

现象：相机跟随时抖动，尤其角色跳跃落地时画面晃。

原因：相机在 Update 里做 Lerp 平滑，但角色移动在 FixedUpdate 里发生，两者相位对不齐；如果相机直接transform.position = target.position，还会把角色微小的物理抖动放大到整个画面。

解决：手写相机跟随放在LateUpdate并做插值，或者直接用 Cinemachine 的Framing Transposer，把Dead Zone Width/Height设成 0.3 左右，角色在中心小范围内移动时相机不动，跳出台子才跟上。解谜关卡尤其适合这个配置，镜头稳定了，机关判定才看得清。

现象：想做个冰冻慢动作，调了Time.timeScale = 0.3，结果暂停菜单和 UI 动画也一起变慢，点击都不跟手。

原因：timeScale是全局的，不只是物理速度，UI 的 Animator、协程里的WaitForSeconds、按钮交互都吃这个缩放。解谜游戏里做局部减速，不该用全局 timeScale。

解决：只对需要减速的角色刚体做速度乘系数，或者用协程单独控制物理步进。要做慢动作就改角色脚本里的moveSpeed与jumpForce临时值，机关和 UI 完全不受影响。全局 timeScale 只应该用在这几个地方：真正的暂停、需要整体放慢的过场演出。

现象：角色死后点击重试，门是开的、按钮是亮着的，机关状态没还原。

原因：门、按钮等组件把状态存在实例字段里，重试时如果只是重新加载场景，场景里的静态单例又用了DontDestroyOnLoad，旧状态就会被带到新场景。

解决：给机关定义一个ResetOnRestart()方法，GameManager在重试时遍历场景所有机关组件，统一调用该方法把门关回原位、按钮灭灯、检查点保留。检查点记录和机关进度分开存，死亡只清机关进度，保留已解锁的检查点。这样才能做到「死了重来但不用从头打」。

6. 进阶玩法：把源码改成关卡配置化，二次开发省一半时间

如果你打算在这套源码上做自己的迷宫关卡，最值得投入的一件事，是把机关参数和关卡入口从代码里抽出来，做成配置。森林冰火人这种解谜玩法的核心变量就三类：角色参数、机关参数、关卡里的目标点。角色参数你已经有了，机关参数在MechanismButton和SlidingDoor上，但关卡一多，每次摆机关都要逐个拖引用，效率很低。更可维护的做法是定义一个LevelConfigScriptableObject，把每关的机关列表和角色出生参数集中管理。

6.1 用 LevelConfig 管机关和出生点

using UnityEngine; [CreateAssetMenu(fileName = "LevelConfig", menuName = "Levels/Level Config")] public class LevelConfig : ScriptableObject { [Header("角色出生参数")] public Vector2 startPoint; public float playerMoveSpeed = 6f; public float playerJumpForce = 11f; [Header("机关预制体")] public MechanismButton[] buttonPrefabs; public SlidingDoor[] doorPrefabs; }

配置化之后，新关卡只需要创建一个 LevelConfig 资产，把预制体拖进数组，场景里的机关只按 ID 读取配置，不再互相硬引用。这样改角色参数时不用开场景，改机关参数时不用翻预制体，两个角色的初始移动速度和跳跃力也能按关卡单独覆盖，比如冰面关把 moveSpeed 压到 4，岩桨关把 jumpForce 提到 12。

6.2 编辑器一键冒烟测试与分辨率适配

配置化以后最怕引用断掉，我一般会在编辑器里写一个冒烟测试菜单，一键加载全部 LevelConfig 资产并检查引用是否为空，这样摆关卡的人不用每次进 Play 模式就知道了。

using UnityEngine; using UnityEditor; public static class LevelConfigValidator { [MenuItem("Tools/Validate Level Configs")] public static void ValidateAll() { string[] guids = AssetDatabase.FindAssets("t:LevelConfig"); foreach (string guid in guids) { string path = AssetDatabase.GUIDToAssetPath(guid); LevelConfig config = AssetDatabase.LoadAssetAtPath<LevelConfig>(path); if (config == null || config.buttonPrefabs == null || config.doorPrefabs == null) { Debug.LogError("配置缺失: " + path); } } Debug.Log("校验完成"); } }

打包之前的最后一步，我会检查 UI 的分辨率适配。这类 2D 解谜游戏的 UI 通常用 Canvas Scaler 的Scale With Screen Size模式，参考分辨率设 1920×1080，匹配模式选Expand；这样在带鱼屏上不会裁切，在竖屏上也不会把按钮挤出屏幕。字体和小图标按最窄的 16:9 做，操作提示就不会在窄屏上重叠。

我以前拿到新源码总想着先改代码，最后发现先跑通原版、再抽配置、最后调参数，才是性价比最高的路径。这套迷宫解谜项目真正值钱的地方不在角色脚本，而在「解谜状态管理 + 机关触发 + 关卡配置」这条链路上，你把这三层理清，就能把自己的关卡源源不断加进去。希望帮到你。

本文还有配套的精品资源，点击获取