可运行合作烹饪Unity源码：交互状态机与订单系统拆解

简介：面向Unity初学者与课程设计需求者的《Overcooked》胡闹厨房项目源码，基于Unity引擎实现多人合作烹饪玩法，适合用来熟悉游戏框架、功能拆分与代码组织方式。项目来源于CodeMonkey教程学习实践，并在其基础上加入个人实现，可作为课程设计、大作业或自学练手参考，也便于在现有结构上继续修改扩展。压缩包共228个文件，约234.53MB，内容以dll、pdb、ress、assets及exe、json等为主，分别对应运行库、调试信息、资源与配置文件，另含讲解文档，便于理解项目构成与运行环境。目前已有339人学习。读者可获得较完整的合作玩法实现样例、场景与资源配置参考，以及按教程推进项目时的功能落地思路；对想了解Unity项目目录组织、脚本与资源配合、基础打包运行流程的初学者尤其有帮助，对课程展示与二次开发也较为友好。

1. 一套跑得起来的合作烹饪 Unity 源码，省下的是重写玩法的两周

多人合作烹饪玩法（也就是常说的「胡闹厨房」那一类）看着简单，真动手做才发现难点全埋在细节里：两个人抢同一口锅、切菜切到一半被拉走、订单超时该扣分还是直接判负、手柄拔了再插上还算不算同一个玩家。这套 Unity 源码把这些流程都写成了能跑的工程，包含角色移动与交互探测、工位状态机、配方资产、订单生成与结算、本地多人输入分配，适合拿它当玩法模板或二次开发底子。它面向的是已经会用 Unity、但不想从零搭交互和状态机骨架的人，也适合新手照着跑一遍，理解这类玩法内部的运转方式——当成一套可以直接参考的 Unity 软件与插件级工程来看，比自己攒预制体快得多。

2. 工程骨架拆解：四个程序集与一套交互接口怎么分工

这份源码的结构含有一段理解成本：它没有把所有脚本丢进默认程序集，而是按职责切成了几块。如果你上来就翻PlayerController找逻辑，很容易在各种GetComponent调用里绕不出来。正确的做法是先看目录和程序集依赖，再看交互入口，最后看关卡约定。按这个顺序读，半个下午就能把整条数据流画清楚。

2.1 目录与程序集：先把依赖方向定死

拿到工程先别打开脚本，先看 asmdef。这类项目最容易烂掉的地方，是所有逻辑都塞在默认程序集里：改一个工位脚本触发全量重编译，两个人同时改工位时冲突一片，最要命的是核心层反过来引用了 UI 层，导致连单元测试都没法跑。这套源码的目录大致长这样：

Assets/ ├── _Project/ │ ├── Art/ │ ├── Prefabs/ │ │ ├── Stations/ # 砧板、灶台、出餐口、垃圾桶等工位预制体 │ │ ├── Ingredients/ # 食材与半成品，命名规则：Raw_/Cut_/Cooked_ 前缀 │ │ └── Players/ │ ├── Scenes/ │ └── Scripts/ │ ├── Core/ # 游戏状态机、事件总线、时间管理 │ ├── Interaction/ # IInteractable 与交互探测 │ ├── Cooking/ # 工位状态机、配方资产 │ ├── Orders/ # 订单生成与结算 │ └── UI/ └── Plugins/

程序集之间的依赖是单向的，靠 asmdef 的 References 锁住，不允许反向引用：

这张表的实际价值在于：你加新功能时先问自己「它属于哪一格」。比如「糊锅时飘黑烟」是表现层，就该走事件总线让特效脚本去订阅，而不是在CookingStation里Instantiate一个粒子预制体——那样一旦预制体路径变了，玩法脚本就跟着编译失败。

另外注意_Project这个下划线前缀。它不是洁癖，是把项目资源和第三方插件在 Project 窗口里物理分开，升级插件时不容易误删。我一般还会把_Project/Scripts下的每个文件夹都配上同名 asmdef，让「改一行代码等十秒编译」变成「改一行代码等两秒」。

