前言

游戏框架是支撑具体游戏逻辑的底层建筑，需要提供游戏工程大部分的基础需求的支持。 无论框架是小至只有一两个类模块，还是大至十几个模块，只要是为通用功能而起作用的都能成为项目的框架。 框架不是从开始指定了就不变动的，而是随着项目的发展而有所改变。但是并不意味着它是一个可以随便改动的地方。 当框架已经满足了功能，除非是功能有大改，具体的问题，详细的优化等情况，通常就是趋向于稳定。 框架稳定后，更多是基于框架进行上层建筑的开发，和辅助工具的开发。

组成

无论是什么类型的游戏，都有一些功能是共同需要的。这些需求组成了框架的基础模块架构。

一级模块

无论什么项目都必然需要的功能

版本管理 网络通讯 资源加载 输入管理（触摸，键盘，鼠标，手柄等外部设施） UI管理 音效管理 场景管理

二级模块

一级模块中，一些重要的技术核心点

脚本语言（要根据项目的使用而定） 对象池/资源池（面向一切资源） 协程管理（根据项目不同，使用的类型和程度也有所不同） 计时器 事件分发 GM

接触

框架的组成通常是由非常多的脚本组成，那么刚接手一个全新的框架时应该注意什么呢？ 可以先从自己的职位入手，大部分情况下必然会接触的模块包括UI，计时器，事件。这几个模块可以作为第一个入手点。 先了解如何调用相关的API是最重要的。如果能够直接看到源码的话，就能对框架的细节了解地更为深入。 但接触一个陌生的环境，最好先将工作所需的模块相关的公用API大致了解一下。目的是能快速开发。 如其看内部错综复杂的模块代码，还不如在实践中理解模块设计的思路和原理。 在使用中，思考路径可以是：

1. “为了实现XXX，应该调用哪个API”
2. “除了这个API，还有别的api可以实现相同的功能吗”
3. “这几个API有什么区别，各自的侧重点是为了实现什么”

这样一路思考下来，应该能对整个模块的使用和理解有一个比较快的提升。

UI

UI模块提供的API UI对象对应的数据结构

API

打开界面需要传递数值，对应是否能开启指定界面（界面打开需要等级判断，需要指定状态） 需要传递数据给指定UI对象（Tip） 关闭非当前的所有对象 （跳转场景非加载条界面全部关闭）

结构

UI结构是指面对一个Prefab对象是用什么样的数据结构去与之对应的。了解到UI结构后，就能比较清晰地明白要将逻辑和数据分别写在什么地方。 常见的结构：

一个perfab对应一个脚本 一个perfab对应MVC结构

单个脚本是非常简单就能实现的，但若是大型项目，程序员会变动，需要其他人来维护的话，这就不推荐使用了。 因为单个脚本意味着将一切实现都混合在其中，代码必然会变得混乱。即便能梳理结构，一个较为复杂的UI，起码上千的代码交给他人去快速快发也是一件痛苦的事情。 所以使用解耦的接口，将功能定位都显示地清晰明了，对于后期维护有非常大的好处。

工具

为了更有效率的开发，辅助工具必不可少。对应常见的需求，有些工具几乎是所有项目都会存在的。

而开发工具和日常游戏开发有所区别。工具需要开发者思考，使用者的目的和想要解决的问题。工具也是随着项目的发展而一路需要维护和更新的。 在工作上重点是放在功能的实现。例如大量操作IO的功能，要是不考虑性能就很容易卡，但只是实现功能也是可以的。因为编辑器并不需要像给玩家使用那么严谨。 但是，这也考验这一个程序员的责任心和水平。在他人要求不高的情况下，自身的要求将到达何处。在已实现功能的情况下，能将细节做到什么程度。