关于游戏架构的探讨-UI框架

无凿

游戏UI的特点

游戏UI到底适合使用什么框架，很难简洁直观的描述清楚，我觉得我们可以先从问题的本身出发，然后再去探讨解决方案。游戏ui开发从工程的角度看主要面对的这几个问题：

• 复杂的数据对象。界面展示的数据并不像传统app那样结构简单，它的数据可能经过多重逻辑的加工，取自游戏系统的不同部分，数据有的来自网络，有的来自配置表，有的是运行时数据，这几类数据每个都非常庞大，又会进行再组合。
  
• 复杂的交互逻辑。一个界面的功能复杂可以达到几十个功能的叠加，有效的逻辑代码行数几千行。
  
• 界面数量极大。大型游戏的界面轻轻松松达到近百个。
  
• 相似界面多，开发迭代速度快，难以高效的复用，往往是物理复制。
  

一个框架，如果可以解决上面几个问题耦合产生的各种工程问题，那么它就是一个合适的框架。
谈谈MVC框架

谈起ui框架，绕不过去的一个话题就是要不要用mvc架构，相信各位也在工作的项目中看过类似的结构，像，又不完全像，知乎上很多大佬也讨论过类似的问题，褒贬不一。我在这里按照我的思路系统的探讨一下这个问题。
什么是MVC

MVC，全称为 模型/视图/控制器(Model/View/Controller),最初被用来构建用户界面。

MVC包括了三类对象。Model作为数据对象管理数据，View为作为视图界面可视化model中提供的数据，Controller控制器定义用户界面的交互逻辑。MVC的应用，将用户界面分为了数据，界面，逻辑三个部分，提高了代码的灵活性，资源的复用性。

MVC框架中可以抽象出多种设计模式。

• 在Model与View的交互中，Model数据变化时，通知View数据更新，View则访问Model来更新数据，这种将Model与View分离，一对的多的通信方式抽象成更一般的情况，将对象分离，使得一个对象的改变可以影响另一些对象，并且无需知晓它们的变化细节，这就是观察者模式(Observer)的核心思想。
  
• View与View的交互中,将一组原子View对象封装成了一个新的View，这个新的View又被其他更复杂的View调用，比如一组按钮分装成了一个列表，这个列表又被当成一个单独的对象使用，这种将一些对象划分为一组，并将该组对象当做一个对象来使用，这个设计就是组合模式(Composite)。
  
• View与Controller的交互中，将View的交互逻辑封装在Controller中，当我们想要更换View的交互逻辑时，比如一个股票分析界面，vip就是要比普通用户看到的信息更多，但是界面资源是一样的，这个时候就可以更换一个Controller，达到不一样的交互逻辑的效果，而又不用更改资源，或者引入臃肿的判断，这种将一系列算法封装在一个对象中，供另外一个对象灵活使用的方式就是策略模式(Strategy)。
  

从这里我们可以看出，优雅的MVC框架是对现实问题的抽象，然后再组合多种设计模式，从而让问题简单化。
MVC与MVE

知乎一篇高赞文章总结了各种前端框架，最后得出结论，mvc不适合游戏ui，太过臃肿，作者所认为的游戏ui框架是mve，他用桥梁的概念说服自己，在mv的基础上引入了e，即event事件。暂且称之为mve。结构如下图


