游戏的核心

模块化（Modular）、可编辑（Editable）、可被测试化（Debuggable）

• 模块化自不用多说，减少耦合性的根本。

• 可编辑则要求，一个项目中的所有开发者，甚至所有成员都应该可以对项目内容进行编辑or更改。

一、模块化

系统之间不要直连在一起

模块化要求我们不能让我们的系统之间直接联系在一起，比如如果你有一个库存管理系统需要和游戏中的其他系统通信，但是我们又不想让他们之间产生一个强连接，因为这会让我们的系统非常不灵活，同时重新集成的时候会非常难受。

干净的游戏场景

游戏场景中也应该尽可能干净，场景直接不会传输任何数据， 这样每次加载或卸载场景的时候开销将非常小，这样就可以使每个场景都只做单一职责，防止你在场景之间打洞传输。

预制体要独立工作

每个预制体的功能要抽象到一定程度，这样可以尽最大化减少冲突

组件化

unity引擎的最大优势，就是可以将每一件事划分到一个具体的组件程度，做且仅作一件事。

二、可编辑化

基于数据的开发

尽可能让我们的项目以数据驱动，这可以让我们的游戏随时进行更改，甚至在运行时。

不要每次都用代码改变程序、高集成度的设计

可以用做很多小组件的模式来制作游戏，这样不但可以快速开发，同时可以大幅度减少测试的成本

运行时更新游戏

更好随时随地的调试你的游戏

三、可调试化

最好又相应的视图来做调试工作。

永远不会修复你没有遇到的错误

对于bug来说：

Scriptable Objects 基础

• 可视化版Unity类

• 类似于Mono behaviour，但是没有transform、GameObject这种原生组件（最终继承自Object）

• 以asset的方式存储

Scriptable Objects用例

• 游戏配置文件（虽然视频里说了很多大型项目都在用这个来配置，但是不知道为什么国内都不用这个，从原生大小看确实比配置文件大）

• 背包系统的数据封装

• 敌人状态？（还没实际用过,倒是做过状态机）

• 音频管理（一个asset中存一堆，然后获取，类似工厂）

架构

别再滥用单例了！！！！

P.S ：终于有看到有人讲单例坏的地方了，下次用这个跟人battle。

从小到指甲边缘起皮，大到核战争，一切都是由于单例引起的！！

单例模式的优点

• 任何地方，拿到任何东西

• 持久化存在

• 很简单的能理解

• 很“简单”来构建项目（前人挖坑，后人遭殃）

缺点

• 刚性连接，每个系统没法独立存在

• 缺少多态性

• 测试起来非常困难

• 依赖噩梦，我们不想要一些东西的时候，它依然会存在

解决方案

• 减少全局的引用

• 控制反转

模块化数据

主要用于减少全局查询数据的操作行为

我们以一个敌人的实体举例

• xxxManager.Instance.MoveSpeed

以这种方式获得变量的话会造成硬连接，同时非常依赖对应的manager被加载进来。

• 使用SO直接进行配置

这样会把一个敌人的所有信息配置到一个文件中，造成一个巨大的冗余，同时扩展性与模块性会变得很差。

解决上述问题的方案，就是：

Scriptable Object 变体

PS：使用 [CreateAssetMenu] 以相同的SO脚本创建出的不同Asset。

这样就可以用这些变体来做对象的数据管理

但是这种每个变量都创建一次的方式非常麻烦，所以我们在上层又进行一次封装

所以我们最终把DumbEnemy类做一些修改

再用一个实例来解释这个，就是上图

一个中间件通知player预制体受伤了，同时，对UI界面通知更新状态，而不用让玩家对象直接引用UI界面做更改。音频界面同理。

这样就可以让这些数据以某种持久化的形式，加载在内存中，使得你在运行时也可以调试！