GAMES104课程笔记19-Online Gaming Architecture Advanced Topics

这个系列是GAMES104-现代游戏引擎：从入门到实践(GAMES 104: Modern Game Engine-Theory and Practice)的同步课程笔记。本课程会介绍现代游戏引擎所涉及的系统架构、技术点以及引擎系统相关的知识。本节课主要介绍网络游戏架构的高级技术。

Character Movement Replication

角色位移同步(character movement replication)是现代大型网络游戏必须要实现的功能。由于网络环境的不稳定，玩家操作角色在自己视角和其他玩家视角下的行为往往会有一定的延迟，即角色在其他玩家视角下的动作会滞后于操作玩家的第一视角。

Interpolation & Extrapolation

在这种情况下我们可以使用内插(interpolation)和外插(extrapolation)两种插值方法来缓解延迟。

Interpolation

内插是指利用已知的控制点来获得中间的状态。当网络存在波动时利用内插的方法可以保证角色的动作仍然是足够平滑的。

在具体进行插值时还可以人工设置一个offset来保证buffer中有足够多的控制点，这样虽然会提高一些延迟但可以获得更加光滑稳定的插值结果。

当然内插也存在一些问题。由于内插加剧了网络延迟的问题，同样的游戏世界在操作者和其他玩家的视角下会有非常大的差别。这样的问题在一些延迟要求很高的游戏中可能是不可接受的。

Extrapolation

相比于内插，外插的本质是利用已有的信息来预测未来的状态。当我们对网络延迟有一定的估计时就可以通过外插的方法来推断角色的状态。

实际上外插的思想在很多领域都有非常多的应用，dead reckoning算法那就是外插在导航领域的实践。

Projective Velocity Blending

