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