个人开发测试

  • 关于
  • 历史项目
  • 游戏开发
    • 一些轮子
    • Unity
    • UnReal
    • Godot
    • 常用框架
  • 游戏设计
    • 游戏品类研究
    • 游戏心理学
    • 游戏杂谈
  • 计算机科学
    • 算法、数据结构
    • 图形学
    • 网络
    • 计算机语言
  • 留言板
  • 推荐
游戏开发/个人感悟/一些废话
  1. 首页
  2. 游戏开发
  3. 常用框架
  4. 正文

【0】【常用框架】框架-概述

2022年1月22日 1858点热度 0人点赞 0条评论

软件开发中的框架(FrameWork)主要是在多人合作中起到约束和规范的作用,帮助团队开发者更高效地组织代码,降低人员流动对团队带来的影响。需要明确的是,世界上没有最好的框架,只有最适合团队的。

框架一般会包含几个部分,具体通用逻辑的拆分,足够通用的中间件和工具,以及依赖某种特定的设计模式组织代码模块。并且,使用不同的编程思想设计的框架各有不同。不过核心思想都是保证工程内各模块的高内聚低耦合。提升代码拓展性和稳定性。

在之前的工作与学习生涯中,笔者多次负责团队代码框架的搭建和维护的工作,私以为姑且可以和大家聊聊这部分的内容。今天先聊个大概,后面再拓展。

在游戏开发中,配合unity,一共会有几种常见的代码组织方式。

【EmptyGo】

姑且可以称为一种代码组织结构,无数不同用处的脚本直接挂载到各种GameObject上,各种GameObject.Find和脚本间相互引用多到飞起。恭喜你,你的项目现在是一个可以跑的状态了。俗话说:”代码和人有一个能跑就可以“。

优点:初学者最爱,不需要理解,猴子都会。

缺点:后期耦到不可想象,史诗级的灾难。

【Simple GameManager】

上一种方式的进阶方案,在无序中寻找秩序。恭喜你这次学聪明了,使用了全局大单例用来控制各部分,各种类的实例和全局变量都可以在这里引用,一个大HUB接了无数条线。相比上一种方案确实优越了不少,项目现在甚至可以稍微高效地跑起来了。

优点:干掉了各种耗时的Find操作,对代码有了初阶的管理意识。小型项目可以用起来了(demo)。

缺点:不符合即插即用原则(plug and play),毫无拓展性可言。

【MOM】

MOM即Manager Of Managers,是笔者十分推崇的适用于Unity的代码组织结构,上述大单例的进阶版本。大单例管理所有manager,并根据项目需要拓展不同的子manager进行管理,每一个子manager 下都可以再使用嵌套的MVX进行组织,保证模块的高内聚低耦合,具有强拓展性。在中大型项目上都有很好的用武之地。

一般来讲在Unity中实现下述几个Manager就够用了:EventManager、AudioManager、GUIManager、PoolManager、LevelManager、GameManager、SaveManager、MenuManager。之后有时间可以带大家做一下。

优点:强拓展性,高可用性

【MVX】

MVX中的X是缩写,这个分支包含了MVC,MVCS和MVVM。MVX架构是标准的软件工程架构,每一个码农应该都见识过了。核心思想是数据,显示和逻辑的分离。目的也是模块的高内聚低耦合。一般在游戏开发中,会视具体业务内容,在每个业务实现内部实现MVX。

MVC:Model(数据),View(显示),Controller(逻辑)

MVCS:Model (数据) ,View (显示) ,Controller (逻辑) ,Store(数据操作)

( MVCS 的unity相关实现:strangeioc/strangeioc: The IoC/Binding Framework for Unity3D and C# (github.com))

MVVM:Model (数据) ,View (显示) ,ViewModel(数据加工)

( MVVM 的unity相关实现 :InvertGames/uFrame-MVVM: uFrame MVVM Framework for Unity3D (github.com))

MVCS和MVVM都是对于传统MVC的优化方案,其中优化共识都是 Controller 部分会随时间推移越来越臃肿。于是视情况需要为其拓展单独的Store模块处理数据或直接将其拆分为VM。

【ECS】

ECS即Entity(实例) Component(组件) System(逻辑),是Unity2018年在主力推的新架构(DOTS),配合新版Unity的C#jobSystem和Burst Compiler,可以真正在游戏中运用CPU的多核能力。且编程思想从OO转为了DO,从根本上解决了实例化消耗的问题。

核心思想是将传统OO对象上的数据和行为剥离,其中数据部分化身成为 Component ,而行为部分则演化成 System ,OO的对象也进化为DO的 Entity ,即多个 Component 的集合。将大量的逻辑运算替换为批量处理大规模数据可,从而可以配合多线程发挥最大效能,且不需要考虑线程锁。

【总结】

最后写一些笔者的观点:OO作为沿用了很久的编程思想,虽然相较PO具有继承,封装和多态的特性。但是正是因为此类特性,在实际开发过程中会遇到由于过度抽象导致的性能问题。因为本质上对于自然语言友好的编程模式对于计算机而言并不是特别友好的。这个矛盾在游戏开发中尤为凸显(要求时序稳定)。因为游戏逻辑的天然特性,在传统游戏开发流程中,主要Gameplay相关的循环都要放在主线程中,最多额外开辟线程处理网络,音效,物理,动画等外围系统。而在DOTS的架构下,使用DO可以最大化的将数据操作利用起来,真正的实现效率的整体提升。所以ECS是未来的方向。但是我们也需要意识到,ECS在传统Unity项目瓶颈中(UGUI,GC,渲染,物理),能够提供的优化也有限或基本没有增益,建议在数据密集模块中使用。

MOM和MVX也没有优劣之分,在实际应用中也可以存在MOM嵌套MVX的情况,还是那句话,一切以实际需求出发。

OO:面向对象

PO:面向过程

DO:面向数据

补充资料:技术分享|UNITE课程实录:Unity项目架构设计与开发管理(建议收藏) (qq.com)

有空总结一套框架分享出来。

2022.1.22 23:34 于上海漕河泾

标签: 游戏开发
最后更新:2022年6月12日

可以吃的妙脆角

平平无奇的游戏开发者

点赞
下一篇 >

文章评论

razz evil exclaim smile redface biggrin eek confused idea lol mad twisted rolleyes wink cool arrow neutral cry mrgreen drooling persevering
取消回复

归档
  • 2024 年 2 月
  • 2023 年 9 月
  • 2023 年 8 月
  • 2023 年 7 月
  • 2023 年 1 月
  • 2022 年 11 月
  • 2022 年 9 月
  • 2022 年 6 月
  • 2022 年 5 月
  • 2022 年 4 月
  • 2022 年 3 月
  • 2022 年 2 月
  • 2022 年 1 月
  • 2021 年 4 月
  • 2020 年 11 月
  • 2020 年 9 月
  • 2020 年 8 月
  • 2020 年 7 月
  • 2020 年 4 月
分类
  • CSharp
  • Lua
  • NAS
  • Unity
  • 一些轮子
  • 历史项目
  • 尚未分类
  • 常用框架
  • 杂
  • 游戏品类研究
  • 游戏开发
  • 游戏杂谈
  • 游戏设计
  • 计算机科学
已阻挡的垃圾评论
3条垃圾评论已被Akismet阻挡

COPYRIGHT © 2022 XuYue. ALL RIGHTS RESERVED.

Theme Kratos Made By Seaton Jiang

京ICP备2022001429号-1