传统 MMORPG 通讯模式实现的一点想法
既然 MMORPG 都有千篇一律同质化的趋势，好歹我们技术人员也应该总结出点东西来，新项目开发可以用现成的模式。
一般来说，MMORPG 服务器要解决的问题无非是，同步玩家的位置，状态，把这些信息广播出去（细分的话，有非战斗环境和战斗环境）；需要建立一个聊天服务，供玩家文字交流；有一个信息发布渠道；有任务 NPC 和玩家一对一交流；玩家调整自己的装备（也可以看成是和一特定 NPC 交流）。
以上，我们可以看到几个基本需求是可以正交分解出来，并有不同的实现方式的。
同步玩家的状态，基本上是由玩家自己不断提交自己的最新状态，然后由服务器把这些信息广播给其他人。
聊天服务比较成熟，基本上就是玩家订阅聊天频道，并按权限向频道内发布信息。
信息发布可以看成是一个特殊的聊天频道。
任务 NPC 或是整理自己装备，都类似于向特定节点做请求等待回复。
我经历的几个 MMO 项目都实现的比较简单，无论是 server 还是 client ，都是跑一个消息循环，对每个到来的消息包进行处理。通常都是一个 timer 消息源和一个网络包消息源，共同组成最终的消息源，主程序是标准的消息循环分发结构。
但对比前面的需求，可以看到，这些方式略显简陋。最后能再此基础上再做一个层次的封装工作，让这些不同的需求可以分开处理。更方便的解决一些有状态的需求，或是能够对信息处理进行优先级排序。
最近一段时间，我受 zeromq 的设计思想影响较多。对于未来的项目设计方法，我有一些想法需要梳理一下。
玩家 Client 和游戏 Server 方面，我还是倾向于采用单一的 TCP 连接。但是希望再其上加一个层次。可以在单一 TCP 连接上模拟多个通讯信道。实现 zeromq 提出的几个模式（的变形）。
在我看来，MMORPG 的服务器端，可以看成是若干服务的集合。那么这些服务无论布置在哪里，我都希望他们是在一个逻辑上的网络中。玩家通过网关也接入这个网络，并可以根据授权来使用网络上的服务。
抛开玩家登陆（注册）流程不谈。典型的场景是玩家在虚拟场景中漫步。这可以看成是 Client 订阅一个指定场景的环境。订阅本身会先鉴权，服务器会查阅玩家是否有权限订阅（玩家是否在这个场景中）。场景会不断的发布场景中每个玩家，NPC 的动态。订阅者将不断的获得这些信息。由于性能问题，我们可以把不同类别的信息放在不同的订阅点上。订阅可以按需进行。
玩家会选择向特定场景 PUSH 自己的状态数据，按 zeromq 的模式，这应该走另一个信道。
每个可对话的 NPC 都可以看成是一个特定服务。玩家向它建立连接，然后以 Request/Reply 模式工作。这样可以方便完成带状态的任务。同样，建立连接的过程可以引入鉴权（比如说检查玩家是否在 NPC 附近等）。当然，NPC 同样需要订阅场景，当场景中和他交流的玩家跑开后，可以自动切断信道。
战斗部分的处理可以独立。以即时战斗为例，战斗计算服务订阅场景中对象的位置和动作。计算他们的动作的后果，得到每次攻击的伤害值。它自己是一个信息订阅点，玩家通过订阅战斗服务，可以了解场景中每个个体受伤害的情况。
同样，某些增值服务，比如自动寻路，都可以独立出来实现。
只是一些想法，希望整理出来后，可以有更多启发。对人也对己。
Comments
服务器端架构采用 agent+若干service的设计思路。
04年在作一个电信增值业务系统时就提出过，可惜到目前为止，我还只是空想家。。。（没法说服别人、也就一直没实现）
Posted by: pig345 | (27) May 29, 2012 09:56 AM
GOOD
Posted by: monclerjackets7.com | (26) October 15, 2011 09:52 PM
没学计算机真是亏了，编程就是复杂
Posted by: drop shipping | (25) July 23, 2011 03:50 PM
我想选择游戏编程，但我不知道当我掌握了足够的基础功力，并用这些基础去学习具体的技术，如：D3D以后，当熟悉了direct 3d提供的技术以后，并用它开发出一个具体好的游戏，
发现技术只不过是无聊的重复，我没有以前的热情了，我的选择是对是错，我应该过普通人的用吃喝玩乐的欲望支撑的生活吗，迷茫。。。。。。
Posted by: 逐 云 | (24) July 6, 2011 10:06 PM
确实想多了，数据都不在手边，处理起来麻烦，不如单服简单，能支持个几千人也就行了
Posted by: 斗破苍穹 | (23) June 24, 2011 12:09 AM
走走想想，发现有复杂度，就更应该好好想想。不能因为现代社会关系很复杂，就觉得停留在农业社会是更好。复杂是相对的，习惯，了解了都简单。所以越是复杂越应该好好想想，棒子做出来了，ea做出来了，wow做出来了。我们为什么做不出来？
----------------------------
Posted by: 孤单 | (21) June 23, 2011 12:45 PM
Posted by: 盖猪猪 | (22) June 23, 2011 10:55 PM
很多好的东西不是构想造成的。
BW里就是很好的构想，实际上虽然设计成这样，实际上很多时候到处都是异步，处理的意外情况很多，远没有单服那么轻松。
2楼的估计深有体会。
就像以前时代做UI推崇DELPHI一样，更多的东西是不是该放在游戏本身的东西，而不是花在天天处理这个那个UI的BUG一样。游戏设计也是一样，一旦复杂起来，各个异步交错，除非框架比较简单或者一次稳定，否则大部分时间在考虑这样那样的怎么获取到“自己”数据的同步和处理之间产生的错误，最后很容易整个项目就挂了。
Posted by: 孤单 | (21) June 23, 2011 12:45 PM
多谢大侠的分享。
这段时间我也在考虑这个问题。同质化确实是一个趋势。变本加厉的是 webgame这一端，从抢车位、朋友买卖这种sns轻游戏类型开始，越来越mmo了，而大量webgame开发者显然不擅长（或者不应该擅长）实时交互通讯框架的实现和维护。
这段时间看了zeromq，smartfoxserver，一些山寨方案，其他mq也顺带搂了一眼。zeromq和sfs有不少地方值得借鉴。
设想有一个独立的mmo服务器端框架，开发者可以在框架上做各种游戏开发。
在我的设想里面，server端的功能以服务和频道（订阅点）两种最基本的形式组织。服务是业务逻辑功能的划分单位；频道用来管理信息传递的粒度和方式。频道带endpoint。以这个为基础应该可以把客户端通讯、server端功能模块间通讯和server之间的通讯编程模式统一起来。
zeromq对socket的抽象和访问模式的抽象非常可取。但有一点，endpoint需要统一组织成uri的方式，这个和你文中说的单一tcp多个信道是一个意思。
另外，频道中的每个peer都需要有自己的id（和类型）。不需要区分受众的广播有时候还是行不通。
最后，业务逻辑以服务的形式组织，以插件的方式注册到框架里面去。服务和用户一样可以订阅频道或者向频道发消息。业务逻辑以事件驱动，事件包括来自频道的信息（特定广播消息的出现、用户加入或离开）和其他系统消息；以request/response调用的服务相当于自带一个req/res的频道。服务可以截获/过滤特定的消息；往频道发送消息；给频道内特定的用户发消息（频道局部广播而非整个频道广播，如地图漫游或者 /say ）；控制频道的生成和销毁（组队聊天或者副本）。
在此基础上，engine层面可以提供broker提供server之间的discovery，降低开发和部署的耦合度。单机测试环境搭起来也容易。
希望以后有机会和大侠交流！
Posted by: immars | (20) June 20, 2011 11:01 PM
我觉得敏捷开发的方法并不合适游戏系统层面的开发，如果应用层和系统层面混杂在一体，那么当发现需要重构的时候，已经臃肿的动弹不得。系统层面在对数据层的处理，网络层的处理，线程空间的处理，这些和冒个特定游戏逻辑本身的关系并不大。系统层面的开发方向就是更稳定，更多链接，更多对象，更多数据，他的开发方向是单调增加的。游戏应用和逻辑层面是随着团队的不同而不同，他的开发方向只是大于零，完全没有目标的，被这个东西牵着鼻子肯定不是死路也是半死不活的路。
--------------------
感觉思考得过深了，也不太符合程序设计的演化过程，容易造成过度设计。只需要在当前需求的情况
Posted by: 盖猪猪 | (19) June 19, 2011 11:10 PM
看了就觉得有点复杂！！
Posted by: nike shox r4 | (18) June 19, 2011 10:47 AM
感觉思考得过深了，也不太符合程序设计的演化过程，容易造成过度设计。只需要在当前需求的情况下，适当提前一点思考下一步可能的需求从而适当提高设计的思考层面并实现就可以了，不需要太超前，这样遇到大的需求需要在不同程度上重构时，也不会因为前期实现太死板造成难以重构的局面。
Posted by: 鏉� 瀹�![[TypeKey Profile Page]](https://blog.codingnow.com/nav-commenters.gif)
| (17)
June 17, 2011 11:53 PM
感觉思考得过深了，也不太符合程序设计的演化过程，容易造成过度设计。只需要在当前需求的情况下，适当提前一点思考下一步可能的需求从而适当提高设计的思考层面并实现就可以了，不需要太超前，这样遇到大的需求需要在不同程度上重构时，也不会因为前期实现太死板造成难以重构的局面。
Posted by: youngs | (16) June 17, 2011 11:42 PM
博文还是一样的好，谢谢你的分享，以后我会常来的。
Posted by: 宁波公墓 | (15) June 16, 2011 03:43 PM
云风可不可以 解决下 win7 64位下梦幻西游的问题啊。 玩了下问题多多啊
Posted by: flexy | (14) June 15, 2011 10:03 PM
可以单一TCP做一下，然后一点点把线程开起来噢~慢慢来哦~云大的团队一定可以哒~
Posted by: icicle198514 | (13) June 15, 2011 05:18 PM
一直有个疑问，还望各位高手解答：程序里面，如果当前的模式符合需求，那么另一种更好的模式出现的理由是什么呢？我们怎么去辨别好与更好？
Posted by: lin_style | (12) June 13, 2011 01:15 PM
还是回到数据流上来吧，看透了无非一坨一坨的数据变化而已。走流程的话会被游戏玩无数法和底层处理间的耦合折磨死。
--------------------------------
在我看来，MMORPG 的服务器端，可以看成是若干服务的集合。那么这些服务无论布置在哪里，我都希望他们是在一个逻辑上的网络中。玩家通过网关也接入这个网络，并可以根据授权来使用网络上的服务
Posted by: 盖猪猪 | (11) June 13, 2011 10:14 AM
在我看来，MMORPG 的服务器端，可以看成是若干服务的集合。那么这些服务无论布置在哪里，我都希望他们是在一个逻辑上的网络中。玩家通过网关也接入这个网络，并可以根据授权来使用网络上的服务
从这里开始走向了苦痛的深渊。
Posted by: Anonymous | (10) June 13, 2011 09:38 AM
博客每次更新必看，但遗憾云风身怀绝技，却一生给了游戏，能不能做点别的事呢？能不能做点让人觉得你做了利国利民的事而不是让青少年沉迷而荒废青春的事？
Posted by: 失望 | (9) June 13, 2011 08:49 AM
个人感觉， mmorpg server能实现到负载平衡的数据流转发就可以了，至于位置同步，战斗等东西，都是上层的东西。不同游戏也不尽相同。
Posted by: Siney | (8) June 12, 2011 04:34 PM
”数据都不在手边，处理起来麻烦，不如单服简单“
这个就是体现服务器设计水平的地方了。
“能支持个几千人也就行了”
这个也确实现在网游的现状，人数太多了，策划们也没有能力去策划和运营。
Posted by: 涛 | (7) June 12, 2011 11:02 AM
楼主很强大啊
Posted by: 土工布 | (6) June 11, 2011 02:52 PM
这个。。。，调试和维护比较困难吧。
zeromq在网游中应用个人觉得还是颗粒度大点的设计比较现实。
Posted by: keror | (5) June 11, 2011 12:47 PM
我觉得太复杂,何不纯粹一点,客户端只是最简单的输入和输出功能,可以封装成通用显示格式和通用命令格式,通过网络输出这些输入和输出命令,计算和存储全部由服务器来处理,这样客户端的移植也非常方便.
Posted by: foenix | (4) June 11, 2011 12:45 PM
看来。。。D-bus数据总线协议找到新应用场景了
Posted by: Anonymous | (3) June 11, 2011 01:16 AM
确实想多了，数据都不在手边，处理起来麻烦，不如单服简单，能支持个几千人也就行了
Posted by: Anonymous | (2) June 10, 2011 09:55 PM
你想多了
Posted by: 盖猪猪 | (1) June 10, 2011 07:02 PM