游戏服务器设计的相关内容(2)

时间:2009-11-20   来源:haooooooo博客   网友评论:0   人气: 656 作者:

 

这个方案听起来似乎不错,只是,如果宕掉的是场景管理器进程,那该怎么办呢?

按照前面的描述,场景管理器可以看作是整个游戏世界的中心,它以一个指挥者的身份维护着游戏世界的有序运行,所以它的宕机对整个游戏世界的影响也将会是巨大的。

有没有什么办法能够使得场景管理器进程再次启动后能够恢复先前的状态呢?

我们可以为管理器和场景进程定义一套协议,使得管理器不仅能够创建并恢复一个已有场景,而且场景管理器还能通过现有的场景进程数据恢复出自己。

一个理论上可行的方案是,场景管理器与场景进程间保持TCP长连接,并以一定频率进行心跳联系,任意一方发现联系中断或长时间未收到心跳包后都会立即做出处理。

如果是管理器发现场景进程失去联系,那就启动新的场景,如前面所描述的那样。如果是场景进程发现管理器失去联系,那就立即启动重连过程,直接再次连接上管理器,然后立即将自己当前的状态和负责的场景ID报告给管理器。管理器通过这些上报的数据就能恢复出游戏世界内的场景对应关系表,也就是恢复出了自己原来的状态。

 

进程是恢复出来了,可我们忘了最重要的内容:数据。当场景进程宕机后,上面保存的玩家属性数据也随之丢失了,虽然我们能够再次将这个场景创建出来,并把原来在这个场景内的客户端数据重新定向过来,但这些客户端对应的玩家对象的数据却没有了,游戏仍然无法继续。

 

也许我们可以再做一点修改,把场景内的玩家数据分离出来,保存到一个独立的进程上,比如,我们可以把这个进程叫做数据服务器,或者数据中心之类的。一个隐含的要求是,数据服务器的逻辑实现非常简单,简单到你可以认为它是绝对安全的,不会宕机。所以,保存在这里的玩家数据也就是绝对安全的。

 

让我们在这个问题上稍微再深入一点。

场景进程上每次执行玩家的游戏逻辑时都要异步地到数据服务器上来存取数据,这个开销可能太大,而且会使得一些游戏逻辑的实现变的很复杂,那么,把一些会频繁使用到的数据直接保存在场景进程中,当数据发生改变时同步更新到数据服务器上,这样可能会比较容易接受。

 

 

老板全都满意了吗?

 

从理论上来说,我们已经解决了场景进程宕机和管理器宕机后的状态恢复问题,并且在场景恢复后也不会因为丢失了玩家数据而无法继续进行游戏,而且,只要处理得当,这个过程对客户端来说可以是完全透明的,也就是玩家根本不知道服务器上有个进程意外结束,我们做了这么多的工作来将它恢复了。

 

事实上,这个过程的透明也是必须的,我们并不需要嚷嚷着告诉我们的用户,也就是玩家,我们做了多少多少事情来让你玩的更顺畅,又花了多少多少精力来解决因为服务器宕机而引起的麻烦,对于最终的用户来说,他只需要享受最好的服务。闲话少说,让我们继续。

 

真的已经完全解决了所有问题吗?

想象这样一个场景:我带着几个刚刚降临到艾泽拉斯大陆的伙伴冲向了艾尔文森林,去开荒霍格!正在霍格只剩下一丝血的时候,服务器稍稍卡了一下,等我缓过神来,面前的霍格骤然消失,地上也不见尸体。找了一圈,它正在出生点摇头晃脑,也在四处张望,但头顶上的血条分明是,满血!

怎么回事?

处理这张地图的场景进程意外结束了,服务器的宕机处理机制很快地恢复了这个场景进程,并且把我的客户端数据重新定向到了新场景。只是,事情并不是一切都完美。因为这个场景是完全重新创建的,这意味着所有的怪物也是重新创建并被摆放到了初始位置,所以,只剩下一丝血的霍格碰上了好运气……

 

类似的还有,正在护送NPC返回营地,在稍微停顿了一会儿之后,NPC又重新回到了原来的地方,等等。

 

虽然这比起最初的“客户端被迫断开连接,服务器端数据丢失”要进步了许多,但会给我工资的老板仍然可能不太满意,他希望,霍格应该还在我的面前,而且只有一丝血,那个跟着我的NPC也应该还在我旁边……


 

文章评论