《天涯明月刀》服务器端3D引擎设计与开发
一、前言
随着用户对游戏品质需求的提升，MMORPG作为网络游戏中最重要的一种类型，也在潮流中不断的进化着。现在，网络游戏已经从之前的2D，2.5D时代，进化到了全3D时代。玩家可以在游戏中自由的轻功跳跃，飞行，上墙进屋，MMPRPG的玩法与体验得到了进一步的提升，更加接近于虚拟现实。
全3D时代的网游，对于网络游戏服务器提出了新的挑战。
面对新的需求与挑战，天涯明月刀项目在服务器端另辟蹊径，在提供不输于2D系统的性能的前提下，实现了一套全3D且逻辑安全的服务器端引擎。同时实现了性能，精度，安全三者的兼顾与平衡。
二、技术背景/业界现状
在客户端引擎方面，经过多年的发展，虚拟3D世界的构建已经有着较为成熟的技术。现在市场上有多款成熟的商业引擎诸如CryEngine，Havok，Gamebryo等可以借鉴与使用。
但是在服务器端，MMOPRG服务器无论是从用户模型，硬件现状，以及业务形态都与客户端有着巨大的差异：
a) 、硬件支持有限
服务器硬件少有像GPU类似的专用图形图像计算单元，只能依赖于CPU进行计算。CPU的浮点运算能力远远低于GPU
b) 、完全不同的业务模型
一般而言，MMORPG客户端需要同时精确计算的对象局限在较小的空间范围内（诸如九宫格视野范围内），数量较少，服务器必须接近实时地计算世界内的所有玩家所处的位置与状态
c) 、更多的计算需求
在单个svr进程上需要支持3-4k玩家同时进行游戏；
目前业界中，服务器端的3D解决方案有如下几种：
1) 、多边形网格（Polygon Mesh）
图1：基于Polygon Mesh的3D场景描述
将客户端的引擎移植到服务器端
优点：
精度高：可以做到与客户端相同的精度表示
缺点：
计算量大：碰撞计算非常消耗CPU
资源量大：需要在服务器端导入大量的美术资源
开发难度大：要讲通常跑在客户端的引擎代码移植到服务器端，迁移成本较高
结论：
l 性能上无法满足MMORPG大世界的承载需求
l 可以通过增加机器的方式对性能需求做出一定的缓解，但是会拉高整体的运营成本
l 通过降低精度可以缓解计算压力，但是精度不再的话就丧失了唯一的优势
2) 、多层网格（Layer Gird）
图2：基于 Grid Layer的3D场景描述
通过添加多层扩展传统的服务器2D网格场景描述
优点：
计算量小：无需计算复杂的碰撞，只需检查网格碰撞即可
开发难度小：大部分的2D行走逻辑可以继承，只需要在切层时做额外处理
缺点：
资源生成困难，描述能力不足：
复杂建筑用层来分割非常困难，数据生成难度很大。
如下图：
上图中循环上升的回廊，回廊在不同高度上究竟属于那一层？
重叠的部分理论上应当属于不同的层，但是按照多层网格数据格式的定义，又应该属于同层。在描述上会出现矛盾的尴尬境地。
上面的例子很实际的说明了多层网格的描述能力是有限的，而且遇到复杂建筑的时候，如何正确的描述建筑规格，会遇到很大的困难。Case by Case的解决也无法完全消除问题，而且效率很低。
精度较低：由于采用固定规格的格子大小，在描述一些形状较小的复杂物件的时候会存在精度问题。
结论：
l 性能上可以满足承载需求
l 数据制作难度过大，且存在描述能力不足的问题，无法满足内容制作需求
三、设计方案
3.1、Voxel概念的引入
Voxel即体素（Volum Pixel）的简称。Voxel体素的概念是从二维空间的最小单位像素衍伸而来。像素用于描述二维的影像，是二维空间上的最小单位。而体素则可以用于描述三维空间上的立体的对象，是三维空间分割上的最小单位。
图3： Pixel 描述的二维图像
图:4：Polygon Mesh描述的三维对象
图5： Voxel描述的三维对象
Voxel描述相较于Polygon Mesh的优势在于：
性能
Voxel本身是规格化的，无需使用浮点数运算，避免了服务器CPU浮点运算能力的瓶颈。
通过合理设置精度范围（Voxel的大小），可以大大降低服务器的计算频率，减小计算压力，同时保持比较好的C/S同步。
资源
相比Polygon Mesh，资源描述简单，服务器使用规格化的数组即可描述，加载，解析，存储都很方便。
开发难度
Voxel本身就是在2D基础上的概念扩展，从2D系统迁移到Voxel系统的过程中，迁移成本较低。且其中原有3D系统阻挡Mask的概念还可继续沿用。
如何用Voxel来描述复杂场景，让我们在下一节详细展开。
3.2、 基于Voxel的3D场景描述
使用Voxel对场景进程3D描述的具体方案如下：
l 将3D场景以Voxel为单位进行离散化描述
l 以 (x, y, layer) 三元组对场景描述voxel的位置进行定位
l 以 (x, y, z, layer) 四元组描述移动对象在空间的位置
l （layer为冗余量，用于快速定位同一垂直投影上的Voxel对象）
l layer = 0 的voxel为地表层，voxel记录上沿（upward）高度
l layer > 0 的voxel为建筑层，voxel记录上沿（upward）与下沿（downward）高度
图6：室内室外场景Voxel描述剖面图
图7：拱桥Voxel描述侧视图
上面的Voxel示意图中，绿色的Voxel为0层，黄色的为1层，蓝色的为2层。
可以看到，视觉上处于同层的蓝色与黄色，实际上是处于不同的逻辑层上的。也就是说，在Voxel方案下，层的概念只在水平grid的垂直投影面上才有意义。相邻的Voxel之间，层id相同，并不表示联通/或相接，因此，原有的行走检测算法已经不再适用，需要引入基于Voxel的碰撞检测算法
图8：天涯明月刀场景常规视图
图9：天涯明月刀刀场景Voxel视图
3.3、基于Voxel的碰撞校验算法
通过对玩家在游戏世界中的移动行为进行研究，我们可以划分并得到两种行为模式:行走与轻功。
3.3.1、行走
玩家在行走时，脚步不会离开地面。用voxel的视图来表述的话，玩家的移动就是在不同voxel之间切换，且玩家的高度（z轴坐标）始终是当前所在Voxel的上沿的位置。
既然玩家的高度是由所在Voxel确定的，那玩家在行走的过程中，其实是不用处理高度信息的，以(x, y, layer)三元组即可描述/处理玩家的移动路径。
3.3.2、轻功
轻功过程中，玩家的脚步脱离了地面，即玩家的移动不再限制于Voxel的上沿表面。此时，需要(x, y, z, layer)四元组来描述/处理玩家的移动路径。
通过对于移动模式的分解，我们可以进一步细分碰撞模型：
3.3.3、行走
行走的碰撞校验步骤为：
1、 Grid Mask判定
Ø 检测Voxel对应的Grid Mask
Ø 静态阻挡、动态阻挡、水面阻挡等
2、 高差判定
Ø 相邻Voxel的高度差是否在合理范围内
Ø 高差判定的方向性：
Ø 从高处可以往地处走无需考虑高差
Ø 从低处往高处走，需要考虑高差，太高走不上去
3、 碰撞判定：
目标Voxel之上的高度空间是否能容纳移动对象
经过这三步，就可以完整的判定移动是否合法。下面是流程示意图：
图10：行走逻辑碰撞判定规则
3.3.5、轻功
轻功的碰撞检测步骤为：
1、 Grid Mask判定
Ø 检测Voxel对应的Grid Mask
Ø 空气墙，动态阻挡
2、 碰撞判定
Ø 目标Voxel上的空间是否可以容纳移动对象
Ø 移动路径前方是否有Voxel阻挡
图11：飞行逻辑碰撞判定规则
图12：碰撞判定示意图
3.4、服务器端3D引擎构架
通过封装3D场景管理数据读取以及碰撞算法，天涯明月刀server形成了一套完整的以voxel描述数据为核心的服务器端3D引擎构架。
示意图如下：
图13：服务器端3D引擎构架示意图
3D场景引擎：
Ø 数据管理模块位于最底层，提供了基础的地形碰撞信息读取接口。
Ø 在底层Voxel数据管理的基础上，实现了多层Layer的管理。
Ø Voxel数据与Layer Patch（详见下文）数据统一放置到场景数据管理器之下。
Ø 碰撞校验API以及场景数据API访问场景数据，并向上层提供服务。
Ø 同时提供一套运动计算引擎，封装了常规的运动计算公式的实现，可以供上层移动逻辑调用。
移动控制模块：
Ø 提供行走，轻功，拖拽等多种方式的移动模型，可以充分满足业务逻辑的开发。
业务逻辑：
Ø AI，玩家移动以及技能位移作为最上层的逻辑，直接调用移动控制模块提供的接口即可，无需关心底层实现，简化了一线业务开发的工作量。
四、性能优化
在之前的技术方案评估中，已经论证了Voxel方案比起Polygon Mesh方案有着较大的性能优势，但是相较于之前的2D移动方案，性能还是有大幅度的下降。
为了实现单进程3-4k玩家数的承载的目标，从用户模型与数据特性出发，我们对Voxel方案进行了细致的优化，最终实现了和2D移动方案下相近的性能。
4.1、时间优化
4.1.1、多层索引Cache（Layer Mask Cache）
图14：多层索引示意图
要点
碰撞检测算法中存在大量指定(x,y)，获取此grid垂直投影面上所有层信息的操作。经过统计此处操作函数为热点函数，且占用了大量的cpu时间。
针对这个问题，可以通过预先生成并缓存layer mask，在运行时访问layer mask缓存，即可快速定位并获取grid垂直投影面上层的信息
副作用：
内存消耗增加，地图大小为4km x 4km，且每个voxel平面大小为50*50的情况下，需要额外占用64M的内存
4*1024*100 / 50 = 8192; // 地图以voxel为单位的边长
8192 * 8192 = 64M // 整体内存占用
与不优化的情况相比，单张地图资源内存使用增长了15%左右，从整体性能trade off来看，还是划算的。
4.1.2、连通性Cache（Connectivity Cache）
图15：连通性cache示意图
要点
为了美术数据制作限制，导致出现穿墙等行为，在3D引擎内部，移动对象的连通性判断限制为在相邻grid之间的四方向之间进行。外部传入的路径会经过转换生成一条在四方向之间进行移动的路径。
通过仔细分析我们可以发现，相邻grid之间，同一个方向上，从src层只能切换到一个唯一的dst层，即相邻grid之间的连通性是唯一的。
由上面的分析可以看到，决定连通性条件都是静态的，在运行时进行碰撞检测来计算连通性，实际上存在大量的重复计算。
同时，经过统计，90%以上的地表只有0,1两层，我们只需要对这两层的碰撞判断做针对性的优化，即可覆盖绝大部分的计算。
综上，我们提出了一套基于联通性Cache的优化方案：通过预先计算碰撞信息，生成全图的连通性Cache，在运行时直接访问Cache获取连通性信息，避免重复计算，可以极大提升运行性能
优化效果
Ø 相邻Grid连通性碰撞检测平均时间消耗从2000 CPU周期降低至200
Ø 场景服务器整体CPU消耗降低30% (单进程3000人在线战斗 + 移动)
副作用
内存消耗增加，4km x 4km 的地图需要额外占用128M的内存。
与不优化的情况相比，内存使用增长了30%左右，虽然在时间优化方面有了非常大的提升，但是将压力转移到了内存空间使用上，下面我们会针对这种情况做进一步的空间优化。
4.2、空间优化
天涯明月刀刀的地图大小是同类游戏中最大的（4km x 4km），按照之前定义的Voxel模型，我们可以推算一下，每张大地图的内存使用量：
Ø 大地图面积：8192 * 8192（4 km）
Ø Mask+上下沿高度： 5 byte
Ø 全图最高建筑层数：8
Ø 场景地图数：8
Ø 单张地图所需内存：2.5G
所有地图需要内存：2.5 * 8 = 20 G !
除此之外，还需要加入之前因为时间优化需求而加入的各种cache数据，对内存的需求会进一步膨胀，这显然是无法接受的。为此我们必须要展开内存使用优化。
4.2.1、多层补丁（layer patch）
首先我们观察到，地图大部分都是野外(0层, 90%)，只有城市中才存在多层建筑。这种情况下，0层以上大部分的数据都是空的，没有这部分内存被完全浪费掉了。
基于这样的数据特性，我们提出了多层补丁（Layer patch）的数据组织方案，来实内存优化。
多层补丁，即为0层以上的地形，不已全图的形式展开，而是以补丁的形式存在，有数据的地方才有补丁。诸如下图：
图16： Layer Patch示意图
layer 1可以简化为两个patch，layer 2可以简化为1个patch，数据量大大降低，从而节省了更多的内存。
优化后：
Ø 0 层： 8192 * 8192 * 3 = 192M
Ø 2 个patch层，每层有100个patch，每个patch大小是 50m * 50m
Ø 100*100*5*100*2 = 10M
Ø
单张地图所需内存 200+M
通过layer patch的优化，显著降低了内存使用量，使得方案达到了可用的程度。
4.2.2、多进程地图资源共享
在天涯明月刀超大地图的设定下，经过patch优化后，单场景服务器内存使用依然达到16G（其中地图6G）。如此一来，B6机器只能支持部署3个场景服务器（scened），而B6机器上有12个计算核心，多核计算资源被大量浪费。
然而仔细分析，我们的多个scened进程其实都是是同构的，其中的地图数据也是相同的，且这部分数据都是只读的资源数据。在同一台物理机上的多个scened各自都加载了一份庞大的地图数据，如果能把这部分数据做成共享的，那我们将节省出大量的内存资源。
在这样的情况下，我们提出了一套多进程资源数据共享的方案：
图17：多进程内存共享示意图
优化方案：
Ø 将资源数据从单个场景各自加载改为统一加载至共享内存中
Ø 各个场景服务器attach至共享内存，使用同一份数据
优化后：
Ø 单机整体内存占用下降30%（3 scene 部署情况下）
Ø 5 scened机部署可以改为单机部署
4.2.3、开发模式地图资源按需加载
天涯明月刀团队有着140人的规模，针对大项目组多人协作的情况，我们设计了一套完整的服务器私服部署/版本分发体系，力求项目组中的每个人都可以拥有一个自己可以控制，调配的私服，实现无干扰的高效开发。
但是我们的场景进程在dev模式下内存需求达到14G，导致B6机器只能支持部署3组私服，140人规模团队，私服需求巨大。目前我们有12 台vb4，6 台A5，2 台B6作为私服，但是还是无法有效满足团队需求，内存紧张一直困扰着我们。
针对这种情况，我们针对dev模式设计了一套地图数据按需加载模式。
地图数据按需加载，dev模式启动时只加载一张默认地图。采用先全量加载，再释放冗余地图的策略，保证资源校验的完整性。然后在发生传送/进入新地图事件时，按需动态加载地图数据。
优化结果：
Ø 单scene内存需求下降至8G
Ø 以20台左右服务器支撑起100余套私服
Ø 有效支持全项目组的日常开发工作
Ø 解决以后新增地图情况下私服内存紧张问题
Ø 为公司节省大量dev-net机器资源
4.2.3、性能基线
最终的优化完成之后，我们实现了单个进程支撑3000人同时移动下场景服务器压力维持在20%以下的目标。
图18：服务器移动性能基线表
五、结语&挑战
通过这套服务器端3D引擎，有效支持了天涯明月刀的玩法与功能特性开发。且为工作室日后的新项目提供了开发与借鉴的基础。
但是不足之处还有很多，在未来的日子里，sever组会进一步强化引擎的功能，以在玩法开发方面提供更多的支持。
未来可能会考虑引入可变精度的Voxel来实现更高精度的场景需求；同时也会实现动态建筑建造与升级等功能，还请大家拭目以待！