《Unity 3D游戏客户端基础框架》系统设计

引言

最近到看一个《贪吃蛇大战开发实例》，其中贪吃蛇大作战游戏开发实战（3）：系统构架设计提供的系统架构的设计思路我觉得还是值得学习一下的，接下来的内容是我看完视频后的一点笔记。

架构设计原则：

1.系统分层：

根据功能特性，可以大致将整个系统分为：

视图层（游戏输入、战斗 View、业务 UI）：视图层也可以遵循 Mvc 的思路来做进一步分层；
业务层（核心玩法、业务模块）；
服务层（模块管理、UI 管理、用户管理、资源管理、配置管理、网络管理、支付管理、分享管理）；
UI 控件；
基础类库（储存管理、调试器、数学库、网络库、单例、Monobehaviour能力）。

上面的分层是根据游戏具体逻辑来划分的，这些层级之间也并非完全独立，存在依赖关系，为了服务于视图层，通常会把一些常用的 UI 试图进行控件化，也就是会多出一 UI控件层，而且整个系统也需要使用到很多基础类库，所以也就有了基础类库层。

2.单向依赖：

只要有两点要求：

不同层级之间的模块是单向依赖的；
仅允许上层模块依赖下层模块。

也就是说，上层模块可以之间访问下层模块的属性，而下层模块不能直接访问上层模块，下层模块的变化通过消息/事件通知上层模块，上层模块通过监听这些消息/事件来及时获取下层的属性变化。

3.模块解耦：

各个业务层模块之间，不直接访问彼此的代码，这样可以达到编译不依赖，实现静态解耦，那么他们要通过什么方式进行通信呢？

最常用的做法：业务层模块之间通过【事件】与【消息】的方式通讯。

具体实现方式：模块 A 需要调用模块 B 的逻辑时，会广播一条特殊的消息/事件，而模块 B 的监听此消息/事件，当收到消息/事件时执行指定的逻辑。

这里的 消息 或 事件 都是不依赖于发起者的抽象类型，通常使用一个抽象消息管理类来管理，经常使用字符串常量来表示不同的消息类型。

4.全局事件：

这种方式适用的情景：

有些事件并非从固定模块发出（可能会有多个模块都会发出此类事件）；
有些事件模块影响全局逻辑。

可以在多个模块中监听同一个事件，当事件在某个模块发生，则广播一个全局的事件，此时所有监听了此事件的模块都会触发相应的操作。

缺点：使用全局事件会使得代码的阅读性下降，因为当一个事件有多个触发源时，当事件触发时我们无法准确地定位事件是从何处触发的。（也可以通过日志记录来索引事件源头）

5.模块独立：

主要适用于服务层模块的设计，核心思想就是将两个服务模块必须有的公共逻辑抽象出来，放在基础类库中。

6.代码重用：

将可以重复使用的代码，在系统层级上做一些小整合，例如：

业务层公共逻辑 –> 服务层
服务层公共逻辑 –> 基础类库
视图层公共逻辑 –> UI 控件

6.设计模式：

善用一些设计模式，可以让代码更加高效，这里列举一些游戏开发中常用的设计模式及其适用的场合：

设计模式	应用场合
观察者模式	业务层之间通讯、上层与下层通讯、客户端与服务器通讯
命令模式	业务层之间通讯
单例模式	服务层为上层提供功能
MVC 模式	视图层与业务层通讯
工厂模式	视图层实例的创建、核心玩法中角色的创建、特效的创建管理