积累了半年的Unity开发经验，写下自己对游戏程序"快速"开发的见解，主要是面向2D游戏、UI制作、游戏后端数据处理的一些思考。
游戏开发和传统的Web前后端有些不同，但是又大同小异的，做好UI、传递数据、中间层处理信息、后端接受存储、再返回前端，大概都是这个流程。
所以写UI啊、角色信息、接口设计啥的，大体就有了一些经验，因为是个人的思考总结、也并非什么教程理论，就随便写得通俗一点。
本篇文章的大纲如下：
- 游戏项目管理、维护、推进、合作开发
- 游戏UI制作、代码管理、UI数据处理
- 后端数据保存读取等(美术资源、数据库等)
游戏项目管理：
一个简单的例子：Unity里当然可以在场景里搭好Unity、玩法逻辑等组件，再一个一个往上挂脚本，控制器写一套脚本往玩家身上挂，UI控制就单独写一个脚本逐个往上添加组件，还有数据处理啥的挂个empty组件放后台运行…
这么做的结果就是：当游戏的内容丰富到一定程度的时候，Scripts文件夹下有几十个脚本，当场景运行的时候、里面挂着一大堆的组件，当想要再继续添加新的想法(例如修改之前的玩法、增加新的功能)，很容易发生混乱的冲突，或者难以进行。
更不用说一打开脚本文件全是各种乱七八糟的函数调用逻辑，还有各种不规范的写法。
所以正经商业游戏的处理做法好像应该是这样才对：再怎么多此一举，也要单独为各部分写个管理器：UI管理器、资源管理器、运行玩法的管理器，就像数据结构里的树状结构一样：一个场景里只需要挂载那么几个管理器，当打开的时候告诉管理器：我们该运行哪些资源，再加载进游戏中，性能、管理、开发复杂度都大大降低了。
而且要善用C#的语言特性：
- 先在稿子上写好大致的框架逻辑，
- 搬进C#的接口(Interface)里，
- 通过抽象类(Abstract)实现基本逻辑，
- 然后再通过重载(Override)，实现逻辑功能，
- 测试、排查、管理。
当然这些都不是必须的，只是说要做的体量越大、个人脑力越有限、越应该分配一部分精力在这些管理的实现上（基本网上都有现成的实现框架、学会用着也非常不错）。
合作开发的话就推荐用git仓库、gitee啥的，
在游戏项目的根目录加入 .gitignore 文件：
1 | /Library/ |
push到代码仓库里，邀请别人加入仓库，十分正常的程序合作开发做法。还有就是盯着Deadline安排开发的时间吧，其实一个程序员真正写代码的时间还挺少的，一半时间构思要写什么东西满足什么需求，部分时间debug，剩下就是照着框架去写逻辑了。
游戏UI方面：
前端有个CSS、html、js三件套，负责了 渲染、布件、逻辑控制，三大功能，在游戏开发里一样，先在场景里搭好基本的显示UI（写html），参照树状数据结构做好分级，用管理器控制每一面板的UI预制件，再写好数据处理、显示就行。
实际开发过程中，遇到过一些比较棘手的问题就是：
前端组件是应该带有属性数据的
我该怎么样用对象的思想去写好UI组件？因为很多数据需要显示，但是我又不可能把显示接受数据的部分拆分到子组件去（这样会非常混乱，甚至耗费时间），我希望的是让这个前端UI界面就像一个简单的class，里面有各种属性值，只要我在外部更改了这个属性，UI就会随之更改。
答案就是事件监听：通过UI面板内部的事件管理器，监听属性的变化并实时传到每一个bind在UI面板预制体上的组件（TMP、Sprite、Prefab数量）等，这样写就感觉非常简单了。
前端代码管理器
无可避免地问题就是每一个UI都得专门写一套代码去控制上面的组件，并在游戏场景内可以随时实例化资源，不然编辑器内场景上面的信息量就要爆了，看不过来，我用的做法就是别人写好的框架(互联网上真的有好多这种好用的框架)