8.2 在线子系统与高级网络

8.2 在线子系统与高级网络

本节摘要：会话层解决"玩家怎么找到彼此"：建房间、搜房间、加入、断线，引擎用在线子系统接口屏蔽平台差异。本节走通会话全流程，比较监听与专用两种服务器形态，并介绍复制图与网络移动等进阶手段。

从"能联机"到"能找到人"

8.1 解决了"连上之后状态怎么同步"，但"连上"本身是个会话问题：谁开局、房间叫什么、别人怎么搜到、满员怎么处理、掉线怎么算。手写这些逻辑要对每个平台各写一遍，引擎的在线子系统（Online Subsystem）把它们抽象成统一接口：会话的创建、发现、加入、销毁，平台换成接口实现跟着换，游戏逻辑不动。这一节处理的就是"玩家从大厅到同场"的这段路。

本节在网络章的位置是"会话与架构层"：8.1 的同步原语在这里被组装成完整的对局流程，8.3 的世界流送在这里决定运行在哪类服务器上。预算视角：会话层不花每帧预算，但服务器形态的决定影响整个项目的运维成本——这是一次性架构听证。

会话生命周期与接口设计

一次典型的对局会话走五步：创建（主机端定房间名、人数上限、是否私密度）、注册、被发现（其他玩家检索公开会话列表）、加入、开始/销毁。每步在接口里都有对应调用，游戏逻辑只需要关心业务判断（房间满了提示、密码不对退回）。会话设置里两个参数最常被低估：人数上限影响服务器的模拟与同步成本，8.1 的相关性剔除效率也随人数变化；私密度与好友可见性直接决定检索行为——测试阶段最常见的事故是"建了房搜不到"，十有八九是私密度参数与检索过滤条件对不上。

服务器形态的取舍在立项时就要听证。监听服务器：第一台客户端兼任主机，省掉服务器成本，代价是主机优势（他的延迟天然为零）与主机退出全房散场的风险，适合合作类与轻量对抗。专用服务器：无头运行、只做权威结算，公平与稳定都归它，代价是服务器成本与部署管线，竞技类与运营型项目的默认答案。两种形态在工程上的差异主要是打包产物与移动语义——无头服务器的打包目标与关卡切换的无缝语义要单独验证。

服务器形态的取舍对照

进阶手段：量大之后的两个工具

玩家规模与地图复杂度上来后，两个进阶工具值得认识。复制图（Replication Graph）重建了"谁该收到谁"的计算方式：把相关性判断从逐Actor逐帧的通用规则，改成按空间网格、按角色关系预先组织的分发结构，几十人同场、万物同步的项目靠它把网络线程的 CPU 账单压下来；代价是理解与维护成本，起步阶段用默认同步，玩家数过了阈值再上。无缝切换（Seamless Travel）解决换图时的体验断层：传统切换会断开重连，无缝切换把玩家装进"过场车"里平滑搬到新地图，多人项目的换图默认应当走这条路——大厅到对局来回切换的掉线事故，多数是没配无缝语义。

另外两个趋势性话题知道名字即可：网络移动组件为 Character 提供了客户端预测加服务器校正的现成方案，自写移动同步之前先确认它不够用；引擎在新版本持续引入更高效的同步后端，思想仍是"按需分发加优先级"，老经验不贬值。

案例：一个可被好友加入的合作对局

背景：双人合作闯关需要：任意一方建房、好友列表检索加入、开始后进同一关卡、中途换图不断线。这是会话层的最小完整闭环。

操作：第一步，按目标平台启用对应在线子系统实现，项目设置里注册默认接口——本案例逻辑与平台解耦，测试期可用默认空实现走通流程。第二步，大厅界面三组调用：建房按钮调创建会话（房间名取玩家名、人数上限二、公开）；刷新按钮调检索并渲染结果列表；加入按钮对选中结果调加入。第三步，加入成功后双方各自执行到对局地图的切换，主机走监听形态。第四步，项目设置开启无缝切换并按框架要求指定过场地图，大厅到对局、对局到下一关都走无缝语义。第五步，对局内用 8.1 的同步原语做双人交互（机关双人同踩），验证同步链路。

结果：两人从大厅到同关卡通关，换图期间不掉线；一人退出后按"房散回大厅"处理。

解读：这个闭环里最值得复盘的是两处工程决定：逻辑全部压在接口层——测试用空实现、上线换平台实现，游戏代码一行不改，这是在线子系统抽象的兑现；无缝切换的过场地图是必填项而非可选项，多少"换图掉线"的排查时间，本来可以省在立项时读完这段配置说明。变式一：转专用服务器——把监听主机换成无头服务器进程，会话接口调用不变，只是创建方从客户端变为匹配服务端，9.2 的打包节给出产物管线。变式二：断线重连——会话参数允许中途加入，配合 8.1 的属性同步，重连者拿到的就是当前世界状态。

常见坑：会话设置里的人数上限写成产品文案上的"最大队伍数"。上限是服务器同步规模的硬约束，写小了玩家进不来，写大了同步量失控——它应该由服务器的预算反推出来。

本节要点回顾

• 在线子系统把会话四步标准化，逻辑压在接口层，平台实现可替换。
• 监听省成本、专用换公平，形态选择是一次性架构听证，立项定最好。
• 搜不到房先查私密度与过滤条件，会话参数是检索行为的全部输入。
• 人数上限由服务器预算反推，不是产品文案的自由参数。
• 多人换图默认无缝切换，过场地图是必填项，不是可选项。

高频问答

问：局域网联机测试要不要接在线子系统？
不用：引擎的内建局域网模式足够日常开发，会话接口留给需要互联网匹配的阶段。开发期用内建模式把同步逻辑全部验完，接入平台会话层时只剩"怎么找到人"的问题——两层解耦，接入风险最小。

问：玩家中途掉线，他控制的角色怎么处理？
默认行为是角色留在原地或按项目规则销毁。合作类项目通常做"等待重连"：角色保留一段时间并挂起输入，重连走中途加入流程拿回身体；对抗类项目直接移除并广播。处理逻辑本身简单，关键是把规则写进会话设计，而不是掉线发生时临时决定。

问：多大人数开始考虑复制图？
经验阈值在几十人同场：相关性剔除的逐对计算开始吃满网络线程一个核。低于这个规模时把优化精力花在减少同步字段与调相关距离上收益更大——复制图是规模化的解，不是默认配置。

一份会话参数速查

建会话前把五个参数过一遍：人数上限（反推自服务器预算）、私密度（公开还是仅好友）、中途加入（合作项目建议开）、断线保留（等待重连的时长）、区域过滤（跨区匹配的延迟代价）。这五项覆盖了会话层的绝大多数排错与设计决策——把它们写进项目的网络设计文档，比散在代码里可维护得多。