简介：这是基于Unity打造的森林冰火人迷宫冒险解谜游戏完整项目源码，采用C#编写，适合Unity开发者、独立游戏制作人以及休闲游戏爱好者学习借鉴。项目还原经典火男孩与水女孩的双人协作闯关玩法，玩家需要收集全部钻石才能通过迷宫，其中包含完整场景布局、角色动画状态机、物理材质、着色器和预制体，并已集成AppLovin Max与AdMob广告插件，支持Android与iOS双端发布，能帮助读者理解从核心玩法到广告变现的完整商业化流程。资源包共2000个文件，以C#脚本595个、meta文件1009个为主，另有118个asset资源、45个材质文件、43个Unity场景、32个Shader、29个Prefab以及动画、音频、贴图等类型，压缩包总大小约251MB，目录结构清晰。当前已有475人学习下载，对于想快速上手Unity2D解谜游戏开发、研究双角色协作机制或直接获取可发布源码的读者来说，是一份实用的完整项目资料。

1. Unity 森林冰火人迷宫源码拆解：能跑起来的双人冒险解谜框架

这份“Red Boy And Blue Girl 森林冰火人迷宫”的 Unity 冒险解谜源码，最打动我的不是画风，而是它把双人协作解谜里最常用的那套机制——冰火属性免疫、水位机关、推箱开门、检查点复活——全部用 C# 脚本串成了一个能直接 Play 的 Demo。拿到手可以做的不只是玩，而是拆开看每个脚本挂在哪个物体、图层怎么分、碰撞判定走的是 OnTrigger 还是 OnCollision，改几个公共参数就能调手感。适合想从头搭迷宫解谜的新手，也适合想快速验证双角色协作玩法原型的熟手。

2. 场景搭建与物理分层：Tilemap、碰撞体与 Layer 的设计顺序

很多朋友拿到这类源码第一件事就是点 Play，结果人物穿过墙壁、机关不响应、门开了关不上。问题不是脚本写错，而是场景层没分对。这套项目里 Tilemap 承担了大部分地图表现，但 Tilemap 的碰撞体组织方式直接决定后面脚本好不好写。

2.1 为什么用 Tilemap 铺迷宫，而不是散摆 Sprite

迷宫类关卡墙多、路窄、台阶密，如果用散装 Sprite 一个一个摆，几百个物体挂在场景里，查找和修改都痛苦。Tilemap 的核心优势是“格子即地图”，刷子一抹就能画出一面墙，选中瓦片就能替换，而且 Tilemap Collider 2D 会自动为相邻瓦片生成合并后的碰撞轮廓，运行时物理性能比挂几百个 Box Collider 好得多。

我一般会建三张 Tilemap：背景层、碰撞层、装饰层。背景层只负责显示地面花纹，不挂任何碰撞器；碰撞层才是真正的墙和平台；装饰层放花草、石头这类不影响移动的东西。打开这份工程时你会在 Hierarchy 里看到类似 Ground 的对象，那就是碰撞层，不要往里面塞压力板或门，原因后面避坑章会展开。

2.2 物理 Layer 划分与碰撞矩阵设置

双角色解谜最怕的是“冰人被火焰烫死、火人被冰面滑死”这种判定相互干扰。解决办法不是写一堆 if，而是先从物理层上把对象归类。我拿到这套源码后第一件事就是打开 Edit → Project Settings → Physics 2D，把 Layer 确认成下面这套结构。

Layer Collision Matrix 里的关键设置是：Player 与 Hazard 之间只勾选 Trigger 感应，不产生刚体碰撞；Hazard 与 Ground 不碰撞，避免水面、火焰被地面挤出奇怪的抖动；Box 与 Ground 要碰撞，这样箱子推不过墙才能成立。这一步不做，后面贴再多脚本都白搭。

2.3 Tilemap 碰撞体合并与层巡检脚本

具体到操作，我给这套工程配置 Ground 层时按这个顺序走：先创建 Tilemap 物体，加上 Tilemap Collider 2D，再挂 Composite Collider 2D，并在 Tilemap Collider 2D 上勾选 Used By Composite。注意 Tilemap 的刚体类型要设成 Static，否则运行时整个地图会被物理引擎当成活动物体参与模拟，出现地图轻微飘移的玄学现象。

