UI游戏框架（一）

UI游戏框架

简介 MVC 框架（设计模式）

 

 

 

 

 

大型游戏项目中，没有UI框架容易导致与出现的问题：

问题1；

 　　以ARPG为例，多个场景会反复出现相同的“UI窗体”，造成多个场景中反复加载相同的UI窗体。

解决思路：

 　　 “UI框架” 需要缓存项目（例游戏项目）中常用的“UI窗体"。

 

问题2： 

　　开发商业复杂项目时，各个UI(UI脚本)之间传值，容易出现“紧耦合”的情况，容易导致项目的“可复用性”降低。

解决思路：

  　　各个UI的生成、销毁、切换，都是通过框架(Manager)实现，各个UI之间不直接联系（传值），开发类似“消息传递中心”的机制来负责所有“UI窗体”或者UI脚本之间的传值。

 

问题3： 

　　卡牌、RPG等游戏类型项目，很多情况下会出现多个“弹出窗体” 叠加的现象，开发人员需要“手工”维护窗体中间的层级关系。

解决方案：

  　 设计UI框架系统，使用“栈”的数据结构，保存与控制当前所有需要显示的“UI窗体”的层级关系。

 

问题4： 

　　商业项目中多个“UI窗体” 叠加出现时，保持“UI窗体”的“模态显示”非常重要（即： 弹出子窗口时，不允许玩家操作父窗体），否则容易出现各种误操作。

解决方案：

  　设计的框架本身，需要对当前显示的窗体做“遮挡处理”，即：不允许用户绕过当前“UI窗体”直接操作底层窗体，或者误操作点击项目中的3D游戏对象等。

  

　　当然还有很多其他的问题，诸如：语言的国际化、“窗体预设”自动加载的管理等。但是设计UI框架一个总的核心原则是：尽量让框架本身完成与具体业务无关的事务性工作，让开发人员只需要专注游戏业务逻辑的开发本身即可。（这个原则同样适用于其他框架的设计中） 

　　为了解决以上商业开发遇到的各种问题，见UI窗体架构的“功能设计图”

 

  

相应的类图设计如下：

  

 

为了更好的描述整个框架系统，我们整个框架分如下六个部分作详细描述：

1. 最简版本设计

2. 窗体的层级管理

3. 模态窗体管理

4. 配置管理与应用

5. 消息传递中心

6. 资源国际化技术