使用Unity开发游戏，有流行的框架嘛？
看到web开发，或者是app开发，都在大谈特谈mvc 或者mvvm框架 ，难道这些东西游戏开发不常用嘛？ 有没有适合unity开发的游戏框架呢？ 提到游戏的UI开发，几乎没人没听说过MVC吧？MVC最早是为软件架构设计的框架，这里不打算讲MVC的演变过程，需要的了解的可以参考大神的文章，传送门：你对MVC、MVP、MVVM 三种组合模式分别有什么样的理解？ 高赞回答。
另外，我也喜欢第二个回答的总结：
M-V- X 本质都是一样的 重点还是在于M-V 的桥梁，要靠X来牵线。
在相同技术栈下 能够实现的各种 X都可以是大同小异的。
在不同技术栈下 相同的X可能实现都大相径庭，仅有非常抽象的流程类似。
所以UI部分的开篇我们不讲代码，只讲概念。
1.1 M-V-C
看下百度百科的定义：
MVC全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。
架构的兴起有它的时代和背景意义，那么随着时代的变迁，工具和大环境甚至是目标设备的变化，框架都是需要逐步调整的。
MVC出现的初衷是源自于与操作系统和软件的日益复杂化。MFC或者VB那种界面和逻辑揉在在一起的模式已经远远不能满足于大型复杂的功能系统开发。
然后随着软件行业的日益成熟，团队的职能分工也越来越明确，那么如何揉在一起的任务拆离出来，让不同职能的人专注于自己的领域和设计也是一个重要的方面。
基于很多的原因，软件UI框架开始分化为M-V-C的模式。M层专注于数据处理， V层专注实现的专注于表现，柱状图，饼状图、表格按你意愿。
一个典型的MVC的框架可以这么表示：
话说真的爱死 Unity的Animator编辑器了，好方便。
可以看到这是一个局部生态的自给自足。考虑了大部分的交互和变更情况，并通过规定每个部分的职能来满足功能需求。
但是MVC并不是完美的，严格来说它是只是一种指导性的框架，是综合了大部分的软件需求和时代发展结合得出的相对较优的方案。这种模式仍然存在它的缺陷：
1.局部生态，数据（M层）封闭，如果多个模块需要同一个数据块，数据之间的互通和重用性都非常的低效。
2.局部耦合，虽然在大的环境下实现了局部封闭，但是局部内的各个层之间的逻辑耦合还是很深。
想象一下，如果把上面的局部展示放大到游戏开发中的话会是什么样？
在这个情境下，MVC的框架就不能很好的应对了。游戏数据很多时候是互相依赖，并不能完全封闭。比如角色的属性展示需要用到背包里的装备，背包需要显示货币，货币可能受某些角色属性影响，任务依赖角色等级，同时奖励货币和道具、装备等等。
那么这种情况下，MVC要么需要将M写的非常复杂，每遇到一个新的需求开出一个新的接口，提供数据插叙或者变更，要么写一个通用的M管理器，用来统一中转数据。
在游戏开发这种需求多变，并且数据嘈杂的背景下，无论哪种都不能很好的应对需求，并且开发人员会受到无尽的折磨，在遵循架构和实现需求的之间来回纠结，摩擦，最终写的不伦不类，BUG还超多。
1.2 M-V-P
有需求就要有变化，当一个需求只是个别现象的时候，你可以特殊处理、特殊对待。但需求大批量出现的时候，就得重新审视现在的实现是不是需要重构或者升级了。
来看看谷歌的MVP模式：
https://github.com/googlesamples/android-architecture/tree/todo-mvp/MVP即Model-View-Presenter。
Model的工作就是完成对数据的操纵，数据的获取、存储、数据状态变化都是model层的任务，如网络请求，持久化数据增删改查等任务View只处理视图相关，不做任何逻辑处理。Presenter作为桥梁，处理所有二者之间的中转。
在这个模式下，M和V的连接被完全切断了，以前C层只是负责一些简单的转发和处理，现在P的任务变的更重，除了桥梁的作用之外，还需要做初步甚至高级的逻辑处理来处理M-V或者V-M的交流过程。
居然P的任务变重了，那么相对来说，P也会变得更加臃肿和难以维护，但是好处是将M和V彻底解耦，不管哪一方的实现方式发生变化，只要最终和P同步的数据不变另一方都不需要关心和修改。
另外V的逻辑功能一部分移入P之后，V可以更加专注的处理自身的表现，同时因为对接是通过接口实现的，所以满足接口的各种测试或者模拟都能够得以使用。
另外这里每一个V都对应一个P，写法非常复杂，软件复杂的时候，类和文件贼多。并且它仍然没有解决M复用的问题。
1.3 M-V-VM
MVVM是Model-View-ViewModel的简写。
从示意图上最直观的感受是两个：
1.使用ViewModel替代了Presenter。
2.原本P和V一对一的关系现在变为VM-V一对多的关系。
这解决了什么问题呢？
1.VM在一定程度上能够重用，就表示M层在一定程度上也可以复用了。
2.VM一对多的关系，表示在类和文件的数量和管理上要减轻很多。
VM是通过DataBinding的技术实现V和M之间的关系映射。抛弃了P层的手动关系接口和维护。当然每种技术都有其存在的意义和解决的问题。至于选取什么样的方案去解决问题，就要看项目自己的需求更符合哪一类的设计。如果都没有那就需要自己去实现变种或者是新的设计，当然也可以修改需求的啦。
1.4 游戏开发应该使用什么？
注意，以上的三种方法都是来源于软件，都是来源于软件，都是来源于软件 。游戏开发中也都是套用这些概念来进行UI的开发设计的。至于实现过程依据引擎和平台的差别肯定是不一样的，那么我们使用什么样的方式呢？
我的UI框架设计里，没有使用DataBinding技术，要仔细来靠的话，它可能不属于以上的任意一种。那么我给它命名为MVE!即Model-View-Event。
MVC重点逻辑在V，MVP重点逻辑在P，MVVM，重点逻辑还是在V和VM，V负责UI逻辑部分，VM负责数据绑定部分。
那么MVE可以认为是MVC的一个变种，但是V会和数据中心共享。
话不多说看图：
作为网络游戏来说，数据应该来自两个部分，一部分是策划编辑的数据，一部分是通过服务器下发的数据。界面通过注册事件来订阅指定的事件类型，数据中心通过和服务器之间的交互来获得或者改变数据，并根据需求推送指定的Event，当界面关心的事件发生的时候，它有两个可能，一部分是动态变化的局部更新，可以通过事件带下来，另外一种是整体数据需要去数据中心获取。
举个例子，当我打开背包界面的时候，我需要知道所有的背包数据，因此V和M直接交互，拿到背包的所有道具，并显示自己。然后我吃掉了一个经验丹，这时候服务器会告诉客户端删除一个物品，这个时候数据层会通过事件触发，背包监听了这个事件，然后查找对应的道具ID，删除，然后对背包道具进行局部重新排列刷新。
假设我们还有一个界面叫做一键升级，可以选择吃掉背包内不同种类的经验丹，那么它打开的时候同样找数据中心拿取道具这部分相关的数据做显示，如果这个时候在背包内吃掉一个，那么同样监听了这条消息的一键升级界面也要重新显示数量。
所以V和M的关系只是查询，并不会改变数据，数据的变化只能来自于服务器的协议驱动。（当然一些客户端自定义的用于辅助的数据，比如排序列表，计时器等VIEW层自己变化就好。）
另外，其实开篇我也有提到，这里再说一下：
M-V-X 本质都是一样的 重点还是在于M-V的桥梁，要靠X来牵线。
在相同技术栈下 能够实现的各种 X都可以是大同小异的。
在不同技术栈下 相同的X可能实现都大相径庭，仅有非常抽象的流程类似。
再者，不管是框架还是设计模式都是为了解决实际问题的，不需要也不应该为了设计而过度设计，但是也不能完全没有章法，胡乱定义。
一个稳定的，有序的能满足项目需求的实现就是好的实现。切莫过度纠结设计模式和框架结构，但是也不能轻视这部分，够用就好，够用就好。
------------分割线------
以上是我去年在侑虎写的UI框架的第一章节试读，课程地址：
张鑫：【学堂上新】Unity手游UI框架一站式解决方案该课程多次被侑虎列为精品推荐。有兴趣可以看一看。
另外，还有一些战斗的扩展阅读，基于Entitas的战斗实现，是一个ECS框架：
放牛的星星：Unity手游实战：从0开始SLG——ECS战斗（一）ECS设计思想放牛的星星：Unity手游实战：从0开始SLG——ECS战斗（二）Entitas插件放牛的星星：Unity手游实战：从0开始SLG——ECS战斗（三）逻辑与表现分离放牛的星星：Unity手游实战：从0开始SLG——ECS战斗（四）实战ECS架构和优化放牛的星星：Unity手游实战：从0开始SLG——ECS战斗（五）浅谈CPU缓存命中放牛的星星：Unity手游实战：从0开始SLG——ECS战斗（六）Unity面向数据技术栈（DOTS）有一个翻译的渲染合集：
放牛的星星：（完结）Unity图形渲染Part1——基础渲染系列教程20篇（默认渲染管线） UI这边MVC/MVVM结构用的较多
而设计Gameplay部分，就比较麻烦了，没那么多通用的，众所周知的框架。
其实这里还想说一下：
框架只是一种设计思路，为我们更快捷的开发，少些代码，更容易的维护代码服务，没有什么固定的套路可以选用的，就像武功，到达高出无招胜有招。找到适合你游戏的方向的编程模式才是最好的。
我们不可能为一个连连看游戏做一个守望先锋一样的框架不是么？
但是设计的思路总是一样的，我们的代码要安全，要能方便扩展，而且还要低耦合。一般写完了一篇代码，如果觉得思维混乱的话都会重新去重构下代码，看下有什么方法可以去精简的，哪里可以模块化的地方模块化，如果新的一个地方发现可以用到以前的代码功能，就想下能不能画时间做个简单的子系统来统一处理这里。 我想起来一个重要的相关建议，希望能帮到题主或日后看到的同学。
当游戏加载一个scene时需要加载各种资源，除了本来就放在scene里的那些部分，其他的资源加载建议统一写一个加载器，用来根据配置数据动态加载资源、初始化单例、初始化各核心模块、并统一在这里设置各个脚本里需要的引用关系。
如果你是新手，除非你非常清楚自己在做什么并有把握，否则尽量不要在Awake()、Start()里做操作。需要做的初始化工作可以自己写个函数来显式调用。同样的道理，在GameObject的游戏逻辑生命周期结束时、其各组件对象的内存生命周期结束时需要做的工作（比如用到Object Pool时就要做好两者的区分），都显式地分别写函数调用。
以上问题本质上是一个意思，即有关各对象生命周期的开始和结束的函数调用以及调用的顺序都要做到心中有数，尽在掌握之中。 推荐个ECS框架:Entitas，这个框架在 Unite2015 和 Unite2016上有两个视频介绍，主页上也有不少的入门Demo。 1、推荐Ellan大大的Unity游戏框架，Game Framework ，迄今为止我见过的最好的Unity游戏框架。融合了现代游戏框架的诸多优点，组件化的内置模块、分层的框架设计、面向接口编程（同一个模块可以有不同的实现）、易于扩展、强大的资源管理系统（AssetBundle对开发人员透明）、VFS等等优点。 让写游戏代码也成为一种优雅。
官网： 基于 Unity 5.3+ 引擎的游戏框架
github: EllanJiang/GameFramework QFramework: 简单，强大。
文档: http://qframework.io，
github: liangxiegame/QFramework
Unity 游戏框架搭建 2017
Unity 游戏框架搭建 2018
Unity 游戏框架搭建 2019
Unity 游戏框架搭建 2020 & 跟着案例学 Shader
凉鞋的笔记 ECS 用过都说好！谁用谁知道！ 直接百度GameFramework框架，进群或者看博客学习，这将极大提高你的代码质量和游戏开发效率
我自己也有写GameFramework教程
我用#CSDN#这个app发现了有技术含量的博客，小伙伴们求同去《GameFramework框架个人笔记汇总》, 一起来围观吧 https://blog.csdn.net/qq_15020543/article/details/86766583 试过网上一些框架比如IoC和Foundation Framework，结果最后全被我废弃了，有些太过复杂，不适合团队协作，而且有学习成本，最好的框架还是自己搭比较合适
页:
[1]
2