找回密码
 立即注册
查看: 213|回复: 4

Unity 游戏框架的搭建有哪些技巧?

[复制链接]
发表于 2024-7-15 17:55 | 显示全部楼层 |阅读模式
Unity 游戏框架的搭建有哪些技巧?
发表于 2024-7-15 17:55 | 显示全部楼层
Unity作为全球最知名的游戏引擎之一,功能已经做的非常完善了,为什么我们还要在开发项目的时候需要搭建游戏框架呢?基于Unity来搭建一个游戏框架,我们又应该如何思考,如何做?今天给大家分享一些Unity游戏框架搭建相关的内容和理念。
对惹,这里有一游戏开发交流小组,希望大家可以点击进来一起交流一下开发经验呀
为什么有Unity引擎还要搭建一个游戏框架?

Unity是游戏引擎,面对的是任意类型的游戏使用和不同的开发团队。所以他提供的是机制,很少提供一些具体的策略,比如资源管理,提供addressable/asssetsBundle机制。比如开发模式提供组件化开发的模式,比如编辑器




Unity游戏框架要解决哪些问题?

上面了解了我们为何有了Unity引擎还要搭建Unity框架,接下来我们来分析一下一个Unity游戏开发框架到底要解决哪些问题,确定哪些策略和机制。
首先要确定的就是组织代码和资源的方式。我们做项目需要维护,需要多人协作,同时开发游戏,包含了美术,策划,程序等多个岗位的开发人员。如果通过制定一个策略把这些开发人员组织在一起,比如目录结构如何划分,美


其次要考虑的是游戏的核心玩法所需要的美术风格,渲染效果和游戏性能。对于一个游戏而言最重要的现在就是玩法与效果,所以客户端的游戏效果是什么样子对于游戏来说很重要,所以很多大型的游戏公司里面做项目的第一件


还有可能要针对游戏的玩法和类型开发一些特殊的工具,比如地图编辑器,比如关卡编辑器,比如路径点标记等等。这些就需要开发一些特殊的工具和脚本。
最后要做的就是上线发布时候必要的一些工具和功能,比如SDK对接,打空包,资源更新,代码热更新等。考虑这些,也是我们做游戏框架必须要解决的问题,而这些问题一般Unity引擎不会直接提供。
Unity 游戏框架具体如何设计

通过上面的描述大家明白了为什么要基于Unity游戏引擎来搭建框架,那么当我们要做一个类型的游戏的时候如何来做游戏框架呢?我这边分享一个我带项目时候的具体的做法,供大家参考。
首先策划会告诉我这个游戏的核心玩法,我要快速的确认这个游戏的美术风格细节(光照,影音等),确认最复杂最消耗性能的战斗客户端的性能是否能支持,最快的速度模拟这种性能极限来做渲染管线的定制和Shader优化等。


渲染效果与性能问题解决后,接下来就开始做常用的一些功能模块来支撑业务逻辑的开发,首先是目录结构的组织,游戏框架代码的启动流程,各个常用的游戏模块: 资源管理模块, 调试日志模块,UI管理模块, 网络管理模块,数据表格管理模块, 一些工具性质的代码,如http上传下载, 工具类的函数等。


最后就是针对游戏玩法关卡设计等,开发一些工具,比如关卡编辑器,地图编辑器与路径烘培等。
这些东西都做好了以后,针对这个项目的框架就算做好了,大家基于这套来进行开发协作,框架也就做好了。

今天的分享就到这里.主页里可以获取一些更多的Unity 游戏开发相关的技术讲解和教程。

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

×
发表于 2024-7-15 17:56 | 显示全部楼层
没啥技巧可言,给够Unity公司钱,活自然成。否则就是商业游戏投资人的血泪教训。
发表于 2024-7-15 17:56 | 显示全部楼层
前言

