Spatial OS的MMO游戏架构是不是革命性的？

是的。

我们从设计（玩法）、技术（架构）和效率（工业化）三个方面来聊聊为什么SpatialOS对于MMO 是革命性的。

一、设计（玩法）

如果大家打开Steam，可以看到它的在线玩家统计数据：

我截取了前20多位的游戏，它们大都有这两点共性： 多人在线，动作射击 。

也许有人会问，这些打枪游戏跟MMO有什么关系呢？事实上，这些游戏的大量在线人数被分散在了不同的房间里，广义上来讲，也是MMO。接下来我们会用房间型MMO来代指它们。
近年来在房间型MMO的发展过程中，有这样一种趋势：一个房间内能够容纳的玩家人数，是在逐渐增加的：

PUBG的出现搅动了市场：支持100人同局的PvP游戏出现了！更多玩家同局不代表游戏更好玩，但是， 在玩家人数这个维度上的解放，的确会给游戏设计者提供更大的发挥空间 ，是可能创造出全新的游戏方向的。

当然，和传统型MMORPG相比，目前房间型MMO的同服人数简直不值一提。但反过来，这些房间型游戏所提供的交互程度，也是传统型MMORPG无法做到的。 多年以来，两者走向截然不同的方向 。但是，当传统型MMORPG不再满足于往一组服务器里放更多玩家，而希望加入更丰富的交互；当房间型MMO的人数因为引擎的限制难以继续突破；当玩家不再满足于市面上的同质化游戏时，新的游戏类型，以及与之相配套的技术就是水到渠成了。

二、技术（架构）

接下来我们从技术角度分析一下，为什么传统型MMORPG做复杂的模拟和交互比较难，以及房间型MMO的最大人数是如何受引擎限制的。

传统型MMORPG的后端，一般是自研引擎，历史久远，坊间戏称「祖传代码」。而前端，这些年逐渐走上工业化的路线，开始使用Unity、虚幻等主流引擎。所以前后端开发的技术栈，甚至开发语言，都逐渐走向了分裂。主流引擎中自带的成熟的物理、AI等技术，不能直接运用到后端，需要单独实现。像物理这种前后端都可能模拟的系统，还需要考虑如何与引擎的版本做兼容。所以从成本角度出发，后端就干脆不做。

前后端分别开发的方式，还带来了通信协议、业务实现逻辑前后端版本不一致的问题。笔者曾
经就深受其害，这里就不一一赘述。

另外在传统型MMORPG使用的三层架构中，兴趣管理（广播）是在连接层实现的，但是连接层没有状态数据，客户端只能基于频道（Channel）去订阅消息，但是无法做更细粒度的订阅或兴趣变更。比如，玩家在打开瞄准镜的时候，变为订阅长锥形视野范围内的对象信息，这个在三层架构里怎么做呢？必然要在场景服增加大量的业务代码。场景服中状态和模拟（业务逻辑）的耦合又带来了新的问题：跨服逻辑的实现。

还是刚才瞄准镜的例子，如果瞄准的区域不在玩家所属的场景服务器，这个区域的对象信息怎么发送给瞄准的玩家呢？这时候就需要场景服务器之间发送消息。这种解决方法除了增加了实现复杂度，还增加了延迟（消息返回到客户端的总时间），在瞄准镜这种对延迟要求高的应用场景，玩家体验会比较差（对象不能及时出现或更新）。

综上， 传统三层架构在一些实现主流动作射击游戏中的复杂模拟，成本高，实现难，或者效果不好 。

那么SpatialOS是怎么解决这个问题的？首先，它把状态数据和兴趣管理都放在同一层，然后配合QBI，开发者可以自由地定义兴趣范围、状态类型，以及频率。兴趣范围包括立方体，球形，圆柱体等基本形状，并且可以组合查询。兴趣定义好之后，客户端就会持续从网络层直接收到变化的状态。更妙的是， 服务端也可以使用QBI来订阅兴趣 ，来管理形状不规则，甚至是动态改变的地图区域。

SpatialOS的网络层本质上是个分布式的内存数据库，所以它也可以实现持久化。可能有人会问，连接、兴趣管理、持久化你们全做了，我们开发者还需要做什么啊？答：游戏模拟。角色的行走跳跃、物理系统、NPC的AI，这些跟游戏玩法密切相关的逻辑。 我们努力把开发者从分布式网络的复杂性中解放出来 ，甚至我们认为，开发者不应该在刚开始设计游戏时，就受限于网络系统能容纳多少玩家或NPC等计算。这些指标应该 像那些基于云的互联网系统能做到的一样，是可以方便扩容缩容的 。

