2004年的《RuneScape》在56k拨号上网环境下，通过极致压缩数据字节，成功实现了多人在线角色扮演游戏。文章以玩家点击移动为例，详细追踪了从客户端到服务器再到其他玩家屏幕的每一个字节传输过程。

好的，这是根据您的要求，对原文主要内容进行的中文重述，保留了关键细节，并删减了与主题无关的内容。

标题：2004年的《RuneScape》如何将多人在线RPG塞进56k拨号网络

核心问题： 在2004年，许多玩家仍在使用速度仅为5KB/秒的56k调制解调器上网。然而，一款名为《RuneScape》的3D多人在线角色扮演游戏，却能在浏览器中流畅运行，支持单个服务器容纳数千名玩家，同屏显示数十人。它是如何做到的？

答案： 通过一种近乎偏执的、持续不断的“不浪费字节”的设计。本文将追踪玩家点击向北移动一格后，从客户端到服务器，再到其他玩家屏幕的每一个字节。

方法论： 本文细节来源于对2004年《RuneScape 2》客户端的反编译分析。

核心限制： 1. 带宽： 56k调制解调器下行速度约5KB/秒，上行更慢。 2. 技术环境： 游戏运行在Java Applet中，受限于安全沙箱，只能使用单一的TCP连接，无法使用UDP。 3. 服务器周期： 游戏服务器以约600毫秒为一个周期（Tick）运行，每个周期内要为所有玩家计算并发送其可见信息。

关键设计：

• 加密层： 仅对每个数据包开头的“操作码”字节进行ISAAC流加密。操作码决定了数据包的类型和解析方式，加密它是防止第三方解析数据包的最廉价方式。

• 发送行走请求： 当玩家点击向北移动一格时，客户端会发送一个7字节的数据包。

  • 节俭设计1： 路径点只发送“拐点”，而非每一步。例如，直线行走十格只发送目的地一个点，服务器会根据自身碰撞地图验证路径。
  • 节俭设计2： 路径点坐标使用相对于起点的“增量”（每个轴1个有符号字节），而非绝对坐标（每个轴2个字节）。对于多步路径，每个额外路径点节省50%的字节。

• 服务器接收与处理： 服务器每600毫秒处理一次所有玩家的输入缓冲区。数据包到达的时间点决定了其延迟是接近0还是接近600毫秒。

• 玩家更新数据包： 这是最核心的节俭设计。服务器每个周期向每个玩家发送一个复合数据包，描述该玩家能看到的所有其他玩家的状态变化。这个数据包分为四个步骤读取，前三个步骤是“位打包”的，即按“位”读取，而非按“字节”。

  • 步骤1：本地玩家（自身）

    • 最节俭的情况： 如果玩家没有移动，也没有任何变化，那么它在更新数据包中只占1个比特位。
    • 移动一步： 如果玩家移动了一步，需要1位（表示有更新）+ 2位（移动类型）+ 3位（方向）+ 1位（是否有更多细节）。总共7个比特位，不到1个字节。

  • 步骤2：已追踪的其他玩家

    • 首先用8位表示需要更新的玩家数量。
    • 然后，对每个已知玩家，用1个比特位表示其状态是否发生变化。如果一群玩家都静止不动，只需用少量字节就能确认整个场景是静态的。只有真正移动的玩家才会消耗更多比特位。

  • 步骤3：新进入视野的玩家

    • 当一个新玩家进入视野时，服务器需要介绍他。这里使用了相对坐标。
    • 节俭设计3： 新玩家的位置不是用全局坐标（需要32位），而是用相对于本地玩家的坐标。由于可见范围有限（约15格），每个轴的坐标只需5个有符号比特位（范围-16到+15），总共10位，而非32位。

  • 步骤4：玩家细节变化

    • 这一步处理前几步中标记为“有更多细节”的玩家，例如装备变化、动画、聊天等。这部分是按字节对齐的。
    • 为何不继续位打包？ 因为这一步的字段（如“面对某个实体”）本身就需要2个字节，没有可节省的“空隙”。而且，这一步只处理少数有变化的玩家，位打包的收益很小。更重要的是，按字节对齐的数据可以被服务器缓存并直接复制到不同玩家的数据包中，而位打包的数据则无法缓存，会消耗大量服务器CPU资源。

总结：

• 一次完整的往返： 玩家向北移动一步，上行发送7字节的行走请求，服务器向其他玩家广播约9字节的更新数据包。总共16字节的往返数据，在5KB/秒的带宽下绰绰有余。

• 核心教训： 《RuneScape》的客户端和服务器并非两个独立系统，而是一个被TCP连接分割的单一系统。所有节俭设计都基于双方共享的、无需传输的共识：

  1. 双方使用相同的寻路算法和碰撞地图。
  2. 双方默认“无变化”是最常见状态，因此用1个比特位表示。
  3. 双方约定“可见”范围，因此坐标可以用更少的比特位表示。
  4. 双方共享一个固定的变化类型表，因此可以用位掩码代替模式描述。

• 现代启示： 这种紧耦合、位打包的设计并非过时产物。在那些“每个字节都至关重要”的场景（如竞技射击游戏、格斗游戏、金融数据流）中，这种设计依然被广泛采用。松散耦合、自描述的现代Web服务设计，是为了应对“独立部署”和“团队协作速度”的约束，而非带宽。选择哪种设计，取决于系统面临的核心约束是什么。

根据评论内容，总结如下：

主要观点与论据：

1. 技术分析质疑：评论1指出文章可能只是对Lost City代码库的分析而未提及来源，评论4质疑客户端发送路径点而非仅目的地的设计，认为服务器端路径计算可能更高效。

2. 历史比较：评论2、6、7、9强调RuneScape并非最早或最复杂的MMORPG，Ultima Online（1997年）、Phantasy Star Online（Dreamcast）、Lineage 2（2003年）等更早或更先进。评论3困惑于RuneScape在2004年与《魔兽世界》同期仍能获得成功。

3. 反作弊与作弊文化：评论5赞赏文章未深入反作弊机制，指出Jagex早在2005年就通过鼠标移动启发式检测机器人，并提及现代LLM可能模拟人类玩家。评论8批评社区对作弊（如RWT）的炫耀态度，认为缺乏自我意识。

4. 游戏复杂性：评论6认为Ultima Online比RuneScape更复杂，评论9提到Lineage 2的3D图形更惊艳。

关键引用（保留中英文）：

• 评论1："Is this article just an analysis of the Lost City codebase without linking Lost City?"
• 评论4："How come the client sends waypoints rather than just the destination?"
• 评论5："Jagex was banning bots based on mouse movement heuristics in like 2005."
• 评论8："cheaters in multiplayer gaming are regarded as the antisocial scum that make the game worse for everybody else."

平衡性说明：评论对RuneScape的技术实现、历史地位和社区文化存在分歧，既有肯定其早期反作弊创新，也有批评其技术局限和作弊风气。