mve的方式确实很普遍，很多项目都这样做。道理也很简单，游戏界面复杂，逻辑重，二者又常常耦合，因为巨大的开发量分开反而造成效率低下，所以View和Controller合并为新的View，既包含界面，也包含逻辑，而且这种写法在unity的编程模式下无比顺畅。model与view通过事件通信，view可以直接访问m。这种模式因为其简单明了又容易快速开发，确实在游戏中广泛使用，但是我觉得这种方案也仅仅只是可以快速开发，它不满足工程框架的要求，即高效率，可复用，可扩展，可维护。
其实深入分析mve，我们只能称之为mv，因为mvc的框架中，m与v的通信就像一开始分析的，本身就是观察者模式，没有必要再单独拎出来。
所以我们通常所见到的都是mv模式，只是将逻辑和界面分配到了View中，虽然写起来快，但是严重违背了面向对象的设计原则，针对接口编程，而不是针对方法编程。因为合并了controller与view，这样就造成严重的耦合，无法复用，难以维护。比如一个几千行的组队界面，这个界面的逻辑和UI写在一个文件中，这时候你要把这个组队界面从副本复用到大世界中，玩家的数据类型全都变了，怎么在原有的代码上兼容？答案就是无法兼容，复制一份UI，防止二次更改，复制一份代码替换所有会变得逻辑，这就是最终实际中暴力物理分割解法，为难美术，为难程序，后期要维护2份，如果不复制2份，强行放在一起，就是堆山，噩梦。记得我曾经维护过一个几千行代码的ui，经常看过逻辑，过一段时间就忘记了，还得再看，维护浪费时间，如果复用这样的代码，简直天方夜谈。
所以mve这种方式，也就是mv，从工程的角度看本身还是存在很多问题。
MVC是否适合游戏

我个人觉得，mvc的设计理念非常适合游戏ui的开发。m.v.c的解偶，保证了可扩展性，可复用性，严格的遵守逻辑剥离到c中，也会大幅提高可维护性。但是我们需要在准确的践行这种设计理念的基础上，再进行一些扩展。
游戏UI框架设计

MVC的抽象及扩展

• 数据(Model)
  

游戏的数据一部分来自网络协议，一部分来自配置表，还有一些是运行时数据，游戏ui展示的数据往往是这几类的组个，数据的多样性导致了无法像软件中的数据对象那样具体，所以我们需要有对数据的再组织模块，这个模块就是model。

• 界面(View)
  

View的作用就是组织预制件中的各种控件，比如button，text，image等控件的显示逻辑，与响应回调。但是要严格遵守面向接口编程的原则，View与Controller是聚合关系，即整体与部分的关系，View中控件的逻辑全部从controller中获取

• 逻辑(Controller)
  

  Controller基类中维护一组接口，实现基础功能，具体的子类去覆盖个性化实现。

• 中介者（Mediator）
  

  游戏ui的一个特点是需要频繁的打开和关闭，必须有一个入口去管理某一个View的不同打开逻辑，比如打开副本组队，大世界组队，需要的controller要变化，同时也负责View与Controller的聚合逻辑。
这是一个完整的元素组成，具备这几个元素我们就可以达到可复用，可扩展，可维护的效果。
框架结构



效果

• 如何复用View
  

实现controllerA，controllerB，将View中传入不同的controller即可以达到复用View，替换逻辑的效果。

• 如何复用Controller代码
  

继承基类controller即可

• 线上View的代码如何扩展，即如何做到修改关闭，扩展开放
  

使用外观模式，即可以在不改变原有代码的情况下新增新的功能
存在的问题

  争议最大的问题就是如果严格遵循上面的抽象，每添加一个界面，就是增加4个代码文件，可能有的文件就几行代码，数百个界面，近千个文件，只是ui逻辑，想想就头疼。所以要退回到MV甚至是V嘛？我们不能因噎废食而彻底抛弃了MVC这种最核心的思想，彻底放弃也就意味丧失了可复用，可扩展，可维护的能力。上面的MVE模式就是抛弃了核心思想，在面对复用扩展时会很乏力。
解决方案

  依靠经验灵活的使用框架。不要一味地遵循物理结构，就可以达到在快的基础上，又可以复用，扩展，维护。

重构。始终铭记MVC的核心思想，即使开发成了MV或者V模式，我们也可以在重构时及时调整。

• 逻辑确定，UI稳定不复用，退回到MV或者V。
  
• 逻辑不确定，UI要复用，直接使用MVC。
  

我昕依旧

求沙发