面向Web服务的游戏设计2：分布式游戏处理

上一节比较了Silverlight支持的几种通信方式，结论是：基于纯Web服务器环境，WCF Binary Encoding为首选的通信技术。接下来我们可能会问自己，Web服务器环境是否适合作为承载MMORPG游戏的服务器，能否承载大量的游戏逻辑运算，能否支持几千甚至上万的游戏者的连接以及逻辑处理？架设过私服的朋友可能有体会，在P4上运行传奇的服务器程序，cpu几乎全部被占用，程序切换明显延迟。而对于租用的web空间，尽管服务器硬件本身可能配置很高，但是服务器上可能安装了多个虚拟web服务器，而每个web服务器可能被很多的web空间租用者所共享，平均下来的系统资源就很可怜了。在这样的环境下支持MMORPG游戏，性能能够得到保障吗？上一篇文章发布之后，已经有朋友提出了类似的质疑。

 

记得在解密方法上有一个有趣的提议，称为China Box（中国盒子）。加密算法一般是正向加密计算很容易，反向解密计算极其困难。并不是说解密计算完全不可能，只是因为计算量太大，在常规计算能力下（例如普通PC），可能耗费几年甚至更长时间，而那时解密的结果已经失去意义了。中国盒子的原理基于中国庞大的人口：15亿。假设中国拥有1亿台电视机，每台电视机上都安装了专门的解密程序（后台运行，不影响收看电视）。当需要某个解密时，中央电视台在播放节目的同时，把该解密请求广播出来，由1亿台电视机上的解密程序分布式计算。可想而知，1亿个程序同时计算不同部分，计算速度大大加快，可以把三年的计算缩短到一秒。如果某台电视机成功解密了，则在电视上显示：恭喜你中了大奖！请马上与中央电视台联系领奖。

 

上面的例子说明了分布式计算的优越性：服务器上无法承受的计算负载，如果分摊到客户机上来执行，对于每个客户端来说可能微不足道。回到我们的MMORPG游戏设计，如果能够把复杂的游戏逻辑运算分布到每个游戏者的机器上运行，然后把结果更新到服务器上，是否可以大大降低服务器的负担呢？理论上似乎说的过去，关键是如何去实现。分布式算法的实现相对于集中式来说复杂很多，笔者并非专家，很难给出完美的方案。只能就事论事，讨论一下我们的MMORPG游戏在Web服务器环境下的解决办法。

 

 

上面是该方案的模块图，图中的箭头标明了数据流动的顺序。由于Web服务器是被动方式的，需要由客户端来发起整个流程。为了方便讨论，假设客户端的任务轮询定时器间隔为1秒。

1 客户端主控模块发出任务请求。

2 客户端通过wcf service把任务请求发送给服务器。

3 服务器收到任务请求，然后把任务请求传递给任务调度模块。

4，5 任务调度模块根据发送请求的客户端的当前状态（每个客户端的当前状态在服务器端都有一个实时镜像），从任务队列中取出一个最合适该客户端的任务。

6，7，8 任务调度模块把任务通过wcf传递给客户端，该客户端在后台处理该任务。

9，10，11 在下一次任务请求，客户端把本次任务处理的结果发送回服务器，服务器把该结果更新到当前全局状态供所有客户端使用。

 

从上面的模型可以看到，服务器端把繁重的任务处理计算分散到众多的客户端上进行处理，在服务器端只保留任务调度和数据传输，计算量大大降低。当然该模型只是在理论上讨论了分布式处理计算的可行性，实际实现起来还会遇到很多问题。例如：哪些任务适合放到客户端进行处理？如果任务的计算量很小，用于调度和传输的开销可能相对更大，分布式处理就失去意义了。

 

一个比较合适的例子是Sprite的寻径算法。假设3个玩家在某个地图打怪，该地图当前有9个怪物。在服务器的任务调度上，可以让每个玩家的客户端托管3个怪物的处理。由于怪物与玩家处于相同地图环境，客户端可以不必下载大量的处理怪物的环境信息，从而节省传输数据量和时间。

该方案的一个问题是时间延迟，由其他玩家托管的怪物信息最大需要2倍的任务轮询时间才能更新到本机。一个解决办法是从怪物的当前状态智能预测下面可能的状态，每次用实际状态更新前面的预测状态。智能预测算法需要很强的数学能力，超出笔者的能力范围了。

 

本文从理论上探讨了网络游戏的分布式处理，以及Web服务器环境承载网络游戏的可能性。从性能上来讲，笔者并不认为WCF+分布式处理可以超过或达到Socket，事实上Socket仍然是专业游戏的首选。然而昂贵的独立主机的价格使广大业余游戏爱好者望而却步，用Socket开发的Web游戏只能在家独享。Web共享空间的价格一般是每年几百元人民币，个人用户完全可以承受，大大降低了发布游戏的成本门槛。

 

本文只是理论上初探，没有严密论证，也没有实践支持，不到之处请大家多多批评指正。谢谢！