游戏后端深入剖析 - TRIBES (1998)

关键洞察

关键洞察

关键洞察

  • TRIBES 网络模型 根据其需求处理游戏数据,分配紧急性和可靠性等级,以便只有最关键的更新能迅速进行,而不那么重要的信息则等待轮到自己。

  • 它的核心是一个极简的 UDP 层,仅报告数据包交付状态,将重试和排序留给针对每种数据类型调优的高级系统。

  • 五个专业的流管理器处理事件、对象“幽灵”、玩家移动、静态数据块和按固定数据包顺序的字符串,确保紧急输入不会被挤出。

  • 客户端和服务器在同步的 32 毫秒节拍上运行;客户端插值幽灵对象并预测玩家命令——在三个连续的数据包中发送——而服务器则验证并轻柔地调和差异。

  • 通过缓存静态资源、仅发送状态变化和模块化职责,该模型从拨号对战扩展到大型户外战斗,为 TRIBES 的传奇在线竞技场奠定了基础。

马克·弗朗迈尔和蒂姆·吉夫可以说是为游戏开发行业写了影响力最大的多人网络论文之一,他们作为Dynamix的TRIBES开发人员——完整内容可在这里查看。

尽管有些过时,但它突出了任何游戏工作室,无论大小,都可以加入其多人游戏中的最佳实践,以帮助改善其在线架构。让我们“瞥一眼”他们的见解。

让我们来看一下TRIBES的摇滚(双关语),这个多人网络模型。  

重新思考数据优先级

TRIBES的网络模型不再追求原始带宽。它取而代之的是询问哪些更新确实重要,以及它们何时需要到达。通过为每一项游戏状态分配紧急性和可靠性层,它将焦点从填塞管道转移到在正确的时刻传递正确的数据。

这种转变重新定义了实时游戏的效率。开发者不再平等对待所有数据包,而是根据每种数据类型的需求进行量身定制的传递,确保关键输入优先到达,而较不重要的更新则等待轮到它们。

当速度遇上可靠性

其基础是一个精简的基于UDP的连接管理器,仅仅报告成功或失败。自动重试被剥离,留下更高层次决定是否以及如何从丢失中恢复。

这种关注点的分离使得专门的处理程序能够仅执行每个流所需的保证。这是一个故意抛弃“一刀切”协议的举动,转向一个更加精确的系统。

结果是一个网络骨干,在需要关注时才算作阻碍——然后给那个数据应有的处理。

模块化流管理器

五个独特的流管理器坐落在连接层的顶部,每个管理器都有自己的任务和数据包中的顺序。事件、幽灵、移动、数据块和字符串都有专用通道以防干扰。

它们以固定顺序填充数据包,以便紧急输入永远不会被大量数据所挤出。这种编排使网络变成了一场排练有序的合奏,而不是一场混乱的自由竞争。

预测与同步

客户端和服务器以固定的32毫秒滴答声向前推进。在到达之间,客户端插值幽灵对象以创建平滑运动,即使更新落后。

玩家输入依赖于三个连续的数据包以最大化传递机会。在客户端,预测算法在新数据到达之前发射,而服务器在每次移动到达时验证每一个动作并调和差异。

这种双重方法使游戏感觉即时,调和伪影对除受影响玩家外的所有人都是隐形的。

带宽效率和扩展性

静态资产——地图几何、车辆蓝图等——仅在“数据块”流上传输一次,然后保持缓存。这意味着例行传输保持最小,腾出了空间用于实时更新。

幽灵通过仅发送变化的位来镜像对象状态,避免浪费周期和字节的过时快照。每个数据包只携带新的信息,系统巧妙地避免了重新发送每个人已经知道的内容。

这种分层设计证明了适应性,无论是运行在拨号上还是现代宽带上,并为拥有多个同时玩家的大型户外地图奠定了基础。

TRIBES网络的遗产

当《星际征服者TRIBES》于1998年推出时,其网络框架支持了大规模战斗,并帮助定义了这个时代的在线射击游戏。后来,TRIBES II完善了头部、压缩字符串,并微调了重传,以实现更精简的性能。

当时的开发者尝试了动态数据包速率、线程I/O和早期语音集成——所有这些都建立在核心教训之上:数据应该在为其独特角色设计的规则下传输。

几十年后,TRIBES模型仍然是分离关注点和根据实时多人游戏真实需求量身定制交付策略的力量的证明。

---

本文基于并引用了马克·弗朗迈尔和蒂姆·吉夫在gamedevs.org上发表的原始文章。原内容的所有权利归其各自所有者。

书写者

Edgegap团队