层关系混乱是这类项目最常见的翻车点，我习惯在场景里挂一个巡检脚本，每次调整图层时自动报警：

using UnityEngine; using UnityEngine.Tilemaps; public class TilemapLayerChecker : MonoBehaviour { public string expectedLayerName = "Ground"; void OnValidate() { Tilemap[] maps = GetComponentsInChildren<Tilemap>(); foreach (Tilemap map in maps) { if (map.gameObject.layer != LayerMask.NameToLayer(expectedLayerName)) { Debug.LogWarning($"瓦片地图 {map.name} 的 Layer 不是 {expectedLayerName}，请检查碰撞矩阵"); } } } }

这段脚本利用了编辑器方法 OnValidate，只要挂载它的物体在 Inspector 上发生改变就会自动执行。逻辑很直白：遍历场景中所有 Tilemap，逐个比对 LayerMask 是否与期望层相同，发现不一致就输出警告。参数 expectedLayerName 必须填 Layer 设置里的真实名字，比如 Ground，不能填中文或带空格的名字。实际使用中我会把它的触发范围限定在编辑模式，不参与运行时逻辑，所以放没放在激活物体上都无所谓。

2.4 迷宫地图的三种表示方式对比

做迷宫关卡前先想清楚地图数据怎么存。Tilemap 适合手工精修关卡，二维数组适合程序化随机生成，NavMesh 适合敌人寻路。这个项目是固定迷宫解谜，验证过又不涉及 AI 寻路，所以我最终只保留 Tilemap 方案。如果你要在这个源码上扩展随机迷宫，再引入二维数组和运行时刷 Tile 的方法。做这种选型时不要贪多，迷宫解谜的核心是可编辑性和可调性，Tilemap 在编辑器里所见即所得，调试效率最高。

3. 双角色控制与属性免疫：移动、切换与伤害判定脚本

场景层搞定了，接下来是这套源码最值得抄的部分：双角色控制。冰人和火人除了外观不同，物理手感也有差异。火人踩冰面会打滑，冰人走冰面很稳，这是我拿到项目后第一个确认的细节，很多仿作把两个角色做成同一套参数，游戏性会差很多。

3.1 移动脚本：用 Rigidbody2D 处理速度而非位置

我给角色用的是 Rigidbody2D 加速度驱动，而不是直接改 transform.position。直接改位置的问题是角色会穿透 Tilemap 碰撞体，而刚体移动能保证物理反馈正常，例如跳到箱子上被箱子带着走。

using UnityEngine; public class PlayerMovement : MonoBehaviour { public float moveSpeed = 6f; public float jumpForce = 12f; public bool canControl = true; private Rigidbody2D rb; private Collider2D col; void Awake() { rb = GetComponent<Rigidbody2D>(); col = GetComponent<Collider2D>(); } void FixedUpdate() { if (!canControl) return; float horizontal = Input.GetAxisRaw("Horizontal"); rb.velocity = new Vector2(horizontal * moveSpeed, rb.velocity.y); if ((Input.GetKeyDown(KeyCode.Space) || Input.GetKeyDown(KeyCode.UpArrow)) && IsGrounded()) { rb.velocity = new Vector2(rb.velocity.x, jumpForce); } } bool IsGrounded() { Bounds bounds = col.bounds; Vector2 origin = new Vector2(bounds.center.x, bounds.min.y); float distance = 0.05f; return Physics2D.OverlapCircle(origin, distance, LayerMask.GetMask("Ground")) != null; } }

这段脚本里我做了三个对新手友好的决定。第一，物理相关逻辑全部放到 FixedUpdate，保证不同帧率下手感一致。第二，水平输入用 GetAxisRaw 而不是 GetAxis，因为后者带平滑过渡，在需要精确落点的解谜游戏里会让人觉得角色“飘”。第三，跳跃检测用脚下的小圆 OverlapCircle，而不是从角色中心发射射线，这样在台阶边缘起跳更宽容。

