mmorpg的一些设计随想总结

不知不觉，跟着这个项目开发，已经四年多了。经历了项目的各个阶段,回顾过往,总结下经验.

一.开发的原则中什么最重要

开发原则有很多，比如编码方面尽量少用goto，静态变量,设计时多用组合等.但是现实是复杂的，总会有些情况要突破原则.那么有什么原则，是可以一贯通用的呢？

个人经验,KISS基本能满足大部分情况下的要求.比如写代码时，会尽量精简变量，简化逻辑来实现功能。某个类持续膨胀时,把相同的功能提取成一个函数.

把相对独立的功能另外采用类来实现.

设计独立模块接口时，接口要精简.现阶段用不到的部分即使内部有实现.也尽量别暴露出来.在设计系统时，尽量就已有的功能做分析.不做无谓，大而空的扩展(参考标准是:扩展在系统设计后1年内没人用).准确预测各功能的可能复杂度,把复杂的功能隔离开.

二.怎么设计一个复杂系统

设计复杂系统的过程，基本上就是一个把问题逐步分解成相对简单问题的过程.这里以开发一个类WOW的MMORPG 作为命题,描述下流程.

首先我们把整个游戏分成客户端/服务器.先说服务器.

如果服务器进程只有一个,无论是性能/稳定性都很成问题.我们以功能独立性/性能优化为准则,逐步分解它.

1.首先把登录功能分解到一个进程.

2.根据游戏地图独立的特性,分解成游戏服(管理地图内玩家)和世界服(全局模块聊天组队等以及网关)

3.如果要做跨世界的应用,比如WOW的跨服副本.需在登录服和世界服添加一个中间层,管理世界服之间的交互.甚至也可以把登录服的DB功能也移过去.让登录服功能更专一.

4.作为主要的DB负荷来源游戏服,DB请求分成两类:一个是玩家信息比如血量，物品等定时保存的.二是全局信息,比如副本进度之类的，需要立即保存的.对于定时保存,如果时间过短,DB会不堪重负.时间过长的话,又会造成服务器异常后的长时间回档.那么可以单独设计一个DB服,缓存DB请求.然后就可以把游戏服的定时保存时间尽量缩短而不影响DB负荷.

5.WOW的地图都很大,NPC也比较多.这样对于游戏服来说,AI模块的负荷也会比较重.可以单独剥离出来形成一个AI服,减轻游戏服负荷

6.最后,根据负荷情况,如果世界服广播压力过大,可以在世界服与玩家之间添加网关服.如果游戏服压力过大,也可以类似AI服那样，把相对独立的模块分离出来形成进程.比如玩家位置合法性的效验等.

按照进程对服务器进行分解后,再重点解决最复杂的游戏服的功能分解.

1.游戏服按照模块功能分成两类:全局模块(管理多个玩家的，比如工会/组队等)和实体模块(依附于实体,比如物品/技能等)

2.全局模块加载初始化,采用传统的方式,在配置表配置加载函数以及模块名称,通过返回公共接口,达到统一加载/初始化的目的.

3.实体模块也可以类似全局模块处理.不同之处在于,每类实体(玩家/宠物/NPC)子系统有所不同,在配置表中，可以配置不同的实体所需加载子系统的名称.以组合的形式区别不同实体.

服务器的设计工作基本差不多,再来说下客户端.

1.客户端采用多进程的设计的比较少.首先最重要的还是逻辑与引擎的分离。

2.考虑到客户端大部分逻辑都是跟UI相关的,而UI逻辑一般不会影响性能.可以把这部分统一通过脚本来做.UI在脚本,C++提供功能性的函数.这样可以很大程度上提高客户端的稳定性.

3.客户端的逻辑模块的设计跟游戏服类似.通过配置表驱动所有模块的加载和初始化.

三.其他重要概念

1.模块划分结束后,重点需要解决的模块通信问题.一般采用接口回调和委托(类似于 boost::signal 功能) 

2.仔细考虑服务器的需求，所有逻辑都是收包和定时器来驱动的。所以底层来说，单独用一个线程接受这两个进行处理.这样所有的逻辑都不需要考虑多线程相关的东西,使服务器更稳定.