19. Game World，让规则跑起来
VRChat 世界排行榜上常年居前的那一批里，有相当一部分是 Game World：Murder 4（jar 制作，2020 年 12 月发布的多人推理 / 反制游戏，杀手拿左轮、平民找子弹反杀，在多个排名站长期霸榜）、Prison Escape（监狱越狱）、Battle Discs（飞盘对战），还有数不清的躲猫猫、Among Us 仿作、Splatoon 仿作、Speedrun 训练场。它们的共同点是有规则、有目标、有胜负，玩家进来是为了「玩一局」。
这一章不教任何具体游戏机制。把 Game World 这一类世界单独拎出来看：核心体验是什么、玩家进门时在期待什么、设计上最容易翻车的几堵墙、要走这条路前面学过的工具里哪几件得先做扎实、哪几样以后必须啃的硬骨头。
这类世界的核心是「规则跑得起来」
Section titled “这类世界的核心是「规则跑得起来」”Game World 的评价标准跟 Chill World 几乎反过来。Chill 世界拿「待得住吗」打分，Game World 拿「能跑完一局吗」打分。
跑完一局这件事的隐含要求其实很硬核：
- 状态在所有玩家间一致。我看到的得分是 5:3，朋友那边也得是 5:3。不是 5:3 vs 4:3 vs 5:2 三个版本各跑各的。
- 回合从开始走到结束。比赛能开始、能进行、能结束。中途有人掉线不能让整局卡住，结束后还能重开新一局。
- 胜负能被判定出来。不是「打完之后大家凭印象算分」，得有一个权威的计分器。
- 新进来的玩家能接上。半路加入的人不能让整个游戏世界混乱。
- 规则得让人五分钟内学会。VRChat 不是 Steam 上专心打的游戏，玩家中途来去频繁，规则越简单越能跑得起来。
这五件事每一件都比 Chill 世界的「调好光」难得多。它们绑在一个东西上：网络同步。VRChat 的网络模型默认每个客户端各跑各的，要让规则跑得起来，必须主动让所有人看到同一个状态。
玩家走进来在期待什么
Section titled “玩家走进来在期待什么”Game World 玩家的期待很具体：
- 马上能玩。从进世界到能开始第一局，最好不超过 60 秒。这意味着规则要简单，开始流程要短，不能让玩家在大厅里站着等十分钟。
- 能跟陌生人凑一局。VRChat 里 Game World 大半时候是跟刚认识的玩家一起玩的。这意味着规则要能从零讲清，分工不能假设大家有默契。
- 看得清现在状态。比分、剩余时间、自己的角色 / 武器 / 任务，得有清晰的 UI 反馈。
- 赢了或输了得有个交代。胜利结算画面、失败提示、谁是第一名，这些东西不写好玩家不知道发生了什么。
- 下一局要能很快开始。打完一局之后切到下一局，间隔最好不超过 30 秒。等待时间长玩家就退了。
这些期待背后是同一种心情：玩家来这里是为了「玩一局完整的游戏」。中间任何一处掉链子（同步错乱、UI 看不懂、Late Joiner 进来挂了、按钮没反应）都会让玩家直接退出去找下一个世界。
设计上最容易翻车的几堵墙
Section titled “设计上最容易翻车的几堵墙”按踩坑频率从高到低排：
规则太复杂讲不清
Section titled “规则太复杂讲不清”Game World 设计阶段一种常见的扩张方向是堆设定：「玩家选一个职业，每个职业有四种技能，地图上有八种道具，胜利条件有三种，回合每三分钟切换昼夜……」
VRChat 上这套基本跑不起来。原因是玩家没耐心读说明书。Murder 4 之所以经久不衰，规则写一行就能讲完：「一个杀手拿着左轮，其他人是平民，找到藏在地图里的左轮子弹反杀。」
这一条没办法用技术解决。设计阶段就得砍：核心循环能用一句话讲完吗？讲不完，再砍。
没做大厅就把玩家直接扔进游戏
Section titled “没做大厅就把玩家直接扔进游戏”世界默认出生点直接出在游戏地图里，玩家一进来发现自己已经「在比赛」，但比赛规则没给、其他人在哪也不知道。
Game World 通常需要分两块：
- 大厅区（Lobby）：玩家落地的地方。能看规则说明、能选模式、能等其他人到齐、能从这里点按钮开始游戏。
- 游戏区（Arena）：正式开打的场地。玩家通过传送或大厅按钮进去，游戏结束后自动送回大厅。
这套大厅 / 游戏分离的结构在第 16 章做过传送的话，骨架已经在了。Game World 把它扩展成完整的「房间状态机」：等待中 → 准备中 → 游戏中 → 结算中 → 等待中。
Late Joiner 一进来世界就乱套
Section titled “Late Joiner 一进来世界就乱套”VRChat 的特殊之处之一是玩家随时进来。一局正在打，第六个玩家这时进来，他需要看到「现在比分 3:2、第二回合、剩余 1:30」，而不是看到「初始状态：所有人血量满、计时器从 5:00 开始」。
这件事在 VRChat 网络模型里需要专门处理：核心做法是把所有需要让 Late Joiner 看到的信息保存为同步变量（[UdonSynced]）。后加入的玩家会收到当前的同步状态，并在 OnDeserialization() 里据此重建画面（重置 UI、补播动画、对齐计时）。OnPlayerJoined 可以做一些初始化补充（例如让现有 Owner 重发一次状态），但不应作为同步过去事件的主路径——过去触发过的网络事件不会自动重放。第 28、29 章会专门讲。
但 Game World 设计阶段就要先意识到：任何状态变化都得能被「中途加入的人」重建出来。这个意识比「写一段同步代码」更先来。
胜负判定写在客户端上
Section titled “胜负判定写在客户端上”一种常见但有问题的写法：「玩家 A 进入了胜利区域 → A 客户端检测到 → A 客户端宣告 A 胜利」。
问题：A 的客户端可以撒谎。在 VRChat 里，客户端逻辑是不可信的，玩家可以通过修改客户端、断网、切换 owner 等方式让自己「赢」。
正确的做法是把权威逻辑集中到一个明确的「裁判对象」上：例如一个专门的 GameManager 物体，由它的 Owner（通常是 Instance Master 或开局时的 Owner）独占改写比分、胜负等同步变量，再通过网络事件广播结果。注意 VRChat 的 Master 也是某个玩家客户端，并不是一台可信服务器——它会随玩家进出而切换，不能完全杜绝作弊，只是减少状态冲突；竞技强度高的世界还需要在结果服务化、回放校验等方向另作设计。第 27 章 Ownership 和第 28 章网络事件会展开。
不在意作弊的休闲游戏里这件事可以放松。但只要在排行榜或竞技性强的世界里，「权威方在哪」必须想清楚。
死锁、Owner 切换错乱
Section titled “死锁、Owner 切换错乱”第 28 章会讲：状态在哪个客户端、Owner 在谁手上、消息谁来发。Game World 比 Chill 世界更容易撞上这类问题，因为状态的链路长：「玩家按按钮 → Owner 转移到那个玩家 → 改状态 → 序列化 → 同步给所有人 → 所有人看到的是新状态」。链路任何一节出问题就有玩家看到错的画面。
这一类问题在第六部要花相当篇幅。Game World 的开发周期里，调试同步问题占的时间比写正向逻辑还多。
技术上要先把哪几件做扎实
Section titled “技术上要先把哪几件做扎实”Game World 的优先级跟 Chill World 几乎相反：先逻辑再美术。
按必须程度排：
- 状态机思维（用「当前在第几步、按什么条件跳到下一步」描述系统的写法）：第 17 章那扇门是入门款。Game World 经常要管理「全局回合状态」、「每个玩家的角色状态」、「每个道具的拾取状态」三层叠在一起。第 17 章理解章 D 那一节（事件 → 条件 → 动作）是基础。
- 网络同步：
[UdonSynced]标记字段、RequestSerialization()发包、OnDeserialization()收包、SendCustomNetworkEvent()远程调方法。第 28 章。 - Ownership 模型：
Networking.SetOwner()、Networking.IsOwner()、Master Client 概念。Game World 里几乎每个交互都要先想「这个状态归谁所有」。第 27 章。 - Late Joiner 处理：
OnPlayerJoined事件 + 状态重建。第 29 章。 - UI 反馈：World Space Canvas、计分板、倒计时、状态文字。VRChat 不支持 Screen Space Overlay，UI 得贴在世界里。第 34 章。
- 调试方法：ClientSim 单人调试、双客户端测试同步、Console 看日志。第 40、41 章。
- 音效设计：胜利音效、失败音效、按钮反馈音、警示音。Chill 世界的「氛围」在 Game 世界里叫「反馈」。
这是一条几乎要把书的第三、四、六、八部全部啃透的路线。美术（第七部）反而能往后排。Game World 里玩家盯着的是计分板和对手的位置，墙是不是 PBR 材质大半时候根本注意不到。
简化版优先级：
| 顺序 | 学什么 | 在书里的位置 |
|---|---|---|
| 1 | 状态机 + 事件 / 条件 / 动作（已学） | 第 17 章、理解章 D |
| 2 | Ownership 模型 | 第 27 章 |
| 3 | 网络同步基础（同步变量 + 网络事件） | 第 28 章 |
| 4 | Late Joiner 处理 | 第 29 章 |
| 5 | 多人小游戏完整骨架 | 第 30 章 |
| 6 | UI 和反馈（计分板、倒计时） | 第 34 章 |
| 7 | 调试 + 多人测试 | 第 40、41 章 |
| 8 | 性能（玩家多时帧率不能崩） | 第 38 章 |
| 9 | 美术（够用就行） | 第七部按需 |
几种典型 Game World 各自的取舍
Section titled “几种典型 Game World 各自的取舍”「Game World」内部还能再分几类，每一类的技术重心略有不同：
- PvP 对战（Murder、躲猫猫、射击）：核心是「玩家之间的状态」，Ownership 切换频繁。多人同步是命门。需要做反作弊或至少做权威判定。
- PvE 闯关（Speedrun、平台跳、解谜）：核心是「关卡 / 物理 / 计时」。同步压力相对小（关卡状态可以全局只放在 Master 上），但物理同步（投掷物、移动平台）容易撞上 VRChat 物理同步的限制。
- 派对小游戏（Battle Discs、Pool 8 球、桌游）：核心是「单一物理对象的同步」（一个飞盘、一个球、一摞牌），需要
VRC Object Sync加自定义状态。容量小但每个对象都得做扎实。 - 任务向（Among Us 类、合作解谜）：核心是「角色 + 任务系统 + 投票 / 讨论环节」。状态最复杂，规则也最多。开发周期最长。
- 跑酷 / 训练场（Parkour、动作训练）：单人为主，多人只是观摩。同步要求最低，反而对物理动作和计时精度要求高。
按这条问自己：心里那个 Game World 偏哪一类？五类共享前面的技术骨干，但各自的「最难做对的事」不一样。
看几个真实例子
Section titled “看几个真实例子”下面几个是 VRChat 长期被引用的 Game World 案例（来源：vrclist、vrcw 等社区索引站）：
| 世界 | 类型 | 核心机制 | 走这条路能学到的 |
|---|---|---|---|
| Murder 4 | 多人推理 | 角色分配、武器同步、视野遮挡 | 隐藏信息的同步设计、Late Joiner 跳过当前回合 |
| Prison Escape | 多人合作 / 对抗 | 道具、传送、计时回合 | 大厅 / 游戏分离、回合制状态机 |
| Battle Discs | 物理对战 | 飞盘投掷 + 队伍计分 | 物理对象同步、轻量化 PvP |
| Pool（8-Ball） | 桌游 | 多球同步 + 撞击物理 | VRC Object Sync 极限优化 |
| Parkour 类世界 | 跑酷训练 | 计时 + 检查点 + 排行榜 | 单人计时 + 持久化排行（结合 PlayerData） |
不一定要进去玩，但开发前期把心里那个 Game World 跟其中一两个比一比，就知道自己缺哪条骨干。
自己想想能落地的画面
Section titled “自己想想能落地的画面”Game World 的「画面」指的是规则画面，不是视觉画面。把心里那个游戏写下来，至少答出这五件事：
- 核心循环一句话：玩家进来要做什么？最少能写到什么程度？（例：「躲在地图里别被发现，被发现的玩家加入猎人方」）
- 胜利条件一句话：什么情况下宣告结束、谁赢？（例：「猎人剩 0 人 → 躲藏方胜；时间到所有人都被找到 → 猎人方胜」）
- 一局多长：60 秒？3 分钟？10 分钟？这个数字直接决定回合状态机怎么设计。
- 几个人玩：4 人？8 人？最多 16 人？人数决定 UI 怎么布局、网络压力多大、性能预算怎么分。
- 新人能不能中途进：能 → 必须做 Late Joiner 处理。不能 → 把游戏区做成「锁起来不能再进」的实例。
这五条答不上来的部分，是设计还没成型的地方。把它们答完整再动手做，比直接打开 Unity 拼东西效率高得多。
这一章在脑子里留下来的
Section titled “这一章在脑子里留下来的”走 Game World 这条路要带走的：
- 评判标准是「能不能跑完一局」。画面有没有惊艳是后面的事。
- 状态机 + Ownership + 网络同步是骨干，必须先啃下来。
- Late Joiner 在设计阶段就要考虑，不是后期补丁。
- 美术可以排后面，UI 反馈不能。
- 起点选「单局 5 分钟、规则一句话讲完」的小游戏。Murder 4 那种规模是十几次迭代加多年运营的结果。
走这条路的话，后面几部按这个顺序读最稳：
第六部（和别人一起） ← 重点，整章节按顺序读完 ├ 第 26 章 你看到的，别人不一定看到 ├ 第 27 章 谁说了算，Ownership ├ 第 28 章 告诉别人发生了什么 ├ 第 29 章 后来的人怎么办 └ 第 30 章 做一个多人小游戏 ← 这一章是骨架，照着仿一个
第七部（让世界变成一个地方） └ 第 34 章 UI、提示和反馈 ← 计分板和倒计时 └ 第 38 章 性能 ← 玩家一多帧率会崩
第八部（做着做着会撞上的事） ← 全部都要 ├ 第 40 章 调试 ├ 第 41 章 测试（多人测试方法） ├ 第 42 章 版本管理 └ 第 43 章 素材和版权
第九部（发出去，然后继续走） └ 第 46 章 维护一个世界 ← Game World 维护成本最高把心里那个 Game World 的核心循环写下来一句话讲完，再画一张「大厅 / 游戏 / 结算」三段状态机的图。这两件事在打开 Unity 之前做完，比凭直觉拼东西更省时间。