Go游戏服务器开发的一些思考（四）：综合考察（下）

（接下来的内容，大部分都是纯逻辑问题，与语言没有多大关系。Go语言的作用就是利用它的语言特性，提供接口来应对变化）

世界场景搭建

Cell服务器

拆出Cell服务，是业内公认的。MMO RPG最核心的玩法就在Cell上，是最吃CPU和最占网络带宽的地方。只有把它拆出来，才有横向扩展的可能。

何为世界

为什么突然来个这么哲学的问题 = =|

因为你看世界的角度不同，你的活法也不一样 + +| (居然还是这么的哲理)

因为不同的世界，会有不同的后面章节的实现。如果能提前考虑这个问题，那么有可能，让你做的游戏服务器可以适配更多的具体应用。

房间集合即为世界

你可能玩过《球球大作战》、《贪吃蛇大作战》、《射箭大作战》。游戏以房间为单位，背景是一片空地。通常人们是不会把这些游戏归类到MMO RPG游戏中的。

如果你能换个角度考虑问题的话，那么一个个房间是不是等价于MMO RPG中的一个个副本，房间内的空地是不是等价于没有障碍物的地图呢。

同时如果你仔细分析的话，还有更多相同的东西。比如 进入房间的流程和进入副本的流程；2者游戏对象属性同步的机制也可以是一样的 等等。

不同的地方在于，他们的 移动算法、寻路算法、AOI算法可能是不一样的，不同的玩法，会做不一样的算法实现

这里列举这个例子，目的不是要 我们做世界场景构建时要兼容这种游戏类型。而是在开发这些功能时，应该要足够的模块化，并提供开关设置。在我不需要它的时候，可以直接关闭它，不会污染其他功能、代码。

只有这样才会让引擎框架有更多的可用性、可插拔性。

tile-based 的世界

在 3D游戏出现之前 都是这种 基于格子的世界。即使是现在，3D游戏盛行，还是有非常多的游戏服务端，采用这种方式来构建世界。原因就是对一些游戏来说，它已经满足了玩法的需求。且相关概念算法比较成熟，资料容易获得。

应当合理的设计接口，如提供：

onSceneCreate

onSceneDestroy

onEnterScene

onLeaveScene

这样具体应用可以针对这些接口做些特殊的处理

NavMesh 构成的世界

目前貌似 go 相关的 NavMesh的资料不是很多。比如在github上搜索下，只有1个 4stars 的go 项目：

https://github.com/mrazza/gonav.git

另外一种可能，Go语言调用NavMesh DLL。暂不考虑。

因此使用 Go语言开发游戏服务端，先不考虑使用这种方式构建世界。

移动、寻路及同步

这里假设，世界是 tile-based的世界。由于使用Go语言开发，正常来说需要复刻一次这些功能

astar寻路

直接上github地址：

https://github.com/beefsack/go-astar.git

移动及同步

可以参考成熟项目的移动算法，这里罗列一些要点

保持2端在某个方向上的位移计算算法一致

服务器端每100毫秒更新移动对象。但不需要与客户端做位置同步

服务器端在移动对象 方向发生改变、或者速度发生改变时，则必须与客户端同步

服务器端每5秒可以主动同步一次客户端

astar算法产生的点，都是方向不再一个方位上的，因此与上面的要点是完全统一的

想要平滑的移动同步效果，客户端也要针对可能出现的渲染、网络不稳定，做相应的优化措施。比如目前比较流行的，会把一个对象分成 数据部分 和 渲染部分， 让渲染部分做插值追赶 数值部分。

提供接口

如，

onMoveStart

onMoveStop

onMoveDirChange

onEnterColloction

onLeaveColloction

AOI算法实现

暂略，比较复杂

辅助功能介绍

自动构建（略）

单元测试

首先需要养成 一个功能，需要写好充足的测试用例 的习惯。它不仅能用于测试你代码的正确性；同时可以作为这个功能的例子教程

Go语言 提供了一个 go test 机制，来定义用例抛出错误。

因此可以在自动构建上，最后去自动执行 单元测试。若单元测试不通过，必然 本次自动构建会失败告终。自动构建可以通过邮件告知程序员

部署及监视

调试演示

应该提供非常编译的调试控制台，方便服务端程序，在与客户端联调前，做好充足的调试。

同时，应该提供可视化的服务器端窗口工具。这样即使脱离客户端也可以把某个流程调试完整。