第 6 章解决的是「两个人怎么同步」，第 7 章要解决的是「一百个人怎么同步」。玩法依旧简单——蛇往前跑、吃食物、撞了死——但一旦同场实体上百，全量广播就会立刻把带宽吃光。于是本章的核心工具登场：AOI（Area of Interest，兴趣区域）。玩家只该收到自己附近的状态变化，远处的世界与他无关。这条原则是后续所有大世界、吃鸡、MMO 原型的经济学基础，也是「服务器是世界唯一真相，但真相不能全量下发」这句口号的第一次落地。
本章定位
- 难度梯度：高阶。在实时同步之上叠加空间分区与带宽经济学两个新维度。
- 前置章节：第 6 章 Pong 对战 的 Tick 模型与预测纠正是本章的直接基础，
proto-007-snake-battle标注依赖proto-006-pong。 - 能力跃迁：从「同步全部」跃迁到「同步必要的部分」。服务器开始主动决定每个客户端「应该知道什么」。
- 阅读时长：单篇 PRD 约 500 行，建议重点读 AOI 网格划分、状态压缩格式与分区分片三节。
核心验证目标
- AOI 可见性：按区域广播，只向玩家下发其邻域内的实体变化，这是本章最核心的带宽杠杆。
- 服务器权威碰撞裁定：撞墙、撞蛇、吃到食物的判定全部在服务端完成，保证一致性与抗作弊。
- 实体状态压缩：玩家与食物的状态编码，用增量与位压缩把每 Tick 的字节数压到预算内。
- 周期快照同步：以 Tick 为节拍下发快照，新进入 AOI 的实体需要补发全量信息。
- 延迟平滑：插值与预测让 60 FPS 体验不因网络抖动而破碎。
- 食物热点刷新：动态地图生成与负载均衡，避免所有玩家挤在同一区域导致热点爆炸。
- 分区分片：多服协同承载超大世界，跨区玩家移动时的状态交接是关键难点。
技术栈建议
- 语言：Go、Rust、C++ 或 Node.js。C++ 与 Rust 在实体数量大、每 Tick 计算密集的场景更有余量。
- 传输：UDP 或 QUIC 加二进制 WebSocket，与第 6 章保持一致。
- 存储：世界快照按分区落盘，食物与实体状态可缓存在内存并周期持久化。
- 关键设计：把「AOI 计算」「状态压缩」「广播」做成三段独立管线，这样第 19 章的战场吃鸡可以直接替换 AOI 策略而不动其余部分。
本章文章
| 文章标题 | 核心内容 |
|---|---|
| 在线联机原型全集：第 7 章 贪吃蛇大作战（Snake Battle） | 完整 PRD：Game Server、FoodSpawner、CollisionEngine、ZoneManager、ReplayLogger 五模块设计，含 AOI 广播策略、状态压缩与分区负载均衡 |
本章只有一篇 PRD；AOI 的算法细节（网格、四叉树、十字链表）在游戏服务端实战专题中有专门文章展开。
与相邻章节的关系
- 上一章：第 6 章 Pong 对战 建立 Tick 与预测纠正，本章在其上叠加空间分区。
- 下一章：第 8 章 战舰 / UNO 简版 从「广播什么」转向「隐藏什么」，开始处理信息不对称与服务器保密性。