【总结】游戏框架与架构设计

使用框架开发游戏

 

优点：耦合性低，重用性高，部署快，可维护性高，方便管理。提高开发效率，降低开发难度

缺点：增加了系统结构和实现的复杂性，需要额外花费精力维护，不适合小型程序，易影响运行效率

 

常见框架

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中找到~