MMO与弱交互游戏的服务端技术区别

一元

　　文/小说君（微信公众号“说给开发游戏的你”）

　　MMO只是一个泛指，现在很多游戏表现形式不是MMO实际上都是MMO。除了梦幻大话剑侠情缘这种的一看就是MMO的之外，像COK这种的实际上也都是MMO。

　　弱交互游戏同样是一个泛指，在几年前的时候特指异步交互的卡牌游戏，现在可以用来指一切交互有限的手游，比如所有围绕推图做的arpg/动作卡牌，以及社交游戏。

　　那这两大类游戏的游戏服务端在哪些方面区别呢？

　　简单地说就是逻辑的复杂度。

　　我们对游戏服务端的最简单的认知就是将其看作一个状态机。

　　就状态机的复杂度（状态的数量级）而言，MMO游戏（特别是端游MMO）的场景服务器的逻辑复杂度是弱交互游戏（包括社交页游和一切服务端不维护场景状态的手游）无法比拟的。

　　列举几个具体的：

　　移动同步

　　移动同步相关的逻辑是许多MMO端游程序员的优越感之一，君不见各种媒体上发声的业内大佬们特别喜欢说MMO手游具有技术门槛，没技术的团队做不了。其实他们如果真的不是指场景制作流程上的难度，那就是在说移动同步小团队做不了。

　　实际上，移动同步除了各种自以为是的猥琐得不能再猥琐的（猥琐部分的代码量相当大）特殊的优化表现的技巧之外，再无技术可言。

　　场景状态同步

　　MMO游戏与其他游戏服务端的一个显著不同就是大部分场景状态是在服务端维护的，因此会有一个时间驱动的主逻辑在这里。场景状态包括各种怪的逻辑，玩家的定时器等等。而且由于MMO的一个场景中会有复数个玩家，场景的状态需要同步给玩家，但是不能每帧都全同步。于是就有了MMO特定的一些优化技巧，比如AOI。

　　这部分要说有技术含量吧，确实也有。但是原理简单，需要的人天也少。因此大多数MMO程序员是接触不到的。

　　切进程

　　MMO游戏最典型的一种需求是玩家从一个地方移动到另一个地方，这两个地方假设在服务端属于不同的场景，那就需要服务端处理一下将玩家的上下文从一个场景迁移到另一个场景的逻辑。这部分逻辑算是比较复杂的了，也会涉及一些包序列、包过期的问题，虽然大概想想不是特别难，但是具体实现上坑比较多。也是MMO的一个特点了。

　　然后我们再回头来看弱交互游戏，处理循环基本可以简化为：一个request上来，经过一定节点路由，路由到一个逻辑节点，逻辑节点从一个地方（可以是进程内，可以是从缓存）取一下玩家数据，处理一下，存回玩家数据。

　　这就是两者大概的区别了。

　　但是，相信各位跟编者一样，在很多jd中看到指明需要大型端游开发经验，这样一想，做弱交互游戏的服务端程序想转型去做MMO游戏的服务端程序岂不是非常艰难？

　　实际上，写出这种jd是一方面，还是要具体看招聘方对候选者的需求是什么。

　　MMO游戏的战斗逻辑是非常复杂的。比如技能逻辑、怪逻辑、结算逻辑，策划面向程序的需求迭代最频繁的部分基本都是围绕这些点展开的，而这些点说实话还是比较业务逻辑狗的，通常有经验有追求的干一段时间这个就不想维护了，要么想走人找更好的岗位要么想培养接盘侠，所以社招的时候肯定需求有过相关经验的程序。但是这一块经验往往需要做过MMO游戏，所以如果想招做战斗模块的服务端这样写并没太大问题。

　　但是对于另一种招聘需求，就是做服务端的性能优化相关的，或者说维护一些比较独立的全局系统，其实跟做什么游戏类型是没太大关系的。要求无非就是操作系统网络什么的老几样。当然最重要的是定位问题、解决问题的能力。

　　而且MMO游戏的服务端由于重点关注的是逻辑复杂度，其实分布式这个方向上发展的不如弱交互游戏，后者的服务端转过来理论上讲应该不会特别适应。当然两边都是写逻辑的话，转来转去没什么本质区别。

相关阅读：游戏服务端究竟解决了什么问题？

san_moshou

倒数第三段话，都不知作者想表达啥

Alux

贴主所谓的战斗逻辑、技能逻辑、怪逻辑、结算逻辑等等实现都是与系统整体架构密切相关的，只有通过对复杂整体网游系统架构的仔细学习，做到了然于胸，才会对这些逻辑的编写轻车熟路。