23. Event World，舞台、活动和聚会
VRChat 里的某些世界一年只热闹一次。今晚九点演唱会、下周末 Anime 漫展、月底某游戏新作的发布会、半年一次的毕业典礼。它们的访问曲线像一根钉子：平时一天 0 个人，活动当晚两小时三千人涌进来，第二天又回到 0。
这一章把 Event World（为演出、聚会设计的空间）这一类拎出来。它跟 Social Hub 看起来像（都要承载多人聚集），跟 Narrative World 也像（都是一次性体验），但取舍方向跟两者都不同。Social Hub 服务的是「常驻群体的长期运营」，Event 服务的是「不认识的一群人在一个时间点的同步体验」；Narrative 服务的是「单人或小团体的私人叙事」，Event 服务的是「人群的集体感受」。
这类世界的核心是「让一群人共享某段时间」
Section titled “这类世界的核心是「让一群人共享某段时间」”Event World 的成败标准跟其他类型差别最大：活动当晚两小时之内，满负载的世界能不能让所有人看完、听清、感到「在场」。
要做到这件事，几样基础得过关：
- 能撑得住容量。VRChat 单实例的容量由世界创作者通过
VRCSceneDescriptor自行设置（Recommended Capacity软上限 +Capacity / Hard Cap硬上限）：达到软上限后实例会被减少在公开浏览中的曝光，达到硬上限后新玩家不能再加入（实例创建者、世界作者、Group owner 等少数情况可能例外）。大型 Event 世界常见会把容量调得较高（例如 60+），但实际可用上限受当前 SDK 与平台性能影响，要以官方文档当前版本和压力测试结果为准。跨实例同步演出（用一台主机推流到多个分会场，或所有人用同一时间戳播视频）要做技术铺垫。 - 舞台得让所有人看得见。不像 Chill 世界各占角落，Event 里几乎所有人的视线都聚在一处。座位安排、视野遮挡、舞台高度要专门算。
- 音视频是命门。一场演唱会，音乐声场不对、视频卡帧、灯光反应延迟，整场就崩了。
- 入场和退场要设计。两小时活动结束的瞬间几百人退出 / 切换实例，那个瞬间不能让世界崩溃。
- 有舞台也要有「闲处」。不是所有人想全程目不转睛地看舞台。两个朋友想中途到角落聊会儿天，能找到地方。
跟前面五章比，Event World 是「短时高强度」的代表。其他世界优化的是「长期可用」，Event 优化的是「关键 30 分钟里不掉链子」。
玩家走进来在期待什么
Section titled “玩家走进来在期待什么”Event World 的玩家比其他类型更明确知道自己在做什么。期待具体来说：
- 能看到 / 听到主活动。这件事是基础。视野被柱子挡住、声音被远方的 BGM 盖住、视频画面卡顿，都直接破坏体验。
- 加载快。Event 玩家是按时间点入场的，世界加载 30 秒比 5 分钟差很多倍。模型轻量化、贴图压缩、Shader 简化，全要做。
- 有「看清舞台」的位置和「比较随意」的位置。一些人想坐前排集中看，一些人想后排随便晃。座位分层是必须的。
- 能跟旁边的人轻轻互动。情绪到了想拍手、想欢呼、想拿出荧光棒，世界要支持这些（情绪表达型 Pickup 是 Event World 的标配）。
- 结束之后能干点什么。活动结束后立刻清场会让人怅然。最好留 10 到 30 分钟的「散场聊天时间」，玩家可以留下来跟朋友讨论刚才的内容。
期待里几乎没有的：「探索」。Event World 玩家进来不是为了「逛」，是为了「在场」。多余的探索路径反而让玩家在活动开始前迷路。
设计上最容易翻车的几堵墙
Section titled “设计上最容易翻车的几堵墙”按踩坑频率排：
没考虑实例分流
Section titled “没考虑实例分流”VRChat 单实例的容量由创作者自行设置，大型 Event 世界常见硬上限在 64–100 人之间。一场预期 500 人参与的活动直接进单一世界 ID，结果就是「实例 1 满了 → 自动开实例 2 → 实例 2 满了 → 实例 3」，每个实例各跑各的。如果是 Live 演出且没有跨实例同步机制，前实例的人和后实例的人看到的演出进度不一致。
应对方式：
- 一次性事件：跟主办方协调，活动现场用「主实例 + 镜像实例」结构。主实例由演出方控制，其他实例通过统一时间戳的视频源（VRChat Video Player + 网络流）保持同步。
- 模板化活动：直接把「同步 = 不重要」当默认。所有实例独立运行，每个实例里的活动是「本实例」的活动。社群型聚会常用这套。
设计阶段就要决定：是要追求「全场同步」还是接受「分实例独立」。两者技术方案完全不同。
舞台到看台的距离没量过
Section titled “舞台到看台的距离没量过”VR 玩家身高约等于真实身高（VRChat 默认 Avatar 大约 1.7 米）。一个 50 米深的礼堂里，最后排玩家看舞台上的演员是个豆子。
线下演唱会通过大屏解决这件事。VRChat 里同样要：
- 舞台两侧放大屏（World Space Canvas + RenderTexture 把舞台主视角投到屏上）。
- 后排座位高度抬起（看台阶梯化，越往后越高）。
- 必要的话设传送点：玩家可以从「全景位」传送到「近距离观看位」。
这些细节如果第一遍没做，活动当晚后排的体验会非常差。
Event 的音频复杂程度高于其他类型世界。同时存在的可能有：
- 演出主音频（演讲者麦克风、表演音乐）。
- 背景音乐（活动开始前 / 中场休息 / 散场时）。
- 环境音（人群欢呼、音效）。
- 玩家语音（VRChat 内置语音）。
- 互动音效（按按钮、Pickup 音）。
这些都没分层时玩家听到的是一锅粥。需要做：
- 主音频不空间化（Spatial Blend = 0），让所有玩家听到同一个音量。否则后排听不清。
- 环境音空间化（Spatial Blend = 1），按距离衰减。
- 玩家语音由 VRChat 自动处理。但要确保 BGM 音量低于语音才能让人听清旁人说话。
- 互动音效局部化（按按钮的反馈音只在按按钮的玩家附近响）。
音频分层是 Event 比其他世界更精细的一项。
灯光太花太亮
Section titled “灯光太花太亮”Event World 经常想「演唱会感」：满场频闪、激光、彩色光柱。这些视觉冲击在线下一闪而过没事，VR 里持续闪烁会让人晕、让人偏头痛、对癫痫敏感的玩家可能直接退出。
通用做法：
- 频闪频率严格低于 3 Hz（每秒 3 次），或者高于 60 Hz / 几乎不闪。3–30 Hz 是诱发光敏性癫痫风险最高的区间，必须避开；WCAG 2.1 等无障碍标准把”每秒不超过 3 次闪烁”作为内容指南底线，但更安全的做法是大幅低于 3 Hz。
- 高强度光（激光、追光）只用在峰值时刻，全程开着会让画面信息密度爆掉。
- 舞台光做成可控（运行中可调整亮度），从中等亮度起步，按节奏推到峰值。
VRChat 上有专门的开源舞台灯光项目可以参考：AcChosen 维护的 VR Stage Lighting（GPU 实例化优化的 DMX512 风格灯光，支持各种舞台灯效，社区认可度高）。直接拿来用比自己从零写灯光控制效率高得多。
散场设计被忽略
Section titled “散场设计被忽略”活动结束的瞬间是技术压力最大的时刻：几百人同时切实例、同时回大厅、同时退出客户端。如果活动结束直接「黑屏 + 谢谢观看」，体验会断崖式下跌。
更好的设计：
- 活动结束后的 30 分钟「after party」：舞台灯调成余烬色，BGM 切到柔和音乐，让玩家可以留下来聊。
- 散场动线：明确告诉玩家「往这边走是出口 / 往这边走是 after party」。
- 纪念品：能拾取的小道具（活动票根、纪念徽章），玩家可以带走 / 在 PlayerData 里留个标记。
散场比开场更需要心力。开场玩家自己会兴奋，散场如果不设计就会冷场。
技术上要先把哪几件做扎实
Section titled “技术上要先把哪几件做扎实”Event World 的技术骨干是几件大块的拼接：
- 同步基础（看活动是否需要跨人同步）：第六部全部。
- VRChat Video Player（USharpVideo / VizVid）：播视频内容是 Event 的常见需求。第七部 UI 章会涉及。
- 大型场景的性能：80 人在场 + 复杂舞台 + 视频流 + 灯效，性能压力极大。第七部第 38 章是核心。
- 舞台灯光：第七部第 36 章 + 社区方案（VR Stage Lighting）。
- 空间设计（舞台 + 看台 + 角落）：第七部第 32 章。
- UI（活动信息、倒计时、互动元素）：第七部第 34 章。
- PlayerData（活动纪念品、报名标记）：第六部相关章节。
- 快速加载（贴图压缩、模型简化）：第七部第 38 章。
简化版优先级：
| 顺序 | 学什么 | 在书里的位置 |
|---|---|---|
| 1 | 大空间动线 + 看台分层 | 第 32 章 |
| 2 | 舞台灯光（含 VR Stage Lighting 方案） | 第 36 章 |
| 3 | 音频分层 + Spatial Audio | 第 33 章 |
| 4 | UI（活动信息、倒计时） | 第 34 章 |
| 5 | 视频源（VRChat Video Player） | 第 34 章及社区资源 |
| 6 | 性能（满负载 80–100 人压力） | 第 38 章 |
| 7 | 同步 + 跨实例策略（按需） | 第六部 |
| 8 | PlayerData（纪念品） | 第 28 章末尾 |
| 9 | 发布前压力测试 | 第 41 章 |
| 10 | 散场和长尾运营 | 第 46 章 |
注意第 9 项。Event World 跟其他类型最大的差别是「上线日就是峰值日」。常规世界上线之后还能边运营边修，Event 当晚出问题就是事故。压力测试是必须的：用多客户端模拟、邀请朋友先期内测、提前一周做满负载彩排。
几种典型 Event World 各自的取舍
Section titled “几种典型 Event World 各自的取舍”「Event World」内部还能再分几类：
- 演出型（演唱会、DJ Live、舞台剧）：舞台和音视频是核心，灯光复杂。容量需求最高，往往要跨实例同步。
- 集会型（漫展、社群聚会、艺术节）：多舞台 + 多展位 + 自由流动。空间大，分区多，对同步要求弱（每个展位独立运转）。
- 典礼型（毕业典礼、颁奖、纪念活动）：仪式感强，节奏严格，音视频统一控制。容量中等，对舞台细节要求最高。
- 发布型（新品 / 游戏 / 内容发布）：以演示为主，玩家相对被动。视频展示和互动 Demo 占主要。
- 派对型（生日派对、节日聚会、临时社交）：随意，舞台轻量，互动机关多。最接近 Social Hub 但单次性。
按这条问自己：心里那个 Event 偏哪一类？前两类对技术要求最高，后两类对设计要求高但技术压力小。
自己想想能落地的画面
Section titled “自己想想能落地的画面”把心里那个 Event 写下来，回答这五件事：
- 活动具体形式：演出？集会？典礼？多长时间？
- 预期人数：50 人？300 人？1000 人？决定要不要跨实例方案。
- 核心视听内容：是直播视频？是 VRChat 内的 Avatar 演出？是音频为主？决定哪个组件是命门。
- 是一次性还是模板：只办一次还是复用？决定前期投入策略。
- 散场怎么设计：直接结束？还是 after party 一段时间？
回答上之后，可以画「时间线 + 空间布局」二维表：每个时间段（开场前 30 分 → 主活动 90 分 → 散场 30 分）对应空间不同区域的状态（开放 / 关闭 / 灯效）。这张表是 Event 设计的核心文件，比 Hierarchy 早。
这一章在脑子里留下来的
Section titled “这一章在脑子里留下来的”走 Event World 这条路要带走的：
- 评判标准是「活动当晚那两小时能不能撑住」。
- 实例容量是硬限制，跨实例方案要早决定。
- 舞台 + 灯光 + 音视频是命门，PBR 材质和氛围细节可以排后面。
- 灯光要做安全（避免高频闪烁），音频要分层。
- 散场跟开场一样重要，30 分钟 after party 是标配。
- 上线日就是峰值日，压力测试是必须的。
走这条路的话，后面几部按这个顺序读最稳：
第六部（和别人一起） ← 看是否需要跨实例同步 ├ 第 26、27、28 章 ← 同步基础 └ 第 29 章 后来的人 ← Event 中途加入处理
第七部（让世界变成一个地方） ← 重点 ├ 第 32 章 空间、比例和舒适 ← 关键：舞台 + 看台分层 ├ 第 33 章 声音和氛围 ← 关键：音频分层 ├ 第 34 章 UI 和反馈 ← 关键：活动信息 + 视频组件 ├ 第 36 章 光 ← 关键：舞台灯光 ├ 第 38 章 性能 ← 关键：满负载压力 └ 第 39 章 PC 和 Quest
第八部（做着做着会撞上的事） ← 重点 ├ 第 41 章 测试 ← 关键：压力测试 / 彩排 └ 第 43 章 素材和版权 ← 关键：视频音乐授权Event 这条路最值得提前做的事是排彩排时间表。开发期保留至少一周给「满负载彩排 + 修问题」。这一周做的事比前面三个月的开发都难替代。