今天说了很多，结论就是，需求分析是最重要的一环，分析清楚了，更容易评估出工作量，更容易掌握对项目的走向，从而设计出面向未来的项目结构，总之，不要天天呆在电脑前写代码，多花点时间去思考产品可以事半功倍。
从 EmptyGO 到 Manager Of Managers以下为 刘钢老师的《Unity 项目架构设计与开发管理》部分文字稿。
我们今天探讨一个话题。Unity 的架构有很多方法，所谓的流派，如下所示:
EmptyGO:
Simple GameManager
Manager Of Managers
4. MVCS/MVVM
ECS (Entity Component Based System)
Empty GO
那我们一起来沿着一个思路走下去，看看怎么样的找到一个架构设计的最优方法。当我们谈到 Unity 的项目设计，可能一开始的时候，我们会写一堆 GameObject，比方说场景里有一些主角、怪物或者一些静态物体等等，我们习惯会去写一些脚本来控制这些 GameObject。而剩下的就是和这些 GameObject 没有明显关系的，一些 UI、Manager、内存池这些东西。我们习惯上，会创建一个 Empty 的 GameObject，然后把控制 UI、Manager、内存池这些东西的脚本往这个 GameObject 上一挂，那么我们的项目就算是有架构的东西了，非常值得鼓励，这就算是一个架构的雏形了。那么在接下来我们访问数据的时候，通常需要 GameObject.Find 或 Object.FindObjectOfType 这样的 API，那么这个东西呢，速度慢慢不慢我们先不说。一旦说，他们之间的一些引用关系有一些变化的时候，我们就要一个个 Search Find 地查找代码。那么做着做着很快就会发现，这不是一个很好的方法。一旦你的项目 规模，慢慢地膨胀的时候，你就会发现，我单单的用一个 Empty 的 GameOject 来涵盖所有无关的控制逻辑的时候，它不能满足你的需求，尤其是一些 UI 搅在一起的时候，就会造成更大的混乱。
而假如，我们使用 MonoBehaviourSimplify 就不会产生这个问题了。
不过我们接着文字稿继续。
Simple GameManager
由以上这个问题，我们想到，是不是可以对这个架构进行改变？那么很多人都知道，我们是不是可以把这个 Empty GO 直接改成一个 Singleton，那么恭喜大家，大家已经开始上路了。那么这是一个最简单的架构方法，事实上也是最常用最有意义的一种。思想非常非常地简单，但是，他的确可以起到一个很重要的作用。那么，我们把刚才提到的这个 Empty GO 变成一个 Singleton，这个时候我们说它有一个明显的好处，当你所有其他的 GameObject 想要访问这样一些公共逻辑的时候，我只要拿到 Instance 去调用他的方法，从你的游戏的任何一个位置，都可以访问到这样的一些逻辑，包括一些 UI 的设计，包括一些模块的访问，我们都变得容易了起来。
到这里呢，与笔者当初接触 Unity 时所使用的设计工具模式是一致的，都是先使用单例。
我们在接着往下。
Manager Of Managers
事实上一款游戏里面，和 GameObject 没有直接关系的逻辑控制是非常非常复杂的，尤其有好多好多的内容，如果说我们把所有这些内容全部塞到这样一个 Singleton GameObject 上去，你很快就会发现，好像是说我们有这样一个集中的地方控制很多东西，但是马上也会发生混乱，也就是说自己也搞不清楚这样一个庞大的文件里面到底有什么东西，那我们说，有着这样一个思想的话，接下去我们是不是可以写多个 Managers，那么这些 Managers 就会有明显的分工。
在上图中，上边可以有一个所谓的 MainManager，那么它下面会有所谓的 EventManager、AudioManager、GUIManager、PoolManager、LevelManager、GameManager、SaveManager、MenuManager。所有的这些东西大家都可以将它做成是一个 Singleton，那么在它们之间互相联系的时候，我们主要拿到每一个 Singleton 的 Instance，那么接下来就能方便地在模块与模块之间进行相互的访问。那么这个基本上成为了我们以后可以做游戏的时候一个最主流最基本的方法。那么对于一些所谓的中型以上的项目的游戏架构设计，这就是一个非常实用的方法。我不敢说它是最好的，但是它应该是一个非常非常实用的方法。