回到游戏领域的应用中来，projective velocity blending (PVB)是一种使用外插来更新角色位置的算法。假设\(t_0\)时刻角色的位置、速度和加速度分别为\(p_0\)、\(v_0\)和\(a_0\)，而收到来自服务器同步的位置、速度和加速度则是\(p_0'\)、\(v_0'\)和\(a_0'\)。假设\(t_0\)到\(t_B\)时间内没有意外状况发生，则\(t\)时刻角色的位置为：

\[p_t' = p_0' + v_0' t + \frac{1}{2} a_0' t^2\]

我们的目的是通过调整速度使得角色可以在\(t_B\)时刻到达位置\(p_d\)，因此首先对速度进行插值：

\[v_t = v_0 + \lambda (v_0' - v_0)\] \[\lambda = \frac{t - t_0}{t_B - t_0}\]

上式意味着对速度进行线性插值使得\(t_B\)时刻具有速度\(v_0\)。接下来再对位置进行线性插值即可：

\[p_t = p_0 + v_t t + \frac{1}{2} a_0' t^2\] \[p_d = p_t + \lambda (p_t' - p_t)\]

这里需要注意的是PVB算法并不符合动力学原理，它仅仅是一种插值方法。

Collision Issues

外插在处理碰撞时会容易产生严重的物体穿插问题。

要处理这样的情况一般需要切换到本地物理引擎来处理碰撞问题，比如说在看门狗2中就使用了这样的方法。

Usage Scenarios

简单总结一下，对于玩家操作角色经常出现瞬移或是具有很大加速度的情况比较适合内插，对于操作角色比较符合物理规律的情况比较适合外插，而在一些大型在线游戏中还会同时结合这两种插值方法来提升玩家的游戏体验。

Hit Registration

命中判定(hit registration)同样是现代网络游戏必须要提供的基本服务。以FPS游戏为例，从玩家开枪到击中敌人这一过程实际上有着非常大的一段延迟，在各种不确定因素的影响下如何判断玩家确实击中目标就需要一些专门的设计。

Challenges

命中判定的难点之一在于确定敌人在什么位置。由于网络延迟和插值算法的存在，玩家视角下的目标是落后于服务器上目标的真实位置的。

命中判定的另一个难点在于如何判定是否击中了目标。在游戏场景中目标往往是运动的，而且往往会位于一些掩体附近。当弹道不是瞬间命中时就需要一些额外的算法来进行判断。

Client-Side Hit Detection

因此命中判定的目标是保证游戏中的玩家就是否命中的问题能够达成一个共识(consensus)。目前主流的处理方法包括在客户端上进行检测，称为client-side hit detection，以及在服务器端进行判断的server-side hit registration。

在客户端上进行检测时的基本思想是一切以玩家客户端视角下的结果为准。玩家开枪后的弹道轨迹以及击中判断都先在本地进行，然后发送到服务器上再进行验证。

在服务器上会对玩家的行为进行一些验证从而保证确实击中了目标。当然在实际的游戏中这个验证过程是相当复杂的，涉及到大量的验证和反作弊检测。

在客户端上进行命中检测的优势在于它非常高效而且可以减轻服务器的负担，但它的核心问题在于它不够安全，一旦客户端被破解或是网络消息被劫持就需要非常复杂的反作弊系统来维持游戏平衡。

Server-Side Hit Registration

在服务器端进行检测的一个难点在于服务器上角色的位置和状态是领先于玩家视角的，当玩家开枪时目标很可能已经移动到其它的位置上了。从这样的角度来看，玩家很难命中移动中的目标。

因此我们需要对网络延迟进行一定的补偿。当服务器收到射击的消息时不会直接使用当前的游戏状态，而是根据延迟使用之前保存的游戏状态。

Cover Problems

对于掩体的问题，由于网络延迟的存在可能会出现射击者优势或窥视者优势的情况。

为了缓解延迟的问题在游戏设计时还可以利用动作前摇(startup frames)来掩盖掉网络同步。

类似地，也可以使用各种特效来为服务器同步争取时间。

MMOG Network Architecture

对于大型多人在线游戏(massively multiplayer online game, MMOG)我们还需要一些额外的网络架构设计。

MMO Architecture

MMOG中一般会有各种子系统来组成整体的玩法系统。

简单的MMO分层架构如下：

Link Layer

连接层(link layer)是玩家和游戏建立连接的一层。在MMO中为了保护服务器不受攻击，我们需要单独的连接层来分离玩家和服务器数据。

Lobby

连接到link layer后玩家会进入大厅(lobby)。大厅可以理解为一个特殊的游戏模式，从而方便管理等待进行游戏的玩家。

Character Server

由于MMO中玩家的数据往往非常巨大，玩家的数据一般会保存在一个专门的服务器上称为character server。

Trading System

交易系统(trading system)是MMO的重要组成部分，在设计交易系统时需要保证系统有足够高的安全性。

玩家之间的聊天和交互功能一般会通过专门的社交系统(social system)来进行实现。

Matchmaking

很多MMO还需要实现玩家的匹配。

Data Storage

数据存储(data storage)是MMO中非常重要的问题。不同于单机游戏，在MMO中玩家可能会随时下线但服务器则必须要保证一直运行。因此如何存储和调用数据是一个非常重要也非常困难的问题。

Relational Data Storage

关系数据库是最基本的数据存储方式，像游戏中玩家数据和游戏数据都会使用关系数据库进行存储。现代网络游戏中往往还会结合分布式的技术进行存储。

Non-Relational Data Storage

除了关系数据库外，非关系数据库也是目前非常流行的数据存储方法。像游戏中的日志还有各种game state就比较适合使用非关系数据库。

In-Memory Data Storage

随着游戏系统变得越来越复杂，在服务器运行过程中会产生大量的中间数据存储在内存中。因此我们需要一些内存数据管理工具。

Distributed System

随着玩家数量的增长，在单个服务器上支撑所有玩家进行游玩是几乎不可能的。在这种情况下就需要使用分布式系统(distributed system)来提供游戏服务。

分布式系统有很多自身的难点：

Load Balancing

负载均衡(load balancing)是分布式系统中非常重要的概念，我们希望在不同服务器上都有相近的负载从而避免某些服务器负载过大的问题。

consistent hashing是实现负载均衡的经典技术。它的核心在于为服务器以及玩家设计对应的hashing算法，然后把服务器和玩家映射到一个环上，当玩家需要连接服务器时只需要利用hashing值寻找最近的服务器即可。当某个服务器从圆环上删除时只需要把玩家连接到下一个服务器上即可，类似地添加新的服务器只需要在圆环上添加新的节点。