20. Social Hub，给社群一个家
VRChat 里有一些世界，每天晚上九点准时聚 20 来个人，连聚了三年。它们不是热搜榜上的爆款，访问量平摊到每个非常驻玩家身上几乎为零。但常驻群体把它们当家。The Great Pug（owlboy 维护的酒吧型公共空间，多年一直是英语社群的代表性 Hub）是这类世界里被引用最多的样本。
这一章把 Social Hub（社群聚集的公共空间）这一类单独拎出来。它跟第 18 章的 Chill World 看起来很像（都靠氛围、都不靠机关），但解决的问题完全不同：Chill 世界服务的是「随机进来想休息一下的玩家」，Social Hub 服务的是「一群有归属感、每周来三次的固定群体」。这件事的设计含义和技术取舍跟前两章都对不上。
这类世界的核心是「社群结构能在里面发生」
Section titled “这类世界的核心是「社群结构能在里面发生」”一个 Social Hub 好不好的衡量，不看某一晚上有多少人，看三个月之后还有没有人按时来。
要让人按时来，空间得能承载几件 Chill 世界不需要承载的事：
- 能区分常驻和路人。社群里有「老人」和「访客」。老人需要熟悉的座位和角落，访客需要看得到「这里在发生什么」。两类人在同一个空间里得有不同的待遇。
- 能区分公开和私密。整场 20 个人时常分成几个小圈子各自聊。一个长桌全员聊很热闹，但不能全场只有一个长桌：要有让两个人单独说话的角落。
- 能给主持人 / 管理员开权限。社群里通常有运营者：定时活动主持、规则维护者、群组管理。他们需要能控制 BGM、关掉 / 打开某个区域、传送出捣乱玩家。
- 能撑得住高频使用。Social Hub 每周被同一群人进出一两百次。坏一次可能不致命，但经常坏会让群体迁移到别的世界。
- 能跟 VRChat Group 系统配合。VRChat 自己的 Groups 功能（社群、订阅、群组房间）已经存在，Social Hub 通常是某个 Group 的「物理总部」。两者要配合得自然。
跟 Chill 世界比，Social Hub 多了一层「治理结构」的需求：空间不只是给人感觉的容器，要能装下社群的运转结构。
玩家走进来在期待什么
Section titled “玩家走进来在期待什么”Social Hub 的玩家分两类，期待不一样：
常驻玩家（每周来三次以上）：
- 他们的固定位置还在。常驻群体会形成习惯：A 总坐吧台第三个凳子、B 喜欢窗边的露台。世界改版时把这些位置挪了，老人会有「家被装修得我不认识了」的不适。
- 熟悉的活动还能正常运行。每周三晚上的 DJ 台、每周五晚的桌游夜，相关设备得能用。
- 能快速找到当晚的「主活动地」。今晚是在主厅放电影，还是在二楼包间桌游？得有视觉线索。
路人（被朋友带来、或被推荐第一次进）：
- 能很快看出「这里在干嘛」。前 30 秒决定他要不要留。一进门看到一群陌生人坐成一桌聊得很热闹，路人会犹豫要不要凑过去。
- 能找到能凑的位置。空着的座位、墙边的吧台、可以坐着旁听的角落都得有，免得路人站在门口不知道往哪去。
- 能分辨谁是「主人」。哪个是世界 owner、哪个是 staff、哪个是常驻、哪个是跟自己一样的路人，最好一眼就看得出（VR 名签、特殊头顶标记、Group Tag 都是常用手段）。
两类人对空间的需求经常冲突。常驻群体喜欢「固定不变」，路人需要「易进入」。Social Hub 设计的微妙之处大半在这两者的平衡。
设计上最容易翻车的几堵墙
Section titled “设计上最容易翻车的几堵墙”按踩坑频率从高到低排：
把空间做成一个大开间
Section titled “把空间做成一个大开间”「我做一个大酒吧吧，所有人坐在一起」。这个直觉的问题是：人数一多就只剩一个声场，所有谈话挤在一起，谁都听不清谁。
VRChat 里 16 个人在一个开放大厅里基本聊不起来。需要分腔：
- 主厅（10 人左右的大圈子，谈话偶尔覆盖全场）。
- 几个小腔（4 到 6 人，吧台、卡座、二楼包间）。
- 至少一个真正密闭的私聊角（2 人，墙体能挡声音衰减更明显）。
物理墙体本身不阻挡 VRChat 的语音传播（语音是按距离衰减的，不绕墙），但墙能改变人的心理：人会下意识在墙围出来的小空间里放低音量。设计上要利用这一点。
没考虑负载情况下的人数
Section titled “没考虑负载情况下的人数”Social Hub 的人数容量由世界创作者通过 VRCSceneDescriptor 自行设置，常见硬上限在 32–64 人区间。要在最大人数下世界还跑得动。
这件事主要影响：
- Realtime Light 数量：每盏实时光在玩家身上会算一遍光照。Quest 上 4 盏以上的实时光基本就要看明显的性能下降。Social Hub 里灯多但要尽量烘焙。
- AudioSource 数量：每个 AudioSource 每帧都在算空间衰减。几十名玩家在一个有 20 个 AudioSource 的世界里，加起来的音频通道压力可观。
- Mesh 复杂度：玩家自己的 Avatar 通常都很重。世界本身要把网格做轻，给 Avatar 留预算。
第七部第 38 章会展开。这里只先意识到：Social Hub 的性能预算要按「最大人数 + 复杂 Avatar」的最坏情况估算，不要按自己一个人测试时的帧率估。
没给管理员留控制台
Section titled “没给管理员留控制台”世界发布之后两周，社群里有人捣乱，常见的需求：「能不能让管理员把那个人传走」、「能不能临时把 BGM 关一下听公告」、「能不能晚上 11 点之后强制把灯调暗一档」。
这些需求事先没设计的话，现场没办法处理。常见的做法是做一个「管理员控制面板」：
- 一个挂在某面墙上的 UI，只有特定 Player 能用（用 VRChat Player 的显示名 / 群组成员状态等做白名单判断）。
- 控制面板里有：一键 Mute 全场 BGM、一键切换房间灯光预设、传送某玩家到「冷静角」、显示当前在场玩家列表。
- 用 VRChat Group 集成判断身份：哪个群组的 owner / moderator 进来时自动获得权限；具体可读的 Group 信息以当前 SDK 暴露的 API 为准（Class Exposure Tree / 官方文档）。
这一类工具是 Social Hub 的隐形骨干，单纯的 Chill 世界不需要，但 Social Hub 几乎逃不掉。
跟 Group 系统脱节
Section titled “跟 Group 系统脱节”VRChat 自带的 Groups（VRChat 群组）功能可以做到：群组成员才能进入的实例（Group Only / Group+ / Group Public）、群组角色（Owner / Moderator / Member）、群组商店、群组公告。
Social Hub 不用这套就只是「一个公共大厅」。用上了能拿到：
- 常驻群体在他们想要的隐私级别下使用空间：今晚搞内部活动？开 Group Only 实例。今晚对外开放？开 Group Public。
- 管理员身份自动传到世界里：如果 SDK 当前版本暴露了相应的群组成员/角色查询能力，门禁、控制面板就有了权限基础；否则可以用显示名白名单 + 群组实例类型组合兜底。
- 订阅功能跟世界绑定：Group Subscription（订阅角色）配合 Udon Products，能给订阅者特权（特殊房间、专属椅子、显示名标记）。这一块第 25 章会讲。
如果心里那个 Social Hub 是为某个具体社群服务的，VRChat Groups 集成几乎是默认选项。
出生点把人扔到「半夜没人的状态」
Section titled “出生点把人扔到「半夜没人的状态」”跟 Chill 世界一样，但更严重：Social Hub 出生点的「氛围」必须既适合「20 人热闹中」，也适合「凌晨 3 点只有一个人」。
如果出生点旁边永远是「DJ 台 + 强 BGM + 满地人偶」的布置，凌晨一个人进来会觉得空旷又喧闹的反差特别大。
通用做法：出生点放在「氛围中等」的位置（比如门厅、玄关），让玩家自己往主厅走。主厅的强氛围只在到达后才完整呈现。这一点跟戏剧的入场设计是同一个思路。
技术上要先把哪几件做扎实
Section titled “技术上要先把哪几件做扎实”Social Hub 介于 Chill 和 Game 之间，技术骨干是两边的杂交：
- 氛围（继承自 Chill）：光、声音、空间尺度、动线。第七部 31、32、33、36、37 章。
- 同步（继承自 Game，但需求弱）：管理员的操作要让所有人看到（关 BGM、切灯、传走玩家），常驻玩家收藏的设置要能保留。第 27、28 章。
- PlayerData（持久化）：常驻玩家的偏好设置（坐哪、灯光预设、是否显示名签）跨实例保存。VRChat 的 PlayerData API（VRC.SDK3.Persistence）。第 28 章末尾或第 46 章。
- Group 集成：基于群组实例类型（Group / Group+ / Group Public）+ SDK 当前暴露的群组成员/角色查询 API 做权限。具体可用 API 以 Class Exposure Tree 和当前 SDK 版本为准；不可用时用显示名白名单、Instance Owner 等方式兜底。
- UI：管理面板、玩家列表、活动公告。第 34 章。
- 性能（最大人数情况下）：第 38、39 章。
简化版优先级：
| 顺序 | 学什么 | 在书里的位置 |
|---|---|---|
| 1 | 出生点 + 进场动线 | 第 31 章 |
| 2 | 多腔体空间设计（主厅 + 子腔 + 私聊角） | 第 32 章 |
| 3 | 光 + 声音的氛围基础 | 第 33、36 章 |
| 4 | 网络同步（管理员动作的同步） | 第 27、28 章 |
| 5 | UI 和管理面板 | 第 34 章 |
| 6 | PlayerData 持久化（玩家偏好） | 第 28 章末尾 |
| 7 | 性能（最大人数下） | 第 38、39 章 |
| 8 | 发布之后维护 + 长期更新 | 第 46 章（这一项 Social Hub 比其他类型重要） |
注意最后一项。Social Hub 的开发周期是「持续运营」，发布日是起点而非终点。第 46 章那一节对这一类世界尤其重要。
跟 Group 配合的几种部署模式
Section titled “跟 Group 配合的几种部署模式”VRChat Groups 给了 Social Hub 几种可能的实例策略：
| 模式 | 说明 | 适合什么社群 |
|---|---|---|
| Public | 任何玩家可进 | 想吸引新人的开放型公会 / 兴趣社团 |
| Group Public | 群组关联实例，任何玩家可加入；通常需要群组里有较高权限的角色（如 Moderator）才能创建 | 主体是群组活动但欢迎旁观的 |
| Group+ | 群组成员或被邀请的人可进 | 半私密社群，有一定门槛 |
| Group（也称 Group Only） | 仅群组成员可加入 | 私密内部聚会 |
| Friends / Friends+ | 创建者的朋友 | 小型亲密圈 |
不同 Group 实例类型的创建权限可由群主在 Group Roles 设置里自行配置（例如 Group / Group+ 通常 Member 即可创建，Group Public 通常需要 Moderator 以上）。
Social Hub 的设计可以一次容纳多种模式：白天 Public 开放给路人，晚上 Group Only 关起来内部用。这套切换不在世界里，而在 VRChat 实例创建侧。世界开发只要确保「Public 模式下不会暴露内部内容」（比如管理面板要做权限校验）就够了。
自己想想能落地的画面
Section titled “自己想想能落地的画面”把心里那个 Social Hub 写下来，回答这五件事：
- 服务的是谁的社群？这个 Hub 的「常驻群体」大概多少人、什么背景、用什么语言？群组性质决定整个空间的语言、配色、氛围、活动类型。
- 每周有几次固定活动？这些活动需要什么设备（DJ 台 / 大屏 / 桌游 / 沙发圈）？这些设备分别需要在哪个区域？
- 典型的一晚是什么样？8 点先来 5 个人在吧台聊天、9 点活动开始 15 人聚到主厅、11 点活动结束剩 6 个人散到各小腔体、凌晨 1 点剩 2 个人在二楼。设计要能撑过这些不同密度的瞬间。
- 路人能从哪进来？是 VRChat Public 搜索？群组邀请？传送门？路人进来后第一秒看什么、第十秒被引导到哪？
- 管理员需要哪些工具？把可能的「现场处置」需求列五条，对应到管理面板上的五个按钮。
这五条都答上之后，能开始把空间布局画出来。Social Hub 的布局通常要边写运营场景边来回调整，很少能一张图画到位。
这一章在脑子里留下来的
Section titled “这一章在脑子里留下来的”走 Social Hub 这条路要带走的：
- 评判标准是「三个月之后还有没有人按时来」。
- 空间要分腔：主厅、子区域、私聊角，三档密度都要照顾到。
- 管理员工具是基础设施，不是后期补丁。
- 跟 VRChat Groups 集成几乎是默认选项。
- 长期运营的功夫比开发本身长，结构稳定 + 装饰更新两件事要分清。
走这条路的话，后面几部按这个顺序读最稳：
第六部（和别人一起） ← 中等深度，Social Hub 同步需求弱于 Game World ├ 第 26 章 你看到的，别人不一定看到 ├ 第 27 章 谁说了算，Ownership └ 第 28 章 告诉别人发生了什么（含 PlayerData 持久化）
第七部（让世界变成一个地方） ← 重点，几乎全部都要 ├ 第 31 章 玩家进来的前三十秒 ├ 第 32 章 空间、比例和舒适 ← 核心：分腔设计 ├ 第 33 章 声音和氛围 ├ 第 34 章 UI 和反馈 ← 核心：管理面板 ├ 第 36 章 光 ├ 第 38 章 性能 ← 核心：最大人数下 └ 第 39 章 PC 和 Quest
第九部（发出去，然后继续走） ← 重点 └ 第 46 章 维护一个世界 ← Social Hub 维护周期最长下一章看 Gallery。Gallery 跟 Social Hub 同样有「让人走进来」的需求，但服务对象从社群换成了作品。空间安静下来给作品让位，这件事的取舍跟前面三章都不同。