引言
最近到看一个 《贪吃蛇大战开发实例》，其中 贪吃蛇大作战游戏开发实战（3）：系统构架设计 提供的系统架构的设计思路我觉得还是值得学习一下的，接下来的内容是我看完视频后的一点笔记。
架构设计原则：
1.系统分层：
根据功能特性，可以大致将整个系统分为：
- 视图层（游戏输入、战斗 View、业务 UI）：视图层也可以遵循
Mvc的思路来做进一步分层； - 业务层（核心玩法、业务模块）；
- 服务层（模块管理、UI 管理、用户管理、资源管理、配置管理、网络管理、支付管理、分享管理）；
- UI 控件；
- 基础类库（储存管理、调试器、数学库、网络库、单例、Monobehaviour能力）。
上面的分层是根据游戏具体逻辑来划分的，这些层级之间也并非完全独立，存在依赖关系，为了服务于视图层，通常会把一些常用的 UI 试图进行控件化，也就是会多出一 UI控件层，而且整个系统也需要使用到很多基础类库，所以也就有了基础类库层。
2.单向依赖：
只要有两点要求：
- 不同层级之间的模块是单向依赖的；
- 仅允许上层模块依赖下层模块。
也就是说，上层模块可以之间访问下层模块的属性，而下层模块不能直接访问上层模块，下层模块的变化通过 消息/事件 通知上层模块，上层模块通过监听这些 消息/事件 来及时获取下层的属性变化。
3.模块解耦：
各个业务层模块之间，不直接访问彼此的代码，这样可以达到编译不依赖，实现静态解耦，那么他们要通过什么方式进行通信呢？
最常用的做法：业务层模块之间通过【事件】与【消息】的方式通讯。
具体实现方式：模块 A 需要调用模块 B 的逻辑时，会广播一条特殊的 消息/事件，而模块 B 的监听此 消息/事件，当收到 消息/事件 时执行指定的逻辑。
这里的
消息或事件都是不依赖于发起者的抽象类型，通常使用一个抽象消息管理类来管理，经常使用字符串常量来表示不同的消息类型。
4.全局事件：
这种方式适用的情景：
- 有些事件并非从固定模块发出（可能会有多个模块都会发出此类事件）；
- 有些事件模块影响全局逻辑。
可以在多个模块中监听同一个事件，当事件在某个模块发生，则广播一个全局的事件，此时所有监听了此事件的模块都会触发相应的操作。
缺点：使用全局事件会使得代码的阅读性下降，因为当一个事件有多个触发源时，当事件触发时我们无法准确地定位事件是从何处触发的。（也可以通过日志记录来索引事件源头）
5.模块独立：
主要适用于服务层模块的设计，核心思想就是将两个服务模块必须有的公共逻辑抽象出来，放在基础类库中。
6.代码重用：
将可以重复使用的代码，在系统层级上做一些小整合，例如：
- 业务层公共逻辑 –> 服务层
- 服务层公共逻辑 –> 基础类库
- 视图层公共逻辑 –> UI 控件
6.设计模式：
善用一些设计模式，可以让代码更加高效，这里列举一些游戏开发中常用的设计模式及其适用的场合：
| 设计模式 | 应用场合 |
|---|---|
| 观察者模式 | 业务层之间通讯、上层与下层通讯、客户端与服务器通讯 |
| 命令模式 | 业务层之间通讯 |
| 单例模式 | 服务层为上层提供功能 |
| MVC 模式 | 视图层与业务层通讯 |
| 工厂模式 | 视图层实例的创建、核心玩法中角色的创建、特效的创建管理 |