传统网络游戏（偏重MMORPG）的模块划分

  之所以用“模块划分”而没有用架构等词汇，因为本篇文章并没有细化到架构的程度。我希望先从最宏观的角度说一下游戏有哪些部分构成，让初入行业的游戏从业者，或者不是技术人员的游戏玩家都有所收获。接着，以后的博客会由宏观逐渐过渡到微观，让读者们在脑子中有个更清晰和容易的理解过程。

  客户端是玩家直接接触的，所以先来看下客户端有哪些模块，流程从左往右。

  当我们玩游戏的时候，最先接触到的必然是游戏画面。游戏画面是游戏引擎将美术制作的资源数据绘制到屏幕上产生的。游戏画面主要由场景内元素和UI元素构成。场景元素类似于现实世界中的肉眼可见的各种物质，包括光线、地面、水、杂草树木、高楼大厦等等，主要为了展示给玩家一个游戏环境。UI元素主要作用是将一些意识层面的东西抽象成图案展现给玩家。UI提供的功能分类大致为提示信息、场景交互、广义物品控制操作、角色控制操作等。

  玩家看到游戏画面后总是要做点什么，无论是与场景交互还是UI交互都可能产生玩家的输入事件。一般情况下UI处理的优先级高于场景。确定了事件的内容后，就会交给客户端的业务逻辑系统处理，处理完后通常会给场景或者UI反馈，此时玩家才能看到自己的操作有了实际的表现，比如角色动起来了或者UI内容发生变化。同时客户端的业务逻辑系统通过网络层将处理结果发送给服务器。至此，本地客户端的流程基本完成了。（PS：这篇文章重点介绍模块划分，不对细节问题做更详细的说明，所以这里不必纠结是客户端的业务直接给了场景或者UI反馈，还是等服务器回复才有反馈。）

  接下来看下服务器有哪些模块，流程也是从左往右。

  当服务器收到客户端的请求后会首先进行常规的校验。如果不合格，就丢失该数据包或者对该客户端进行惩罚；如果合格，则进行业务逻辑运算，并将结果返回给该客户端或者广播给所有相关的客户端，同时如果有关键的数据更新则还需要同步到角色DB保存。至此，服务器的流程也就结束了。

  到目前为止，读者应该对一个游戏的模块和大致流程有个简单的认识。此时读者脑子里可能会有很多问题：比如，客户端的业务逻辑都有什么？服务器的节点都是干什么的？服务器的业务逻辑又有哪些？没关系，我会在后续的博客中慢慢展开解释！