很多刚开始做游戏的小伙伴感觉战斗系统是一个比较麻烦的部分,不知道如何设计,角色很多,职业很多,技能有好几种,还有装备相关的东西。今天这篇文章详细的讲解一个战斗系统应该如何架构与设计,你看完并搞懂它,战斗系统的架构与设计对你来说再也没有难度了。首先我们先来上一张架构图:
对惹,这里有一个游戏开发交流小组,希望大家可以点击进来一起交流一下开发经验呀!


如图,我们把整个的战斗系统分成了3个层次,分别为功能组件层, 策略层, 行为决策层。
我们的战斗系统将围绕这这3个层次参考设计,接下来我们具体的分析每一层是做什么的,哪些代码应该放到哪一层,如何实现。
1: 功能组件层




2: 行为策略层


3 操作决策层


今天给大家分享了战斗的三层设计,我结合这个设计也做了一个视频教程《Unity如何架构设计战斗系统》与战斗代码demo,方便大家具体学习与实践。
战斗系统核心技术之《3D角色的UI血条架构与设计》

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

×
发表于 2024-7-15 17:57 | 显示全部楼层
感谢您的点赞和关注!
关注我 @空名先生
☺️关于作者

众所周知,人生是一个漫长的流程,不断克服困难,不断反思前进的过程♻️。在这个过程中会产生很多对于人生的质疑和思考,于是我决定将自己的思考,经验和故事全部分享出来,以此寻找共鸣‍✈️!!! 专注于Android/Unity和各种游戏开发技巧,以及各种资源分享(网站、工具、素材、源码、游戏等)
☺️前提

✍️为什么要规范/规范的目的

Unity开发通常需要和三维,美术,设计等并行开发,沟通交流频繁,而且中大项目还可能多人开发,所以一个好的项目规范,能提升开发效率。优点多多: - 1.方便代码的交流和分片维护,使代码清晰人人都读得懂,可维护强; - 2.前期开发团队管理效率高,分工明确,有效避免写了后面搞不明白前面,防止了恶性加班; - 3.后期更新/维护速度快,逻辑明确,项目清晰; - 4.规范的代码虽然不一定带来高性能,但一定是优雅的,赏心悦目的,不枯燥提升心情愉悦性; 良好的规范很重要,任谁也不想在“脏乱”的环境工作
☺️实践过程

✍️文件目录规范





image.png

✍️一级目录:

【01_Scenes】:存放所有场景,方便快速找到对应场景,如果场景有先后顺序命名可以挂上编号
【02_UI】:存放2D方面的资源,比如图片精灵等,如果过多可以分二级文件夹,其命名规则和用到的地方相对应
【03_Model】:存放3D资源,模型材质等所有相关内容
【04_NetAndData】:存放网络通信和本地数据库等相关内容,比如:服务器访问,本地存储等
【05_Utils】:存放平时用到的封装工具类,比如:Screen屏幕类,Time类,Math类,文件操作类,时间类,字符串类等等
【06_Scripts】:存放脚本,偏向于存放二处及以上使用次数的脚本,像那些单独使用的脚本且跟控件/模型有关联的,把她们放到一起即可
【07_Audio】:存放声音文件
【08_Others】:存放其他文件,暂时不清楚放在哪个分类下的文件,可以以后再分类
【09_Test】:测试文件夹,平时测试功能,下个测试脚本啥的,都放到这,产品发布之前可以直接删除
【Plugins】:系统默认文件会自动识别,为插件目录,存放扩展Unity编辑器的代码工具,编译的时候不会打包进去
【Prefab】:系统默认文件会自动识别,存放经常反复利用的对象或资源,充分复用
【Resources】:系统默认文件会自动识别,默认的资源路径,发布的时候会自动打包进去,在代码中可以直接访问
有更合适的可以再增加
✍️二级目录:

可以根据自己项目需要增加对应的文件夹,比如存放3D资源的【03_Model】文件夹和存放2D资源的【02_UI】文件夹
3D你可以按照模型分类,也可以按照资源分类