moveSpeed 和 jumpForce 是调节手感的关键参数。moveSpeed 6 适合普通平台，如果做冰面关卡可以给火人降到 4；jumpForce 12 对应重力默认值，跳两格高的墙基本够用，想跳三格就调到 14 到 15。IsGrounded 里的 distance 不要大于 0.1，否则角色还没落地就被判定为可跳跃，出现空中二段跳的 bug。

3.2 角色切换与属性定义

双角色解谜必须有随时切换的入口。我用一个枚举定义属性，挂在每个角色身上，这样后续伤害判定不需要大量比较字符串或标签。

public enum CharacterType { Fire, Ice } public class PlayerStats : MonoBehaviour { public CharacterType characterType; public Transform respawnPoint; public void Die(Transform fallbackPoint) { transform.position = respawnPoint != null ? respawnPoint.position : fallbackPoint.position; // 复位速度，防止复活后继续滑动 Rigidbody2D rb = GetComponent<Rigidbody2D>(); if (rb != null) rb.velocity = Vector2.zero; } }

respawnPoint 默认取关卡检查点，Die 方法里顺手把速度清零，这是很多半成品项目遗漏的地方。角色死亡后如果不清速度，刚体会保留死亡瞬间的动量，复活瞬间人会飞出去一段距离，看起来像踩了传送带。

切换脚本就简单了，核心是开关两个角色并加切换冷却。冷却时间如果为 0，键盘按一下会同时触发多次换人逻辑，所以我在 Update 里用时间戳限制频率：

using UnityEngine; public class CharacterSwitch : MonoBehaviour { public GameObject firePlayer; public GameObject icePlayer; public float switchCooldown = 0.2f; private float lastSwitchTime; void Update() { if (Input.GetKeyDown(KeyCode.Q) || Input.GetKeyDown(KeyCode.Tab)) { if (Time.time - lastSwitchTime < switchCooldown) return; lastSwitchTime = Time.time; bool fireActive = firePlayer.activeSelf; firePlayer.SetActive(!fireActive); icePlayer.SetActive(fireActive); } } }

switchCooldown 我设在 0.2 秒，既过滤重复按键，又不会让玩家觉得切换卡手。注意 SetActive 切换时如果角色身上有协程，会被一并打断，所以切人同时要处理的技能冷却建议放到一个不随物体失活而销毁的 Manager 上，而不是挂在角色子物体下。

3.3 伤害判定：OnTriggerStay 比 OnTriggerEnter 更适合持续区域

火焰、冰面、水池都是持续伤害区域，进入后如果不出来，应该一直掉血或直接死亡。用 OnTriggerEnter 的话，角色在区域内待着只会触发一次，所以这套项目里我建议统一用 OnTriggerStay2D。

public enum HazardType { Fire, IceFloor, Water, Lava } public class HazardDamage : MonoBehaviour { public HazardType hazardType; public Transform fallbackRespawnPoint; void OnTriggerStay2D(Collider2D other) { PlayerStats stats = other.GetComponent<PlayerStats>(); if (stats == null) return; bool isFire = stats.characterType == CharacterType.Fire; bool isIce = stats.characterType == CharacterType.Ice; bool shouldDie = hazardType == HazardType.Water; if (hazardType == HazardType.Fire && isIce) shouldDie = true; if (hazardType == HazardType.IceFloor && isFire) shouldDie = true; if (hazardType == HazardType.Lava && isIce) shouldDie = true; if (shouldDie) { stats.Die(fallbackRespawnPoint); } } }

这里判定逻辑是：水对冰人和火人都致命，火焰只伤害冰人，冰面只伤害火人，岩浆只伤害冰人。每个角色身上必须挂着 PlayerStats，并且 Collider 的 IsTrigger 要勾上。如果发现角色完全不受伤，第一反应是查看 Hazard 物体的 Collider 是否被其他更大碰撞体盖住，而不是先怀疑脚本逻辑。

3.4 关于“Unity 物体速度怎么获取”的补充

做滑动冰面或传送带时，很多人会问物体当前速度怎么拿。最直接的方式是读 Rigidbody2D.velocity，返回的是 Vector2，x 代表水平速度，y 代表垂直速度。上面移动脚本里我用到的正是这个属性。要注意的是，FixedUpdate 里修改 velocity 后，Update 里立刻读取可能拿到上一物理帧的值，所以展示速度给玩家时，我一般放在 FixedUpdate 里更新 UI，避免数字一卡一卡。

4. 迷宫机关与关卡配置：推箱、压力板与 Json 化关卡数据

解谜游戏的灵魂在于机关组合。这套源码里最常见的机关是压力板开门、推箱子堵路、水位升降。把这些机制数据化，比一个一个在 Inspector 里拖引用更利于关卡迭代。

4.1 压力板与门联动：统计数量而不是开关类型

压力板常见误区是“角色踩上就开门，走开就关门”。如果门需要两个角色同时踩或者一个角色加一个箱子才能打开，单纯用 bool 就失效了。我采用计数方式：

public class PressurePlate : MonoBehaviour { public DoorController targetDoor; public int requiredWeight = 1; private int currentCount = 0; void OnTriggerEnter2D(Collider2D other) { if (other.CompareTag("Player") || other.CompareTag("Box")) { currentCount++; CheckWeight(); } } void OnTriggerExit2D(Collider2D other) { if (other.CompareTag("Player") || other.CompareTag("Box")) { currentCount = Mathf.Max(0, currentCount - 1); CheckWeight(); } } void CheckWeight() { if (currentCount >= requiredWeight) targetDoor.Open(); else targetDoor.Close(); } }

requiredWeight 写成 1 时就是普通压力板，写成 2 时冰人火人同时站上去门才开。这个设计的好处是，新关卡想加“箱子压板”谜题，不需要改脚本，只要把箱子 Tag 设为 Box。DoorController 的开门动画我一般用一个协程做逐渐淡出或上移，不要瞬间消失，玩家才能看懂机关生效了。

4.2 推箱子：物理驱动加前方检测

推箱子项目里常遇到的问题有两个：角色推不动箱子，或者箱子被推时疯狂抖动。抖动的原因是直接把箱子 transform.position 往推的方向加，而箱子本身还有刚体，两者互相打架。我建议让箱子也走刚体逻辑：

public class PushBox : MonoBehaviour { public float pushSpeed = 5f; private void OnCollisionStay2D(Collision2D collision) { PlayerMovement player = collision.collider.GetComponent<PlayerMovement>(); if (player == null) return; Vector2 pushDirection = collision.GetContact(0).normal; transform.position += (Vector3)pushDirection * pushSpeed * Time.deltaTime; } }

这段脚本不是完美的物理模拟，但足够让箱子跟着角色走。实际项目中我会再给箱子加上前方检测，判断推的方向有没有 Ground，防止箱子被推进墙里。常见做法是放一个小的 OverlapBox 在箱子前进方向的前缘，如果检测到墙壁，本次推动忽略。箱子刚体的 Interpolate 建议打开，Interpolate 选项会平滑渲染位置，避免看起来一顿一顿。

4.3 关卡出生点与机关数据交给 Json

当迷宫关卡多起来，每个关卡出生点、水位速度、机关类型都不一样，全塞到预制体里维护成本很高。我把关卡参数拆成 Json 文件，挂在关卡根节点上，运行时读取并覆盖默认值：

{ "levelName": "forest_01", "spawnPoint": { "x": -6.0f, "y": -2.0f }, "hazards": [ { "type": "water", "position": { "x": 10.0f, "y": -4.0f } } ], "goalRule": "pressurePlateAndBox" }

读取端用 JsonUtility 就能解析：

[System.Serializable] public class LevelConfig { public string levelName; public Vector2 spawnPoint; public string goalRule; } public class LevelConfigLoader : MonoBehaviour { public TextAsset configFile; public GameObject firePlayer; public GameObject icePlayer; void Start() { LevelConfig config = JsonUtility.FromJson<LevelConfig>(configFile.text); firePlayer.transform.position = config.spawnPoint; icePlayer.transform.position = config.spawnPoint; } }

JsonUtility 对 Vector2 的支持可以直接用，不用自己拆 x、y。如果后续关卡配置变得更复杂，比如嵌套数组或多层条件，我建议直接换 Newtonsoft.Json，它的 JObject 处理动态配置比 JsonUtility 顺手得多，尤其是做“匹配配置”这类需求时，按规则过滤数据更灵活。这套项目目前用 JsonUtility 足够，少引一个库也少一点打包体积。

4.4 水位机关：用 PingPong 控制涨落节奏

森林冰火人里水位场景很多，关键是让水面周期涨落，逼玩家抓时机跳跃。我给水位对象写了一个简单周期运动：

public class WaterLevelRise : MonoBehaviour { public float riseSpeed = 0.5f; public float maxHeight = 1f; private Vector3 startPos; void Start() { startPos = transform.position; } void Update() { float t = Mathf.PingPong(Time.time * riseSpeed, 1f); transform.position = startPos + Vector3.up * (t * maxHeight); } }

riseSpeed 控制水位变化快慢，maxHeight 控制最高水位。PingPong 的好处是不用手动判断涨到顶还是落到底，它会在 0 到 1 之间来回折返，天然形成完整周期。水位碰撞体是一直存在的，不要去开关 Collider，因为 OnTriggerStay 要求碰撞体始终有效，一旦关掉再打开，角色在水里那一帧会判定失败，出现“人站在水里不掉血”的怪异现象。

5. 避坑排查：编译报错、碰撞错乱与内存问题的现场记录

这套项目我前后跑过三遍，每一遍都踩到不一样的坑。下面五条是最有代表性的，全部按“现象 → 原因 → 解决”记录，你复现时遇到同款问题可以直接照抄。

5.1 冰人走进水池不触发死亡

现象：水池和角色 Collider 都设置了触发，Ice Player 走进水区域没有任何反应，代码断点也没进。

原因：水池的 Collider 设置成了 OnTriggerEnter，但角色是跳入水中的，第一帧接触时物理引擎还没稳定计算接触点，导致 Enter 没有被可靠触发。

解决：把伤害判定统一改成 OnTriggerStay2D，同时确认水池物体的 Rigidbody2D 类型为 Static。Static 刚体不参与物理计算，只提供静态碰撞数据，这是 Trigger 区域最稳定的配置。看到角色在水里不掉血，先检查是不是用了 Enter，再检查碰撞矩阵里 Player 和 Hazard 是否勾了触发感应。

5.2 火焰伤害把冰人和火人都烧死了

现象：Fire 区域对两个人都会造成伤害，火人靠近也一样死亡。

原因：HazardDamage 里的判定条件写反了，把 isFire 当成应受伤害的角色，实际上火人应该免疫火焰。

解决：回到 3.3 的脚本，确认逻辑是hazardType == HazardType.Fire && isIce才触发死亡。排查这类问题最快的方式是在 OnTriggerStay 开头加一句Debug.Log($"{other.name} 进入 {hazardType}，类型 {stats.characterType}")，把每个进入区域的角色属性打出来。日志能直接告诉你判定走的是哪条分支，比肉眼盯代码快。

5.3 推箱子时角色连同箱子一起穿墙

现象：把箱子推到墙边时，箱子卡进 Tilemap 里，角色也能跟着挤进去，再走两步整个人掉出地图。

原因：箱子推到位移用 transform.position 直接改，没有做前方碰撞检测。箱子被推时撞到墙，物理引擎还没响应，transform 已经把箱子带到墙体内。

解决：先给箱子加 Rigidbody2D 并把 Interpolate 设为 Interpolate，箱子移动走刚体；再在 PushBox 里增加前方 OverlapBox 检测，检测到 Ground 就中断推动。简单说就是“推动前先问路”。这类问题还有一个隐形诱因，就是箱子所在的 Layer 和 Ground 在碰撞矩阵里没勾，导致墙壁挡不住箱子。

5.4 Tilemap 合并碰撞后压力板触发区错位

现象：给 Tilemap 挂了 Composite Collider 后，原本摆在地图上的压力板触发区域变得很大，甚至覆盖整面墙，角色离老远就触发了开门。

原因：压力板被当成子物体放进了 Tilemap 层级里，Composite Collider 会把子物体的 Collider 一并合并，导致压力板自己的 Trigger 和墙壁碰撞体合并成一个整体。

解决：压力板、门这类机关物体绝对不能放在有 Composite Collider 的 Tilemap 子物体下，要单独建一层 Interactable 层级，与 Tilemap 平级。这是新手最容易踩的层结构坑，记住一条规则：Tilemap 只放地图瓦片，所有带独立逻辑的机关都必须离开 Tilemap 层级。

5.5 粒子特效循环导致内存持续上升

现象：关卡跑十分钟后内存占用慢慢涨，火焰特效数量肉眼可见地越来越多，最后卡顿。

原因：火焰粒子挂在角色或火把上后，粒子系统的 Loop 没有关闭，而且没有在任何时机调用 Stop。特效生成后一直循环，材质实例一直在内存里，Unity 不会自动清理还在播放的粒子。

解决：给所有循环特效加一个生命周期管理，用对象池回收。具体做法在下一章展开，核心思想是特效结束播放时立刻Stop(true, ParticleSystemStopBehavior.StopEmittingAndClear)，StopEmittingAndClear 会立即停止发射并清空已经生成的粒子，比单纯 SetActive(false) 释放得干净。

6. 进阶落地：对象池、Json 存档与时间缩放的边界处理

这章不是额外功能堆砌，而是把前面几章遗留的问题一次性解决。对象池解决粒子内存，Json 存档解决切人后机关状态丢失，Time.timeScale 解决暂停菜单对物理的影响。

6.1 对象池回收火把与水花特效

火焰、水花这类高频生成又立即消失的特效，最适合对象池。先预生成一批实例，用的时候激活，用完失活，避免运行时反复 Instantiate 和 Destroy 造成 GC 压力：

public class SimpleObjectPool : MonoBehaviour { public GameObject prefab; public int poolSize = 20; private List<GameObject> pool = new List<GameObject>(); void Start() { for (int i = 0; i < poolSize; i++) { GameObject go = Instantiate(prefab); go.SetActive(false); pool.Add(go); } } public GameObject Get() { foreach (var go in pool) { if (!go.activeSelf) { go.SetActive(true); return go; } } return null; } public void Return(GameObject go) { go.SetActive(false); } }

poolSize 建议设成关卡内可能同时出现的最大特效数，比如 20。Get 方法负责从池子里找一个空闲对象，如果没有空闲就返回 null，调用方自行决定要不要临时再生成一个。Return 方法只做失活，不做 Destroy。用这种池子后，粒子内存泄漏就不会再出现，因为特效实例数量被池子上限锁死了。

6.2 检查点与机关状态存进 Json

切人导致机关状态丢失，本质是没有持久化。我习惯在每个检查点把当前已开门列表、已收集钥匙、角色位置写进 Json，存到 PlayerPrefs 字符串里。读取时反序列化，恢复现场。代码结构上与第 4 章的 LevelConfig 类似，区别是存档里多了一个动态状态列表。写入用 PlayerPrefs.SetString，读取用 PlayerPrefs.GetString，简单直接，不引入存档库。存档时机不要放在 Update，放检查点触发和过关那一刻就够了，频繁写会磨损存储而且没必要。

6.3 暂停与过场：Time.timeScale 的边界

做暂停菜单时最容易犯的错是只把时间缩放设成 0，然后 UI 动画也停了。Time.timeScale = 0 会影响所有基于 Time.deltaTime 的逻辑，包括 FixedUpdate 里的刚体模拟。正确做法是 UI 动画用 Time.unscaledDeltaTime，粒子暂停用 ParticleSystem 的 Pause：

public void SetPause(bool pause) { Time.timeScale = pause ? 0f : 1f; }

注意暂停时如果 UI 动画要播放，相关代码必须使用 unscaledDeltaTime。倒计时这类需求也别用 timeScale 驱动，用一个单独变量记录剩余时间，每帧手动减去 Time.unscaledDeltaTime。从那以后我每次给新关卡加暂停逻辑，都会先把时间缩放的那行检查一遍，确认哪些逻辑依赖缩放时间、哪些依赖真实时间，再决定要不要动 Time.timeScale。这套源码适合先跑通再改，如果你照着文中步骤复现，记得从第 5 章的五个坑开始验证，剩下的基本都是手感调参问题，改 moveSpeed 和 jumpForce 就能找到你要的效果。希望帮到你。

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