而房间型MMO的计算量受限，是因为它们的后端跟前端一样， 是单进程的，无法受益于分布式的架构 。那么开发者在设计之初，就要经常面临的困境是，好，我们就做100人的玩法，然后做着做着想加点AI进去，然后发现服务器帧率掉下去了，这时候要么砍玩法，要么砍最大在线人数，还有第三条不归路：魔改引擎。

三、效率（工业化）

我们相信游戏开发者是有能力实现SpatialOS做到的一切——比如把状态管理放到连接层，比如引擎的定制，甚至说，自己从头开发一个包括前后端的游戏引擎。但是，能做到就一定值得做吗？纵观游戏行业近年的发展，Unity和虚幻游戏引擎的普及代表了一个信号： 游戏的开发，至少是游戏前端的开发，正在工业化 。开发者不必再需要从头搭建游戏的基础框架，甚至不需要掌握多少渲染管线、网络通信等底层知识，就可以创建出游戏了。换句话说，让游戏开发者用更快的速度做他们更擅长的、想要快速迭代实现的玩法和内容，把其它交给第三方来开发和维护。

引擎的维护是工业化过程中， 产品向服务过渡 的一个绕不过的问题。功能交付给用户（引擎使用者）后， 版本的兼容怎么实现？功能的交叉集成谁来做？ 一个典型的例子就是虚幻引擎的专用服务器（Dedicated Server）。它早已不是一个单纯的网络后端功能了。如果仅仅是提供网络通信层和基本的属性复制（Replication）加上远程过程调用（RPC），是难以帮助开发者跨过网络游戏开发的重重门槛的，所以虚幻引擎还对角色移动等组件进行了深度集成，使开发者 开箱可用平滑的移动同步、延迟补偿、刚体插值同步等功能 。更厉害的是，每当虚幻引擎推出大的特性，比如Gameplay技能系统和Chaos，它都会考虑为其进行网络功能的整合。

所以我们可以想想 为什么像PUBG和ARK这样的游戏，最早是诞生于虚幻引擎 ，运行在专用服务器上，恐怕不光是虚幻引擎的前端表现力更好吧？它简直就像一个房间型MMO的孵化器，越来越多的创意会越来越快地诞生出来。当然，很快创意就会碰到玩家人数和模拟性能的壁
垒，之前已经提过，这里就不再赘述了。

当我们和开发者谈SpaitalOS的时候，我们会在创意赋能之前，谈到一个更重要，更实际的点： 风险管理 。我们认为这也是提高整体效率的关键。我们希望开发者在火力全开时没有后顾之忧，所以我们从一些比较成熟的行业借鉴了工业化的思路，用工具和流程来帮助开发者降低风险。

比如网页开发中早已成熟的迭代方式——你申请一台云服务器，把你的PHP脚本放上去，就可以直接把链接发给朋友进行测试了。之后你每做一些修改，都可以很快地重新走一遍这个流程， 去验证你的修改是否能达到预期。当你的测试达到一定规模，一台服务器支撑不住的时候， 云平台的横向扩容和负载均衡 功能让你弹指之间就能让你的负载上升一个数量级。

我们再对比一下游戏行业传统开发方式——首先你会在开发的很长一段时间里使用内网服务器做测试，所以你工作室外的朋友，或者潜在成为最核心粉丝的玩家，都接触不到你的游戏，更不要说反馈和迭代了（当然我们也可以用「保密」来解释）。然后游戏要进行小规模的对外测试了，你需要找一个机房，租一台机器和带宽。这个时候 后端运行的硬件和网络环境都发生了变化 ，如果你没有进行充分的适配和测试，这次对外测试就面临着从网络延迟高体验差，到玩家连不上，甚至后台程序崩溃的风险。接下来对外测试的规模越来越大，每次你都会面临同样的风险，流程好的就提前适配和测试，让技术来填坑；流程差点，就给玩家道歉补偿，让运营来填坑。那我们能不能让这个坑一开始只用趟一遍呢？

对比网页开发的迭代模式，我们需要补上的技术栈有：基于云的一键式上传部署；可配置的扩容方案；基于云的分发下载和A/B测试方案，以及基于云的日志和性能监控工具。这些我们都会在第一天就免费交付给开发者去使用，并持续维护。

四、总结

综上，从设计上来讲，我觉得未来MMO的趋势是目前房间型MMO和传统型MMORPG的结合；从 技术上看，SpatialOS通过分布式引擎后端的方式，实现了高在线人数和高保真度的结合，使设计成为可能；而放眼游戏工业化的浪潮，革命性的MMO也需要革命性的工具赋能，降低成本和风 险。

在这个下一代MMO呼之欲出的时代，作为一个玩家，也希望开发者们能破除禁锢，早日开发出更多好玩的MMO。

如果想要详细了解SpatialOS的技术和功能，欢迎查看SpatialOS官网。