第 19 章是全集里第一次真正面对「人多了怎么办」。当同场玩家从 8 人涨到 200 人，逐帧全量广播立刻失效，AOI 区域广播成为唯一可行解：用空间索引切分世界，只把订阅者视野内的实体变化推给它，并为每个订阅者设字节预算。缩圈系统则是大逃杀特有的节奏控制器——它既是玩法，也是把玩家逐步逼向同一区域、从而反向缓解广播压力的机制设计。
本章定位
- 全集位置：第 19 章，属「大规模实时」层的代表，是全集中单房并发量最高的一章。
- 难度梯度：高阶。难点集中在空间索引、广播预算与反压策略的协同调优。
- 前置章节：第 7 章贪吃蛇大作战（实时骨架）、第 15 章微型赛车系统（回滚与插值）、第 16 章简版 MOBA（关键帧、快照与一致性哈希）、第 17 章战棋对战（事件溯源思想）。
- 后续衔接：第 20 章社交大厅为这类高频对战提供入口与漫游能力，第 23 章跨服战则把单房规模问题升级为跨区调度问题。
核心验证目标
- 空间索引与订阅模型：固定网格（如 64×64 或 128×128）或四叉树，实体进出格子触发增量订阅与退订，服务端为每个订阅者维护可见实体集合与上次版本号。
- 差量推送与优先级：仅发送位置、朝向与动画状态的变化并量化为 int16，按近距、视线内、战斗相关、远距低频的优先级排队。
- 字节预算与合帧压缩：每 Tick 为每个订阅者设定 1 至 3KB 预算，超预算对象推迟；同一订阅者的多对象更新合帧，允许 LZ4 或 Zstd 压缩。
- 反压与可见性裁剪：客户端 ACK 落后时降低 AOI 频率或放大量化误差；队内共享被动雷达，但绝不下发未可见敌方的精确数据，只保留枪声与脚步等事件。
- 缩圈系统：安全区中心与半径按阶段模板收缩，下一圈中心在上圈内随机并避开不可达区，结合存活玩家密度做偏置，每阶段含预告时间与收缩时间。
- 半确定性物理与弹性扩缩：投掷物、载具与命中判定采用服务器半确定性加参数下放；每进程承载 1 至 8 房，100 人房间 p95 Tick 小于 40ms，跨分片广播经边界网关。
技术栈建议
| 层次 | 推荐选型 | 说明 |
|---|---|---|
| 服务端 | Go 优先，Java 备选 | 配合 ECS 与位集合组件组织实体 |
| 客户端 | TypeScript、Unity 或 Unreal | 负责插值渲染与输入采集 |
| 物理 | 服务器半确定性 | 关键参数下放，避免浮点分歧 |
| 协议 | UDP 加 WebSocket | UDP 带前向纠错承载状态与输入，WebSocket 负责控制、观战与恢复 |
| 时钟 | 20Hz 服务端 Tick | 客户端渲染 60fps，AOI 推送节流 10 至 20Hz 可配 |
本章文章
| 文章 | 核心内容 |
|---|---|
| 在线联机原型全集：第 19 章 战场吃鸡 | 200 人同场、AOI 区域广播、缩圈系统、空投与载具、掉线重连观战、服务端弹性扩缩容 |
与相邻章节的关系
- 上一章：第 18 章 城市经营 是长时段异步一致性的代表，本章回到毫秒级实时，两者构成全集的两个极端。
- 下一章：第 20 章 社交大厅 为本章这类高频对战提供统一身份、房间目录与漫游入口。
- 同层对照：第 23 章 跨服战系统 把「单房扩容」问题替换为「跨区调度」问题。