当前位置:   article > 正文

【Unity自动化游戏框架】通用自动化游戏框架 爽到起飞的工作流 巨幅提升效率 质量 产能_unity 游戏框架

unity 游戏框架

https://github.com/sunsvip/GF_HybridCLRicon-default.png?t=N7T8https://github.com/sunsvip/GF_HybridCLR

开始GF_HybridCLR自动化通用游戏框架,功能设计和用法的系列博文;

GF_HybridCLR通用框架介绍

自动化工作流框架打包/HybridCLR热更流程 万人同屏战斗项目模板

视频中demo测试包下载,以及万人同屏方案性能测试,有需要的老板可以某宝【搜店铺】:【游戏开发资源商店】:https://pan.baidu.com/s/1ML0DC8s0RkkTAraN9maltw?pwd=blueicon-default.png?t=N7T8https://pan.baidu.com/s/1ML0DC8s0RkkTAraN9maltw?pwd=blue

前言:

"工欲善其事必先利其器",  好的框架是对开发工作流的规范化、简单化,当然,高性能是基础必要条件。一个完善的游戏框架不仅能大幅提高开发效率、提高项目质量,还能让程序员码字的时候思路清晰、心情舒畅。

从业以来,接触过很多客户端"框架",架构主要是MVC、 ECS当然最多的还是Manager of managers。诸多心酸,懂的人都懂。设计通用框架的前提,必须要项目经验丰富,熟知项目开发上下游痛点。并且至少吃过细糠,熟悉市面上已有的优秀客户端框架是如何设计的。一定不要盲目重复造轮子,为了设计而设计,以自己的开发习惯为中心,在不了解游戏开发痛点、也不知道优秀通用框架都具备哪些必要特性的情况下闭门造车,毫不权衡、不考虑团队和项目需求。毫无疑问,适用于团队开发的通用游戏框架,必须考虑团队技术成员的整体能力,应该是保证高性能的同时,规范简化开发流程、降低开发门槛、提升开发效率。

当然,以上都是废话,最重要的是不用加班了。因为提高效率和质量,能避免堆成屎山,避免大量无谓的内耗加班。

GameFramework简介:

GameFramework是一款设计非常优秀的开源游戏框架。我最早接触于2018年,在诸多陌生的开源客户端框架里,选择了star最多的一个。在自己的毕业设计《MOBA游戏战地王者的设计与开发》中一边学习GF一边应用于毕设项目开发。接触之初,由于能力问题,很不习惯GF的开发方式。因为在此之前的习惯都是直接在场景中挂几个MonoBehavior一点运行游戏就跑起来了,毫不考虑性能、灵活、可配置、团队协作等等,在做毕设这种相对完整、大型的项目时,这种方式一团糟,已经远远无法满足需要。我非常清楚,如果一直呆在自己的眼界中的"舒适区",保持自己的“习惯”,从不"睁眼看世界",不进行变革升级,那么这个人分分钟将被急速发展的互联网技术淘汰,成为行业寒冬下,“优化”名单里的首选。

有些新手刚接触时给出"过度设计"的评价,熟悉框架之后才会明白这么设计有多么精巧。实际上GF暴露给用户层的接口非常简洁,总结一下就是GameObject显示/隐藏只需ShowEntity()、HideEntity(), UI打开/关闭只需OpenUIForm(), CloseUIForm(); 用户层只管调用,至于内部复杂的对象池复用、释放,资源加载、释放,都由GF框架内部自动管理。 API或生命周期函数命名的规范化也是GF的一大亮点。GF内部实现大量使用了接口(Interface),以至于初学者想跳转查看内部实现,结果都跳转到了抽象接口,因此认为"过度设计"; 

GF把核心模块与游戏引擎解耦,抽离出了一个核心叫GameFramework程序集, 而引擎相关接口封装为UnityGameFramework, 去实现GameFramework的各种功能接口;GameFramework程序集就实现了跨引擎。并且GF使用了大量解耦设计,比如Helper接口,我们只需实现Helper接口就能对各个功能模块自定义;

这也就是为什么GF已经三年没有更新,却依然没有被淘汰,依然能跟得上时代的原因。比如随着时间的发展,技术不断更新进步,其间出现了更好的json插件或者zstring(无GC的字符串格式化、连接插件),我们只需使用这些插件实现GF序列化、文本处理接口,就可以一键切换使GF用上这些新特性。

如果我写不出更好的框架,就绝不会自己去重复造轮子。当然,我始终喜欢用最新、最好的技术。也一直在刷着当前市面上最新的技术,以及是否出现更完美的游戏客户端框架,如果有更好的选择,我会毫不犹豫选择更好的。技术世界就是这样,永远追逐最佳方案。

通过自定义Helper实现框架接口以使用新功能

通过自定义Helper实现GF接口实现自己解析多语言方式

HybridCLR简介:

HybridCLR是新一代的C#热更方案,通过修改Unity对应版本的il2cpp源码使其拥有运行时动态加载assembly的能力。可以用纯C#开发工作流,无感知的支持代码热更,极大提高了热更项目开发效率。