image.png

【Animators】:动画控制器 相关的资源文件。
【Materials】:材质 相关的资源文件。
【Shaders】:着色器 相关的资源文件。
【Scripts】:脚本 相关的资源文件。
【Textures】:纹理 相关的资源文件。
或者
【ModelOne】:存整个模型的所有东西,材质/模型/纹理等
【ModelTwo】:同上,存另一个模型的全部
如上,资源明确,调理清晰, 一看就知道项目层级,至于更深的三四级目录,看项目需要,灵活设置。
✍️文件名规范


  • 1.大驼峰命名法,每个单词首字母大写,并且能够表现出改文件的功能意义。比如有个手模型,可以起名字为:ModelHand
  • 2.同级下且名称相同的文件,命名用下划线”_”加编号来区分,比如:Scene_01,Scene_02,Scene_03,Scene_04
  • 3.同属于一个整体的各个资源名称尽量要一致,比如手模型包含了贴图和对应的脚本,起名:ModelHand,ScriptHand,TexturesHand或者HandModel,HandScript,HandTextures
  • 4.命名尽量使用英文,如果多人协同合作英文有障碍的话,使用拼音,但一定要全拼且符合大驼峰命名。比如手电模型:起名ShouDian,可别来SD,让人误会成SD卡或者傻蛋,非常不推荐缩写。
✍️资源规范


  • 1.命名遵循上面的上面文件命名规范
  • 2.图片资源统一尽量使用png格式
  • 3.图片不要过于追求效果,在不影响视觉的前提下能小就小一些
  • 4.可以提前使用TinyPng软件来进行图片压缩,我在Android中也强烈推荐过,超级神器,效果显著
  • 5.多人协作坐标模式提前商定好,统一的坐标系能帮助更好的观看模型效果,否则会导致场景乱套
  • 6.移动设备面数控制300-1500,PC端建议范围是1500-4000,整个屏幕建议控制在7500面以下
  • 7.贴图尺寸为2的N次方,最大不超过1024*1024,特殊情况再进行特殊处理
✍️代码规范


  • 1.驼峰命名法,且命名要表达出符合她的意思,要么英文要么频音,强烈反对缩写
  • 2.注释尽可能写详细,便于维护和后期查阅
  • 3.禁止在频繁更新的函数(Update/OnGui)中使用协程,声明变量,等创建类操作,对性能造成影响
  • 4.对可能造成功能失效,影响业务流程的代码添加异常捕获,便于调试
  • 5.尽可能将计算量大的耗时任务放到子线程进行,避免堵塞
  • 6.其他规范待补充
作者:小空和小芝中的小空 转载说明:务必注明来源:https://www.zhihu.com/people/zhimalier 这位道友请留步⛅,我观你气度不凡⏰,谈吐间隐隐有王者霸气 ,日后定有一番大作为 ⭐!!!旁边有点赞 收藏 今日传你,点了吧,未来你成功☀️,我分文不取,若不成功⚡️,也好回来找我。
关注我 @空名先生
☺️『更多专栏』:

️‍❤️‍点击跳转->Unity一路向东
‍❤️‍点击跳转->有意思又酷的网站网址
‍❤️‍点击跳转->精致神器软件推荐​
‍❤️‍点击跳转->精品书籍图谱​
‍❤️‍点击跳转->中国神话联盟宇宙​
‍❤️‍点击跳转->Android 指南​

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

×
懒得打字嘛,点击右侧快捷回复 【右侧内容,后台自定义】
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

小黑屋|手机版|Unity开发者联盟 ( 粤ICP备20003399号 )

GMT+8, 2024-11-21 20:54 , Processed in 0.130474 second(s), 28 queries .

Powered by Discuz! X3.5 Licensed

© 2001-2024 Discuz! Team.

快速回复 返回顶部 返回列表