2.2 交互系统：一个 IInteractable 接口撑起整套玩法

整套玩法的入口只有一个接口。玩家不需要知道自己面前是砧板还是锅，只认IInteractable，这是这类工程最值得学的一点——工位越加越多，交互代码一行不改。

using UnityEngine; // 所有可交互物的统一入口：玩家只认这个接口，不认具体工位类型 public interface IInteractable { // 交互提示文本，UI 直接取用，避免每个工位各写一套提示逻辑 string GetPrompt(GameObject interactor); // 前置判断：手上没东西时不能往出餐口放盘子，这类规则都放这里 bool CanInteract(GameObject interactor); // 真正执行交互 void Interact(GameObject interactor); }

配合一个探测脚本，把「找最近的可交互物」和「按下按键」彻底分开：

using UnityEngine; public class InteractionSensor : MonoBehaviour { [SerializeField] private float radius = 0.9f; // 探测半径，约一个身位；大于 1.2 会隔墙交互 [SerializeField] private LayerMask interactLayer; // 只勾 Interactable 层，别用 Everything [SerializeField] private int maxHits = 8; // 重叠上限，缓冲区开小了会漏掉工位 private Collider[] _buffer; private IInteractable _current; public IInteractable Current => _current; private void Awake() { _buffer = new Collider[maxHits]; // 复用数组，避免每帧 OverlapSphere 产生 GC } private void Update() { int count = Physics.OverlapSphereNonAlloc(transform.position, radius, _buffer, interactLayer); _current = null; float best = float.MaxValue; for (int i = 0; i < count; i++) { var candidate = _buffer[i].GetComponentInParent<IInteractable>(); if (candidate == null || !candidate.CanInteract(gameObject)) continue; // 多个工位重叠时取最近的；不比较距离就会出现「站中间不知道在跟谁交互」 float sqr = (_buffer[i].transform.position - transform.position).sqrMagnitude; if (sqr < best) { best = sqr; _current = candidate; } } } }

参数上几个点值得单独说。radius是手感参数，不是物理参数：0.8 到 1.0 之间比较贴近「贴到工位才能操作」的直觉，超过 1.2 会出现隔着柜台触发的诡异体验。interactLayer一定要单独建层，因为OverlapSphere会命中角色自身的碰撞体，如果角色也在这一层，最近的永远是自己的脚。maxHits开 8 够用，但如果你把食材也做成可交互物，掉在地上的一堆食材会瞬间吃满缓冲区，建议食材单独一层、不进探测掩码。

GetComponentInParent而不是GetComponent，是因为工位预制体的碰撞体通常挂在子物体上，接口实现挂在根节点。这个细节决定了「把碰撞体塞进子物体」这类美术调整会不会把交互弄坏。

2.3 关卡与场景：Grid 布局与预制体约定

源码里的关卡是网格化的，一个格子的世界单位是 1，角色胶囊半径 0.4，工位占 1×1 或 1×2。这个约定不是美术偏好，是所有放置判定的地基：出餐口、灶台、砧板的位置全部按整数格对齐，玩家靠近时的位置吸附才有依据。

场景切换只发生在关卡开始和结算，中间不换场景，所以DontDestroyOnLoad在这套工程里几乎不用。这一点对排查问题很有帮助：一旦你在运行时看到某个对象被自动保留，八成是自己写错了，而不是框架行为。

3. 交互与烹饪状态机：切菜、下锅、装盘怎么串成一条链

骨架清楚之后，真正决定手感的是工位状态机。很多人第一版会用Update里堆一堆if (timer > x)，跑起来没错，但加上「切到一半被抢走」「煮好后没人取走会糊」这两条规则后，代码立刻变成一坨。这套源码用的是「手持物 + 容器 + 协程状态机」的组合，拆开看每一块都很小。

3.1 手持物与容器：把「拿」和「放」拆成两件事

CarrySlot只负责一件事：记录当前手上拿着什么，并处理挂点和物理开关。它不管这个东西是生菜还是盘子，那是IngredientStack自己的事。

using UnityEngine; public class CarrySlot : MonoBehaviour { [SerializeField] private Transform anchor; // 手部挂点，在预制体里调，不要写死坐标 [SerializeField] private float pickupRadius = 1.2f; public IngredientStack Current { get; private set; } public bool TryPickup(IngredientStack item) { if (Current != null || item == null) return false; Current = item; item.transform.SetParent(anchor, false); // false：保留本地坐标，避免父级缩放到食材上 item.transform.localPosition = Vector3.zero; item.SetPhysicsEnabled(false); // 手上的东西不该参与物理，否则会撞翻锅 return true; } public IngredientStack Release() { var item = Current; Current = null; if (item == null) return null; item.transform.SetParent(null, true); // true：保持世界坐标，放下时不跳位 item.SetPhysicsEnabled(true); return item; } }

SetParent第二个参数是最容易翻车的地方，记住一句话：拿起用false，放下用true。反过来写，拿起时食材会突然弹到一个奇怪的位置，放下时会原地陷进地板。SetPhysicsEnabled(false)里除了关 Collider，还要把Rigidbody.velocity和angularVelocity清零，否则食材在手上仍然带着之前的速度，放手瞬间会飞出去。

顺带说一个血泪经验：拿在手上的食材一定要换到一个不参与物理的层，否则玩家跑动时手上的盘子和灶台发生碰撞，锅会被顶飞。这套源码里专门有一个HeldItem层，只和玩家自身碰撞。

3.2 砧板与锅具：用协程写一个可中断的进度状态机

工位逻辑的核心是一个四态状态机：Idle、Working、Done、Burnt。用协程写进度，好处是中断和重新开始都很自然；坏处是协程的生命周期跟着 MonoBehaviour 走，场景一卸载就静默停掉——这一点后面排查章节会细说。

using System.Collections; using UnityEngine; public enum StationState { Idle, Working, Done, Burnt } public class CookingStation : MonoBehaviour, IInteractable { [SerializeField] private float processTime = 3f; // 切菜 3 秒 / 煮制 5 秒，每个工位单独配 [SerializeField] private float burnTime = 8f; // 完成后多久糊锅，<=0 表示永不糊 [SerializeField] private RecipeSO recipe; // 该工位接受的输入与产出规则 private StationState _state = StationState.Idle; private float _timer; private Coroutine _job; public bool CanInteract(GameObject interactor) => _state != StationState.Working; public string GetPrompt(GameObject interactor) => _state switch { StationState.Working => $"{Mathf.CeilToInt(processTime - _timer)}s", StationState.Done => "取出", _ => "放入" }; public void Interact(GameObject interactor) { var slot = interactor.GetComponent<CarrySlot>(); if (slot == null) return; switch (_state) { case StationState.Idle when slot.Current != null && recipe.Accepts(slot.Current): slot.Release(); // 原料进工位，先从手上摘掉，再启动计时 StartJob(); break; case StationState.Done: var output = recipe.CreateOutput(); if (slot.TryPickup(output)) { StopAllCoroutines(); // 取走时立刻停掉糊锅计时 _state = StationState.Idle; } break; } } private void StartJob() { if (_job != null) StopCoroutine(_job); // 重复触发时先停旧协程，否则两条计时并行 _job = StartCoroutine(JobRoutine()); } private IEnumerator JobRoutine() { _state = StationState.Working; _timer = 0f; while (_timer < processTime) { _timer += Time.deltaTime; // 用 deltaTime，手感才不受帧率影响 yield return null; } _state = StationState.Done; if (burnTime > 0f) StartCoroutine(BurnRoutine()); } private IEnumerator BurnRoutine() { yield return new WaitForSeconds(burnTime); if (_state == StationState.Done) _state = StationState.Burnt; // 已被取走就不该糊 } }

几个关键点。第一，Interact里对状态做了守卫，Working期间直接返回，这是防止「连按交互键把计时重置」的第一道闸。第二，TakeOutput之前先StopAllCoroutines，比在协程内部维护一个_cancelled标志干净得多。第三，BurnRoutine里必须再检查一次状态，因为WaitForSeconds期间玩家可能已经把成品取走了。

WaitForSeconds受Time.timeScale影响。如果这套工程之后要接暂停菜单，暂停时会把 timeScale 设为 0，糊锅计时也会一起停，这通常是想要的行为；但如果你希望糊锅走真实时间（比如结算界面还在跑），就得换成WaitForSecondsRealtime。这个选择在第一版就要定下来，中途改会导致暂停后秒糊的玄学现象。

3.3 参数怎么调：切菜时长、糊锅阈值与手感

源码把参数全放在 Inspector 上，但默认值只是能跑，不是好玩。下面这张表是我按三个关卡难度调下来比较稳的区间：

调参的顺序也有讲究：先定移速，再定切菜和煮制，最后定订单超时。因为订单超时的合理值等于「所有工序时间之和 × 1.5」，前面几个参数一动，这一项就得跟着重算。我一般会在OrderManager里加一行编辑器校验，超时时间低于配方总耗时就直接在 Console 报警告，省得每次手动核对。

4. 订单与计分：用 ScriptableObject 把配方变成可配置数据

配方、订单、计分是三件事，但它们的耦合点只有一个：配方资产。把配方做成ScriptableObject，策划改数值不用碰代码，这是这套工程里最实用的一处设计，也是最容易埋坑的一处。

4.1 配方资产的结构与字段设计

using UnityEngine; [CreateAssetMenu(menuName = "Kitchen/Recipe", fileName = "Recipe_New")] public class RecipeSO : ScriptableObject { public string recipeId; // 唯一 ID，订单引用与存档都用它，别用资产名 public Sprite icon; [Header("计分")] public float baseScore = 10f; // 基础分，实际得分再乘时间系数 public float timeLimit = 45f; // 该订单从下达到超时的秒数 [Header("流程")] public RecipeStep[] steps; // 步骤链：切 → 煮 → 装盘，工位按顺序校验 public IngredientSO[] inputs; // 允许的输入，用来放开「任意蔬菜」这类规则 public bool Accepts(IngredientStack item) { // 按当前步骤比对 ingredientId，不做类型强转，避免菜刀切盘子 return CurrentStep().Accepts(item); } public IngredientStack CreateOutput() => CurrentStep().CreateOutput(); private RecipeStep CurrentStep() => steps[0]; // 简化版：实际按工位记录的进度取 }

字段里有两点值得强调。recipeId必须是字符串常量而不是资产名，因为资产改名是常事，而 ID 一旦写进存档就固化下来。steps做成数组而不是单个枚举，是为了支持「先切后煮再装盘」这种多工序菜；如果只做单工序，直接砍掉这个数组，用两个字段就够了，别为了扩展性把简单逻辑复杂化。

ScriptableObject的数据在编辑器里是跨会话保留的。这条特性在编辑资产时是优点，在运行时就是坑：如果哪个脚本直接改了recipe.baseScore，你在 Play 模式下看到的数值会一直留在资产文件里，重启编辑器也不会恢复。稳妥的做法是运行时读出一个纯 C# 的RecipeRuntime结构体来用，资产只读不写。

4.2 订单生成器：权重、难度曲线与超时惩罚

订单生成最容易写得没手感：随机抽菜，结果连出三份一模一样的，玩家刚做完一份又来一份同样的，枯燥得要命。源码里做了两层控制，一层控制数量上限，一层控制抽取权重。

using System.Collections.Generic; using UnityEngine; public class OrderManager : MonoBehaviour { [SerializeField] private RecipeSO[] pool; [SerializeField] private AnimationCurve difficulty; // 横轴：关卡进度 0→1，纵轴：0→1 [SerializeField] private float levelDuration = 300f; // 一关 5 分钟 [SerializeField] private float spawnInterval = 12f; // 基础出单间隔 private readonly List<Order> _active = new(); private float _elapsed; private void Update() { _elapsed += Time.deltaTime; float progress = Mathf.Clamp01(_elapsed / levelDuration); // 同时在场的订单上限从 2 涨到 5，涨得太快玩家会直接放弃 int cap = Mathf.RoundToInt(Mathf.Lerp(2f, 5f, difficulty.Evaluate(progress))); if (_active.Count < cap && _spawnTimer <= 0f) { SpawnOne(); // 出单间隔随进度收紧，但保底 6 秒，否则后期一秒一单没法玩 _spawnTimer = Mathf.Max(6f, spawnInterval * (1f - 0.5f * progress)); } _spawnTimer -= Time.deltaTime; } private void SpawnOne() { // 权重 = 1 / (1 + 已出现次数)，已上桌的菜权重更低，避免连续重复 float total = 0f; var weights = new float[pool.Length]; for (int i = 0; i < pool.Length; i++) { int dup = _active.FindAll(o => o.Recipe == pool[i]).Count; weights[i] = 1f / (1 + dup); total += weights[i]; } float r = Random.value * total; for (int i = 0; i < pool.Length; i++) { r -= weights[i]; if (r <= 0f) { _active.Add(new Order(pool[i], _elapsed)); return; } } _active.Add(new Order(pool[^1], _elapsed)); // 浮点误差兜底，别让它返回空 } }

difficulty用AnimationCurve而不是硬编码，好处是难度曲线能在 Inspector 里拖着调，不用改一行代码。曲线前 30% 进度压平、后 40% 抬起来，是最接近「先教学后施压」的形状。spawnInterval随进度收紧的逻辑里那个 6 秒保底很关键——我第一次调的时候忘了写，后期直接刷出同时 5 单、每 3 秒一单，测试的同事玩了两分钟就退出去了。

4.3 计分与结算：小费、连击与失败判定

计分公式不复杂，但每一项都要有明确的意义，否则玩家看不懂为什么这单拿 40 分那单拿 12 分。源码里的算法是：总分 = 基础分 × 剩余时间系数 + 连击加成，剩余时间系数在 0.5 到 1.5 之间线性取值。

连击计数要在订单超时、上错菜、关卡结算三处统一重置，这三处只要漏一处，玩家就会发现「明明超时了连击还在涨」。结算时把上面每一项以明细行展示出来，比只给一个总分有用得多——玩家能从明细里学会怎么打高分，而不是靠猜。

5. 踩坑排查：这套源码最容易翻车的五个地方

工程能跑起来之后的第一个月，问题基本集中在两类：交互物理的时序问题，和 Unity 生命周期带来的数据问题。下面五条都是我在改这套源码时真实撞过的，按「现象 → 原因 → 解决」写，遇到同款可以直接对号入座。

5.1 交互与物理的三处硬伤

第一条：站在两个工位中间，交互提示疯狂闪烁，按一下触发两次。

• 现象：UI 上的提示文字每帧在「放入」和「取出」之间跳，偶尔一次交互同时进了两个工位。
• 原因：探测脚本里直接调了Interact，或者 UI 层读Current的同时又自己算了一遍最近工位；两个工位距离相等时，比较结果是随机的。
• 解决：探测只负责更新Current，执行交互由输入层在按键按下那一帧调一次Current.Interact()。距离相等时加一个稳定的次级排序键（比如GetInstanceID()），保证同一帧选中的永远是同一个。

第二条：食材从手上放下后穿过地板掉出场景。

• 现象：松手瞬间食材往下沉，几帧后消失，Console 报Rigidbody相关警告。
• 原因：Release里先开了 Collider 后设父级，中间那一帧物理系统已经用旧的世界坐标算了一次碰撞；另外还留在HeldItem层，层碰撞矩阵里和地板是忽略关系。
• 解决：先换层、再清零速度、最后设父级，三步顺序不能乱。代码里把这三步收进IngredientStack.OnReleased()一个方法，谁调用都不会漏步骤。

第三条：角色走路时轻微滑步，切菜动画播放时人会往前漂。

• 现象：动画播完人物位置比开始时偏了半米，跑起来像在冰面上。
• 原因：Animator勾了Apply Root Motion，同时位移又由CharacterController.Move控制，两套系统各推一次。
• 解决：关掉根运动，位移完全交给代码；如果确实需要动画位移，就在动画事件里给一个带时长的位移请求，由CharacterController统一执行。

5.2 生命周期与数据的两处暗坑

第四条：切场景后 UI 事件重复触发，第二次进关卡提示文字变两倍。

• 现象：重开一局，点一次按钮触发两次；再重开一次，触发三次。
• 原因：事件总线用的是静态Action，OnEnable里注册了，OnDisable里没退订。场景卸载不会自动清静态事件。
• 解决：注册和退订必须成对写在OnEnable和OnDisable里，不要写在Start和OnDestroy——后者在对象被禁用的场景下不会执行。更稳的做法是改用ScriptableObject做事件通道，它的生命周期跟着资产走，不会跨场景残留。

第五条：编辑器里调好的配方数值，跑一次游戏后全变了。

• 现象：Play 模式里一切正常，退出后资产文件的baseScore、timeLimit被改成了运行时的值。
• 原因：某个脚本为了「临时加快」直接改了RecipeSO实例的字段。ScriptableObject在编辑器里的修改是持久的。
• 解决：运行时统一用RecipeRuntime结构体承接，资产只在初始化时读一次。如果确实要改资产，加#if UNITY_EDITOR并用EditorUtility.SetDirty显式标记，让修改是「有意的」而不是静默发生的。

这五条里，前三条是时序问题，后两条是生命周期问题，两类问题的排查手法完全不同：时序问题靠加日志打时间戳，生命周期问题靠在OnEnable、OnDisable、OnDestroy三个点各打一条带对象名的日志，看谁先谁后。

6. 进阶收尾：双人同屏的设备绑定与一份验收清单

单机跑通之后，绝大多数人会立刻想加第二个玩家，这一步的坑集中在输入设备分配上。用新版 Input System 时，PlayerInput默认会自动配对设备，两个手柄同时插上时，谁先按谁被抢走，玩家一多就乱。

using UnityEngine; using UnityEngine.InputSystem; // 按设备显式分配玩家，避免两个手柄抢同一个 PlayerInput public class PlayerSpawner : MonoBehaviour { [SerializeField] private GameObject playerPrefab; [SerializeField] private Transform[] spawnPoints; public void SpawnFor(InputDevice device, int index) { var go = Instantiate(playerPrefab, spawnPoints[index].position, Quaternion.identity); var input = go.GetComponent<PlayerInput>(); input.SwitchCurrentControlScheme(device); // 显式指定设备，不靠自动配对 input.neverAutoSwitchControlSchemes = true; // 关键开关：不勾会被键鼠抢回去 } }

neverAutoSwitchControlSchemes是这段代码里唯一必须记住的参数。不设它，玩家一手握手柄一手碰键盘，角色控制权会在两个设备间来回跳，表现出来就是人物自己抽搐。设备热插拔则靠InputSystem.onDeviceChange事件重新分配，别在Update里轮询设备列表。

最后一关的验收我固定走这张表，少一项都不算完成：

从那以后我每接一套别人写的玩法源码，都先跑一遍这张验收表再动代码——先确认它原本是好的，再确认我改完之后它还是好的，比事后翻 diff 找问题省事太多。这套合作烹饪的 Unity 源码我本地一直留着一份当模板，新项目开局直接复制_Project目录，比从空场景搭交互和状态机快两周。你手上如果正好要做同类玩法，把工程下下来跑通一局，再对照上面几章改参数，比看十篇教程都实在。希望帮到你。

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