偶尔会听到神言论,说将来Unity转向XXX技术,学习NNN无用论,每个时代有每个时代的最佳方案,我们要做的不是杞人忧天,考虑布局一百年,而让自己固步自封,任何技术都不能吃一辈子。无论Unity何时转向NativeAOT,无论届时HybridCLR能否完美适配,都不能影响当下HybridCLR是热更新首选方案。

自动化:

自动化、简单化、高效化是GF_HybridCLR的宗旨, "懒"是核心驱动力。功能随着本人从业以来参与设计研发无数个项目中,遇到的痛点以及推敲可能遇到的问题,以及作为设计师对用户体验的极致追求。把多年来的沉淀总结完善到了框架内,作为自动化工具链;

1,功能工具栏

首先映入眼帘的是醒目的框架工具栏,这些是点击频率最高的按钮,位置必须醒目,用户体验上必须拒绝拖沓,使用频率高的菜单,能点一下绝不点两下。

核心功能工具栏

当然,有一些无关痛痒的、自动化流程自动执行的命令(如刷新数据表),为了给用户留出选择权(我可以不用,但你不能没有), 这些优先级低的命令,才会以Unity顶部菜单栏的形式留给用户,如:

 好的工作流,就像写一篇好文章一样,层次丰富、言简意赅、主题清晰、用意明了。不宜用力过猛,恰到好处;

Toolbar工具栏功能设计:

 ① 场景切换:

你有没有打开一个项目后,再一层一层翻目录找启动场景?

你有没有半路进入一个项目组后,打开项目一脸懵,不知场景在哪?怎么启动?

谢特?这么影响用户体验的痛点怎么能存在?

直接点击弹出场景选择下拉列表, 点击即可切换场景。

②一键打包/打热更工具:

你有没有打包前要设置一堆参数?

如果接了HybridCLR热更,还要执行一堆前置工作,配置手忙脚乱,丢三落四,漏掉某个步骤就会出现莫名其妙的问题,再重新来过?

打包工具窗口全部解决,并且支持部署Jenkins远程打包、单机/热更模式一键切换。

一键打包工具界面
③ App基础配置:

什么?配置项七零八落?菜单九进九出?

策划总忘记导表、生成表代码?

App Config把项目配置齐聚一堂,设计分辨率、流程、数据表、常量表、多语言都在这里;

勾选即启用,配置表、常量表、多语言,自动检测文件改变,自动刷新导出到工程;

④工具集:

什么?包体优化困难?

多语言填写麻烦、容易遗漏?废弃的多语言Key没人处理,冗余越来越严重?

...

 游戏开发中常用的功能汇聚于此,并且支持轻松扩展,只需继承工具基类编写自己的功能,工具栏内就会自动显示你的自定义工具入口;

框架内置了痛点覆盖面相当广的工具集,如:代码裁剪配置工具、包体优化工具集(图片/图集压缩、动画文件压缩)、语言国际化自动扫描翻译工具、一键换字体、图片艺术字生成、AOT元数据补充配置、ChatGPT AI助手等;

都是直击痛点的工具,功能太多,不逐一说明;

包体优化工具集:批量处理大规模文件,大幅优化包体大小
包体优化工具集
多语言工具: 一键精准扫描代码、Prefab、数据表中的多语言文本;一键增删支持语种;自动生成多语言excel、自动翻译多语言;
多语言扫描翻译工具
⑤打开代码工程:

 啥?想打开代码工程还要找个脚本去打开?

Assets->Open C# Project还要翻菜单?

直接Toolbar一键打开代码工程,用户体验第一位,分秒必争;

2,UI代码生成工具:

你还在手动写UI变量?还在拖拖拽拽?

UI代码生成工具,直接点击Hierarchy节点批量选择添加UI变量、批量添加按钮回调事件;

隔离式生成partial独立UI变量代码,一键添加变量自动绑定、自动命名、支持数组;编码效率飞跃提升;

API接口的简化扩展: 

GameFramework虽然已经极大的将接口封装简化,但毕竟有灵活性包袱。很多接口需要提供的参数过多,针对这些问题通过静态扩展的方式,大幅简化扩展接口,可以说将开发门槛降低到海平面以下,傻瓜式接口调用。

你还在为找功能类、背API而烦恼?GF_HybridCLR中,所有功能只需GF.XXX即可访问,模块极致清晰,即使是首次使用,也能通过API名称精准找到想要使用的功能接口。

以及扩展了游戏项目中各种常用功能,太多太多。。感兴趣的可以亲自试试,告诉你什么叫细糠!

最后也祝愿行业寒冬下的同仁,永远拥有最高的竞争力,永远得心应手、游刃有余。也祝愿大家和我一样,从来没加过班、从来不用加班。

声明:本文内容由网友自发贡献,转载请注明出处:【wpsshop】
推荐阅读
相关标签
  

闽ICP备14008679号