使用框架开发游戏
优点：耦合性低，重用性高，部署快，可维护性高，方便管理。提高开发效率，降低开发难度
缺点：增加了系统结构和实现的复杂性，需要额外花费精力维护，不适合小型程序，易影响运行效率
常见框架
MVC
- 表现层（View）：游戏画面。UI
- 逻辑层（Controller）：数据接口，操作控制，AI
- 数据层（Model）：数据保存，图片、声音等资源
我的SFramework中，View层是单独的，Model我放在基类中，Controller则在派生类，实现了MVC的分离（如果要重构的话我可能会用组合代替继承）
举例： PlayerHUD+PlayerCtrl（PlayerYuka）+IPlayer
注意图中的调用关系
MVC
优点：实现了层次化设计，是一个基础常用的框架
缺点：MVC如果没有用好，容易出现某一层过重的现象（如View）。MVC更适合横向铺量的项目。游戏（非UI部分）则不太合适。
MVVM
MVVM 模式将MVP中的 Presenter 改名为 ViewModel，基本上与 MVP 模式完全一致。
MVP中，View 与 Model 不发生联系，都通过 Presenter 传递。
唯一的区别是，它采用双向绑定（data-binding）：View的变动，自动反映在 ViewModel
SFramework中，View不能直接修改Model，他们之间通过事件通信
uFrame&MVVM
uFrame框架模仿了MVVM这种架构模式（事实上并不包含Model部分，且多出了Controller部分）
在uFrame中，使用Element这个概念将业务分拆成三部分：
- ViewModel：保存游戏中对象的数据结构，例如血量、经验、金钱等等。
- Controller：处理游戏业务逻辑。例如加血、减血之类的。
- View：游戏世界中可以见的对象，和ViewModel绑定，以在游戏中进行展现。
uFrame是可视化的，功能似乎方便实用，但是由于收费，我没有深入过，不便过多评价
PureMVC
pureMVC框架引入了多种设计模式、消息机制（使用观察者模式，发布/订阅模式）来解耦各个模块
我曾使用过PureMVC框架开发过一个demo，它通过ApplicationFacade，Mediator，Proxy，Command架设项目，由SendNotification()进行交互
优点：强解耦，实现了MVC高度分离
缺点：增加代码量，降低执行效率，函数调用层次较深，容易找不到消息发送源。Facade作为单例接口，本应管理MVC，Model、View、Controller却提供了 getInstance()方法，让人奇怪
MVCS
框架与架构
StrangeIOC支持依赖注入（即控制反转（Inversion of Control，缩写为IoC）），可以有效降低耦合度
但是IOC复杂而缓慢，而且是基于Mono的，所以我没有选用
ECS
Entity Component System
Unity本身的组件开发就是ECS框架，ECS很适合游戏开发，在游戏引擎中比较常见，谷歌曾在Github上发布了一个名叫Entitas的ECS框架，下面我们就来介绍
- Entity就是只有数据的GameObject对象，不包括方法
- 每一个Entity拥有Component组件，负责Entity数据处理
- Group是拥有相同Component的Entity集合
- Context就是创建销毁Entity的工厂
- Collector收集器提供了简单的方法来处理Group中Entity变化的反应。
ECS的教程现在还比较少，详细的我也不方便介绍了，感兴趣的可以在这些框架中选一个深入
其他
TRAP框架
TRAP是一个学长制作的单机游戏，他在这个游戏中使用了自己原创的框架，SFramework也从中参考了不少设计思路。TRAP有分UI部分和游戏部分，封装了Unity事件和输入控制，使用单例、Manager和NotificationCenter进行消息传输，不过目前未开源
GameFramework
基于 Unity 5.3+ 引擎的游戏框架，国人原创，开源
详情可以去官网查看
SFramework
Sunset Game 制作组自主设计研发的一款Unity通用游戏框架，设计思想类似MVC+ECS。
还有更多优秀框架可以在GitHub中找到~