各大模块的基本功能如下

· 服务器端

登陆服：处理新建玩家、登陆逻辑。

场景服：处理场景服中的逻辑。

中心服：处理跨服的逻辑，实现不同场景服进程的数据调度，以及向数据库查询数据。

数据库前端：定时将这里缓存的数据存入数据库。

 

服务器管理服：通过配置xml管理多个服务器的启动关闭，作为守护程序定期与所有服务器相连，当不能接受到某个服务器的定期连接时认为该服务器宕机，做相应处理并重启服务器。

运营对接服务器：连接多个服务器，做GM管理，处理来自运营平台的登陆、充值、身份验证。

日志服务器：记录玩家的数据（包括玩家登入登出记录；升级、经验、道具的获得途径、游戏时间；玩家消费的倾向等）供运营做数据挖掘及服务器意外宕机后的赔付依据。

 

 

· 客户端

接收玩家输入，处理游戏逻辑，显示游戏。

 

接着讨论一下上述五个大模块具体该实现那些功能，能够拆分成那些小的模块，分为那些层次。这里只讨论大模块所能拆分出那些小模块，以及这些模块要负责的功能，至于这些模块如何设计，将在后续讨论。

 

首先就场景服进行讨论

 

· 可公共的网络与数据库底层

场景服最底层的是“数据库存储过程调用”、“网络消息接收”和“网络消息发送”，这些功能经过抽象可以供其他服务器模块（中心服、登陆服）共用。

 

数据库存储过程调用用于与数据库前端进行交换。其中一种做法是通过存储过程id区分存储过程，以数据流的方式填充存储过程的输入参数，以数据流的方式返回存储过程输出结果。

 

网络消息接收和网络消息发送通过对socket的进一步封装，使得消息能够很方便的被解析和发送，它们通常要实现的功能包括网络连接建立、套接字的解析、数据加密与解密、数据包的组包与拆包、数据流的写入与读取。

游戏业务逻辑执行完毕后再调用底层的网络消息发送，向中心服、或客户端发送消息。消息发送既可以直接对流进行写入，可以填充一个结构体，在将结构体写入流。后一种方法的好处在于能够确保进入流之中的消息的格式，不会出现直接进行流写入时会出现漏掉消息的某个数据导致消息格式出错的问题。

还有就是网络通信消息的大小对于受流量限制的手机游戏至关重要，老邱提出可以使用Google开源项目的Protocol buffers，对消息进行压缩。（相关介绍）

 

· 可公共的事件触发层

往上一层是“事件监听”、“日志管理”以及“消息派发”。这些功能中，事件监听是可以供其他服务器模块共用。

事件监听包括数据库回调得到监听、客户端网络消息监听、场景服不同模块的消息监听、中心服数据返回的监听。通过监听事件的消息码，消息会触发相应事件监听的消息回调。

 

消息派发与事件监听相类似，主要可以分为网络消息派发、响应消息派发、否决消息派发。网络消息派发是接收到客户端或中心服消息后进行派发。响应消息派发是场景服中某个业务逻辑模块在处理自己的逻辑业务时需要通知其他逻辑业务模块进行相应更新。否决消息派发是场景服中某个业务逻辑模块在处理自己的逻辑业务时需要得到其他模块的验证。

消息的派发还要做一个一定时间内接收同一客户端消息的限制，当消息接收频率超过一定数值，可以判断客户端至少使用了按键精灵或者加速器，甚至客户端已经被破解了，这样的话可以考虑将该客户端踢下线。

 

日志可以分为错误/警告日志和玩家记录日志。错误/警告日志用于记录游戏执行中发生的异常，编写业务逻辑模块的程序员应该考虑一些异常情况，在发现这种异常情况时调用错误/警告日志进行记录，这样能为程序的bug调试提供线索；

玩家记录日志用于记录玩家的重要数据，如玩家等级、经验、物品等，以防游戏发送崩溃、回档等情况时检查错误，并作为营运期发生意外异常时赔偿给玩家的根据。这种日志将发送到日志服务器存储到数据空中。关于玩家记录的日志，由于数据量会十分庞大，具体工作应该独立出来成为另一个服务器，即日志服务器。这层仅用于向日志服务器发送数据。

 

· 数据层

往上一层是数据层，这里包括玩家、宠物、坐骑、物品、容器的数据。这些数据类的接口需要定义好，方便扩展，例如可以将所有数据获取都集中定义到一个函数，通过传入的枚举区分所要获取的数据，设置数据也是使用同样的方法。通过这样的接口定义，有助于扩展，更有助于逻辑脚本的调用，是的上面一层的游戏业务逻辑层更为灵活。

数据层还要考虑两种情况，在线玩家的完整在线数据，和因跨服业务逻辑导致的离线玩家部分数据请求。这些请求由跨服业务逻辑发出，程序查询数据库或获得。获得得结果可以缓存在中心服中，并同步到发起查询的场景服中，供下一次请求使用。离线玩家再次上线时，与之相关的离线部分数据应从缓存中清理掉。

 

· 逻辑层

