胡闹厨房：四人合作烹饪联机游戏

这是 v0.1.0：主体玩法能完整跑完一局，但出生点重叠的 bug 还没修（第六节写了原因和修复方向）。 写作纪律和站点其他案例一致：没有实测数据就不写结论，没测的地方标「待补」。

一、一页速览

二、背景：为什么选这个题材

单机 Demo 练的是「逻辑写对」，联机 Demo 练的是「状态在谁的机器上算数」。做饭类玩法恰好是后者的压力测试：一局里同时存在共享状态（锅里的东西、盘子里的组合、订单进度）和独占状态（手里拿着什么、站在哪），任何一处权威划错，表现都是「物品凭空出现或消失」这种最难查的 bug。

所以目标从一开始就不是玩法量，而是把一条多人链路完整走通一遍，并且明确写下每一处取舍的代价。v0.1.0 的验收定义只有一句话：4 个人在同一个局域网里，从主菜单一路玩到结算，中间不掉线、不出现物品错乱。

三、我的职责

• 定权威边界：先决定「位置」和「交互」分别归谁算，再写任何一行网络代码。这条决定影响后面所有实现，改的成本最高。
• 拆玩法为数据：食材、配方、加工转换规则做成 ScriptableObject，新增一个菜品只加资产、不改代码。
• 管网络对象生命周期：所有「拿起 / 放下 / 销毁」都走服务端，客户端只发请求，用 NetworkObjectReference 定位目标。
• 守边界用例：满员再连、游戏中途加入、玩家掉线时手里有东西、Host 踢人，这几个场景每次改完都要复跑一遍。
• 写文档与自测流程：README 里固化了 LFS、编辑器版本、ParrelSync 多开步骤——换台机器能一把跑起来，才算这个项目是可交付的。

四、技术选择与理由

最容易被忽略的是前两行的配合关系：移动给了客户端，交互就必须全部收回服务端。如果两边都想「顺手」，就会出现客户端认为自己拿到了菜、服务端认为容器台还空着，然后两边各自渲染一个——这类不一致不会报错，只会让玩家觉得「游戏在抽风」。

五、结构：两条权威边界

场景是一条直线，状态都挂在常驻的 KitchenGameMultiplayer 上：

1

MainMenuScene → LobbyScene → CharacterSelectScene → GameScene

• KitchenGameMultiplayer（DontDestroyOnLoad）持有 NetworkList<PlayerData>：谁在线、叫什么、什么颜色。列表变了就抛事件，UI 各层各自订阅。
• Player 只在自己是 Owner 时跑 Update（移动 + 交互射线），别人的移动靠 ClientNetworkTransform 同步过来。
• 各类操作台（容器台、切菜台、灶台、盘子台、配送台、垃圾桶）都继承 BaseCounter，各自持有「上面放了什么」，状态只允许服务端改。

移动侧只需要一行声明，把权威交出去：

1
2
3
4
5
6
7
8

[DisallowMultipleComponent]
public class ClientNetworkTransform : NetworkTransform
{
    protected override bool OnIsServerAuthoritative()
    {
        return false; // Owner 客户端写位置，服务端只做转发
    }
}

交互侧反过来，客户端只发意图，服务端校验后再改状态：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

[ServerRpc(RequireOwnership = false)]
private void SpawnKitchenObjectServerRpc(int kitchenObjectSOIndex,
    NetworkObjectReference parentReference)
{
    KitchenObjectSO so = GetKitchenObjectSOFromIndex(kitchenObjectSOIndex);
    if (so == null) return;                                   // 索引非法：静默丢弃

    if (!parentReference.TryGet(out NetworkObject parent)) return;  // 对象已销毁
    if (!parent.TryGetComponent(out IKitchenObjectParent holder)) return;
    if (holder.HasKitchenObject()) return;                     // 慢一步的请求，输给先到的

    var spawned = Instantiate(so.prefab);
    spawned.GetComponent<NetworkObject>().Spawn(true);          // 服务端生成，客户端跟随
    spawned.GetComponent<KitchenObject>().SetKitchenObjectParent(holder);
}

这几处 return 不是防御性编程的装饰。并发请求下「父对象已经被别人占了」「目标在我解析前就被销毁了」都是正常时序，不是异常——早期版本把它们当成不该发生的情况，结果就是一个空引用把连接打断。

六、验证结果

已知问题：出生点按 ClientId 取，而不是按槽位

1
2
3
4
5
6
7

// Player.OnNetworkSpawn()  ——  v0.1.0 的实际代码
int spawnIndex = (int)OwnerClientId;
if (spawnIndex >= spawnPoints.Count)
{
    spawnIndex = spawnPoints.Count - 1;   // 超出范围就固定到最后一个点
}
transform.position = spawnPoints[spawnIndex];

OwnerClientId 是网络层分配的递增 ID，踢人之后不会复用。四人开满时是 0~3；踢掉 2 号再进来一个新人，新人拿到 4，4 >= 4 命中 clamp，于是和还在 3 号点的人叠在一起：

修复方向有两条，我倾向第二条：

1. 用 playerDataNetworkList 里的槽位索引（0~3）代替 OwnerClientId——改动最小，但服务端和客户端的列表顺序必须严格一致。
2. 由服务端在生成玩家时决定出生点并下发给该客户端——顺带解决一个更隐蔽的问题：OnNetworkSpawn 里设的 transform.position 会被客户端的 ClientNetworkTransform 覆盖，谁先执行决定了玩家最终站在哪。

七、复盘

• 网络 ID 不是业务索引。 出生点 bug 的本质是把 ClientId 当成「第几个玩家」用了。凡是「按编号索引资源」的地方，都要问一句：这个编号会不会跳、会不会重复、会不会被回收。
• 权威边界要一次划完，不能局部妥协。 移动给客户端是为了手感，代价是位置不可信。这个代价本身可以接受，但它连带规定了一件事：计分和订单判定必须只看服务端状态，否则整套作弊防线就是空的。
• 并发下的「正常时序」比异常更值得防。 DestroyKitchenObjectServerRpc 里那句「对象已经销毁就直接返回」的注释是拿一次空引用崩溃换来的。联机代码里，请求到达时世界已经变了是常态。
• 还有一处同类隐患没修：GetPlayerDataIndexFromClientId 找不到时返回 -1，而 SetPlayerNameServerRpc 直接拿它索引列表。断线和新玩家同步的时序撞上就会越界，属于「概率低但一定会发生」的一类。
• 静态事件记得反注册：Player 的静态事件目前只重置了一个（RestStaticData，名字还拼错了），场景重载后旧订阅者会继续被调用。
• 仓库卫生也是交付的一部分：根目录误提交了一个 37 KB 的 stdout 日志文件，README 里的 clone 地址还是旧账号名。这类小事不影响运行，但会让第一次来的人克隆失败。

八、相关文章

• Unity 多人联网：Mirror 与 NGO：两款框架的对比，NGO 的 NetworkObject / Rpc 概念在这里展开过
• Unity 客户端基础小框架：单机侧的同款取舍——哪些能力该收进骨架