指数
第1部分：简介
第2部分：拓扑
第3部分：锁步和回滚
第4部分：异步服务器-客户端和日志补偿（即将推出）
第5部分：处理数据包丢失（即将推出）
第6部分：构建Netcode协议（即将推出）
在第1部分中，Netcode被描述为在不同机器上同步游戏状态和游戏事件的动作。 在研究这种情况如何发生之前，我们必须首先了解客户端如何相互连接。
“计算机相互连接的方式”称为“网络拓扑”，它描述了节点的特定排列以及它们如何连接和交互。 网络代码中使用的常见网络拓扑分为以下几类：
点对点
在对等网络代码中，每个玩家都与每个其他玩家连接，并交换游戏状态和事件。 在纯P2P方案中，没有一个玩家是“主机”，而是由每个客户端负责管理自己的玩家角色（或单位），同时接受来自其他每个游戏客户端的事件更新。
P2P的好处：
- 无需开发或运行任何专用服务器。
- 客户端彼此之间建立直接连接，这意味着网络的每个分支都是最直接的连接（这通常（但并非总是如此）会转换为低ping）。
P2P的缺点：
- 没有单一的权威主机，因此更难检查作弊，更不容易进行滞后补偿，并且有可能使客户端“不同步”，从而导致不同的客户端具有不同的游戏状态。
- 每个客户端建立多个传出连接并接收传入连接，因此每个客户端必须处理防火墙和端口转发。
具有权威专用游戏服务器的服务器-客户端
在服务器-客户端拓扑下，所有客户端（而不是彼此连接）连接到单个游戏服务器。 专用游戏服务器（DGS）运行游戏引擎并充当游戏状态的最终版本，接受来自所连接客户端的更新，将其合并到其游戏状态中，并将结果状态发送给每个客户端。
许多具有在线玩法的AAA游戏都属于此类别，其中游戏工作室负责服务器。 在某些情况下，服务器程序可以作为单独的程序使用，玩家可以下载并操作自己的服务器。
拥有在线持续世界的MMORPG和其他游戏也属于此类别。 在这些情况下，DGS还将包括存储有关持久性世界的数据的数据库。
DGS的好处：
- 服务器的游戏状态是“权威的”：它具有关于客户端生成的事件是否有效的最终决定权。 这样就可以实现各种各样的滞后补偿和反作弊机制，并且在服务器覆盖客户端时不存在失步问题。
DGS的缺点：
- 必须开发和操作专用的游戏服务器。 这具有与此相关的成本。
具有权威客户端主机的服务器客户端
代替使用专用的游戏服务器来维护权威的游戏状态，可以使用客户端计算机之一作为服务器。 该客户端成为客户端主机：同时是游戏会话的主机和参与游戏的客户端。
许多具有“网络多人游戏”模式的游戏都属于此类别，从而允许玩家主持自己的多人游戏会话，而无需连接或运行专用的游戏服务器。
客户主持人的好处：
- 与拥有DGS的好处类似，但是运行专用的游戏服务器没有额外的成本。
客户端主机的缺点：
- 主机必须执行更多计算才能同时运行主机职责和客户端职责
- 与其他客户端相比，本地连接的客户端与主机的延迟要低得多，从而具有竞争优势（称为“主机优势”）。
中继/配对服务器（具有非权威服务器的服务器-客户端）
这是在P2P和拥有DGS之间的一半。 在这种情况下，存在服务器，但其功能纯粹是为了促进客户端之间的连接和数据传输。 它没有积极参与游戏。
尽管仍然需要专用服务器，但由于它不需要运行游戏引擎，因此可以相对便宜地构建和运行它。 此外，大多数为P2P设计的游戏都可以轻松地转换为使用中继服务器，因为网络代码仅在客户端彼此连接的方式上有所不同。
依赖服务器的好处：
- 因为使用了外部服务器，所以客户端仅需要建立传出连接，因此不需要配置端口转发或防火墙
中继服务器的缺点：
- P2P的缺点相同，但由于连接不再直接，因此具有较高的延迟。
- 尽管比DGS便宜，但仍与操作中继服务器相关的成本较低。
大规模社交（异步游戏）
为了完整起见，值得一提的是大规模社交游戏。 在此类游戏中，玩家不会直接进行实时互动，而是会在持久的世界中拥有单人游戏体验，并且可以选择通过聊天，共享资源和“访问”机制与其他玩家进行社交互动要查看的其他玩家的游戏资产。 玩家无需同时在线就可以互动，并且离线玩家在下次登录时会收到有关他们错过的任何互动的通知（实际上，即使当时某个玩家在线，他们也可能不会收到任何其他玩家正在玩的指示。直到活动结束为止。
大型社交游戏往往具有更简单的网络代码，因为不需要处理同时和实时的玩家交互，因此不需要滞后补偿。 但是，像MMORPG一样，仍然需要运行专用服务器来处理游戏状态，并需要数据库来存储持久性世界数据。
当两个或多个客户端上的游戏状态不再匹配时，就会发生不同步。 举一个例子，考虑以下情况，这是在FPS游戏中发生的，其在非权威性P2P拓扑中的网络代码设计不当，发生在玩家1（蓝绿色）和玩家2（橙色）之间：
- 蒂尔（Teal）看到奥兰治（Orange）穿过屏幕进入十字准线
- 蓝绿色在屏幕上以完美的时机拍摄橙色。
- 蓝绿色的游戏会生成射击事件，并将数据发送给奥兰治
- 蒂尔（Teal）的游戏在本地处理射击事件，并确认命中，并将奥兰治（Orange）判定为死亡
- Orange的游戏随后接收射击事件，并在本地处理射击事件。 但是，由于延迟，蒂尔（Teal）的枪无法与奥兰治（Orange）对齐，因此投篮未中。
- 奥兰治在他们的比赛中还活着，但在蒂尔的比赛中却死了。 Orange的客户端仍将尝试将玩家的动作更新发送给Teal的客户端，但Teal的客户端无法接受动作更新，因为它们将应用于死角色。 此时，两个玩家之间的游戏状态已不同步。
在这一点上，两个游戏已经不同步，通常没有办法继续游戏，除非有一种方式可以将一个客户端的游戏状态视为事件的“正确”版本。
这称为“权限”。 当服务器或客户端被认为具有权威性时，它发送给其他客户端的更新或事件被认为是“规范的”（事件的真实顺序）。 即使与其他客户端中的现有游戏状态冲突，其他客户端也必须更新其游戏状态以与权威数据保持一致。
在上面的示例中，如果Teal的客户端比Orange的客户端具有权威性（就像在以Teal为客户端主机的客户端-服务器拓扑中那样），则Teal的客户端将负责发送点击确认，并通知Orange的无论橙色客户的想法如何，客户都知道他们的性格受到了打击。 或者，如果两个玩家都连接到专用的专用游戏服务器。 DGS将负责执行点击检查，并将结果公布给两名选手。
因此，权限可以防止不同步。 但是，可以看出，虽然它可以防止失步，但它却无济于事，它可以解决延迟带来的问题，延迟可能表现为看起来像完美的镜头缺失或明显的不良镜头击中。
进一步阅读：福雷斯特·史密斯（Forrest Smith）讨论了RTS和MMO游戏的不同步问题，其中包括《半神半人马》（A Demigod Tale）中特别难以发现的不同步问题-https://blog.forrestthewoods.com/synchronous-rts-engines-and-a-tale -of-desyncs-9d8c3e48b2be
在第3部分中介绍了使延迟影响最小化的可能解决方案。