最上层的是游戏业务逻辑层，这里主要可以分为场景服业务逻辑，和跨服业务逻辑。场景服业务逻辑是指该业务逻辑需要的数据都在同一个场景服进程中；而跨服业务逻辑是指该业务逻辑需要的数据不一定在同一个场景服进程中，有可能需要中心服进行跨服的数据查找。这里可以产生不同的设计，例如数据只存在场景服进程中，中心服只是做一个调度数据的功能；或者数据即存在场景服，中心服有所有的数据。我并没有实现过跨服业务逻辑的功能，所以暂时并不知道那种设计更好，以及应该考虑的因素。

不同的设计按照策划的需求，场景服业务逻辑派生出养成模块、战斗模块、玩家活动响应、玩家数据管理模块、小游戏模块；跨服业务逻辑派生出副本模块、跨服PVP模块、好友模块、聊天模块、帮派模块、交易模块。

养成模块包括玩家属性提升（科技）、技能升级、坐骑的升级、宠物的升级

战斗模块

玩家活动响应，包括玩家行为的广播、任务模块

玩家数据管理模块

小游戏模块

 

配置数据和脚本逻辑都是对游戏业务逻辑层的支援。配置数据是提供给策划填写游戏内容。而逻辑脚本是用于描述游戏业务逻辑的。脚本可以使用Lua、Python等。为何要使用脚本？使用脚本的好处是灵活，针对多变的策划需求，脚本编写的业务逻辑可以不经重新编译就能应对小规模的修改。如何提高脚本代码的执行效率？脚本应只调用封装好的C++函数组织成业务逻辑，而不进行数据运算。这样效率接近C++编译的原生代码。

 

中心服的结构与场景服的结构基本相同，不同之处在于其主要处理的是跨场景服的游戏业务逻辑。而逻辑层的具体设计可以采取dll插件式的设计，主要是因应跨服逻辑可能出现的增减，同时也是的插件专门针对一个模块能比较独立。

1. 创建新玩家

2. （ 登陆服、中心服、场景服之间的关系是怎样的？用户登陆的流程应该是先到哪个服，怎样走？）

 

数据库前端主要起一个缓存数据提供效率，统一管理数据库操作的作用，结构如下：

（数据库前端担负一些什么功能？）

 

（所担负的功能；多线程结构）

 

（所担负的功能——用例图；能够选用的技术；对接的模式）

 

（所担负功能；大量数据应如何处理，内存不足，占用过高，缓存的使用）

 

客户端的功能包括游戏资源的版本验证与下载、与服务器网络通信、游戏场景构建、模型绘制、动画和特效的播放、UI界面和玩家输入的响应。

具体结构大致如下

总体来说可以划分为三条主线：UI、网络、以及资源与数据。按照MVC的分层模式，可以分为：

表现层，主要包括UI事件响应的表现，当前摄像机的设置，以及动态/静态（场景）物体的表现，这一层与客户端的图形引擎显示相关的接口紧密结合；

业务逻辑层，主要包括UI界面上的游戏逻辑，不同摄像机根据需求的切换，以及动态/静态（场景）物体管理、动态物体的业务逻辑还有动态物体的生成、变化与销毁。这一层是游戏主要玩法的所在，大量投入逻辑程序员开发的地方；同时也是会因应策划需求，容易发生变化的地方。这一层会与客户端的UI接口，物理引擎，AI引擎紧密相连；

数据层，可分为元数据层、数据加载层、数据管理层，主要负责数据的读取、解析和管理。这些数据可以分为来自网络的网络通信消息、UI资源、配置和本地记录数据、由模型特性声效组成的美术资源。所以这一层会跟客户端图形引擎的资源解析，客户端目标系统的文件系统、网络系统紧密相关。这一层要考虑到数据加载的不同步问题，具体而言就是微端要求玩家能够下载尽可能小的客户端快速进入并开始游戏，导致这些资源，特别是美术资源，在游戏运行时可能正在下载。要保证在没有资源的情况下游戏能够运行，同时当资源下载好后立刻显示出来。

 

网络游戏的开发除了以上的最终发布的制成品外，还需要很多的辅助工具。以下仅作列举和简单说明，具体讨论留在后面。

这些工具或是与客户端引擎紧密相连，或是与通信消息相关，或是利用到一些工具，可以制作为独立的小程序，或者游戏引擎、美术工具的插件。

 

 

后续内容：

已完成：

进行中：客户端的主体设计

 

计划中：

服务器相关：服务器的主体设计（场景服与中心服）、网络通信设计、数据缓存与数据库通信设计、数据层设计、逻辑层设计与dll划分、战斗模块设计、机器人压力测试工具设计、服务器管理工具设计、运营对接服务器设计、攻击服务器方式及对策。

客户端相关：资源动态加载与管理、场景管理、战斗模块设计、特效实现方式、UI相关（原理与美术制作规范）、动画相关（原理与美术制作规范）、美术工具设计、破解客户端方法与对策。

公共部分：性能优化与代码检测、测试游戏的方法、游戏开发团队的组建、改善游戏体验的要素。