ProjectS中的全局光照系统(开发中)
文章已于2024.2.18重写,去掉老旧的传统GI方案,准备全面转向VXGI 前言 一开始还是使用的lightmap+lightprobe的传统GI方案,但其实这套方案在大世界项目中并不适用,主要有以下几个缺陷 数据量大,烘焙慢 动态物体只能接受漫反射信息,不能影响场景和其他动态物体 其中第二点尤其致命 当前较为流行的大世界GI方案有以下几大类 半实时Precomputed Radiance Transfer Global Illumination(PRTGI),半动态GI方案,多为离线烘焙一部分场景光照数据,运行时实时采样进行光照计算 动态漫反射全局光照(Dynamic Diffuse Global Illumination)(DDGI),PRTGI的全实时版本,把烘焙放在运行时,类似的还有SurfelGI Voxel Global Illumination(VXGI),体素+RayCast流派 其中VXGI是将场景体素化,并在体素存储几何和材质信息,从而实现实时ReLight 我们都知道,对于大世界来说,游戏的寻路和碰撞也是很令人头痛的一件事,尤其是在Unity上 ...
以线性时间绘制非分层整齐树的实践与应用
故事还是要从去年春节说起,当时临近除夕实在闲的蛋疼,随意摩挲着MAC唯一比较舒服的触摸板,突然想起我的行为树乱糟糟的布局,就想着能不能搞个自动布局算法,充分利用空间的同时让行为树更加整洁大方,说干就干 吭哧吭哧3天时间(是的,你没猜错,我猪脑又过载了)终于是写完了一版行为树自动布局工具,当时够用了,于是就没管了 前阵子在给 基于行为树的MOBA技能系统:朝花夕拾 · 现代化的动画系统设计与开发 开发Playable Debug工具的时候,需求是横向布局对齐,参考了 Reingold-Tilford Algorithm 进行实现 最近我的运行时节点编辑器依旧有自动布局的需求,本来可以直接复用之前写的节点自动布局算法,但由于运行时节点编辑器和NodeGraphProcessor的节点数据结构天差地别,改起来非常折磨,想到后面可能还有什么地方有自动布局的需求,干脆抽离出一个通用的算法库,同时支持 从上到下,从左到右,从右到左,从下到上的树结构自动布局 说起来有4类情况,其实只需要写一个算法,然后对结果进行旋转 + 后处理即可 这次没有再埋头苦干,而是翻阅了大量资料,找到了一个无论...
基于行为树的MOBA技能系统:朝花夕拾 · 现代化的动画系统设计与开发
基于行为树的Moba技能系统系列文章总目录:https://www.lfzxb.top/nkgmoba-totaltabs/ 今天也是冒着猪脑过载的风险想出了这么个像那么回事的标题,我命令看这个文章的所有人都狠狠的夸标题 2021.6.1,随着我战斗系统系列文章的发布,初版的动画系统也是第一次进入了大家的视野,文章中阐述了Unity动画状态机的缺陷,以及使用Playable API的理由,并且最后使用了 Animancer 作为Playable API的封装,然后在技能配置时进行指定一些动画过渡,Avatar,混合相关的参数 随后在代码里以这种方式进行处理 123456789101112131415161718192021222324252627public AnimancerState PlaySkillAnim(string stateTypes, PlayAnimInfo.AvatarMaskType avatarMaskType = PlayAnimInfo.AvatarMaskType.None, float fadeDuration = 0.25f, f...
一次更换电脑机箱的记录
直到今天之前,我都认为机箱空间一般都不怎么影响性能,毕竟还有那种ITX机箱的存在不是? 我的显卡是微星魔龙3060ti双风扇版本,本身的散热是过硬的,但不知怎么,在高负荷的情况下会有很严重的咔吧咔吧的响声,我一直以为是显卡本身的问题,但碍于我没有备用的亮机卡,也就一直没有送去维修。直到昨天,我突发奇想,会不会因为机箱留给显卡本身的散热空间太小了,从而导致积热?这是之前机箱的图 感觉有可能,正好看这个机箱很不爽了,说换就换,今天机箱到了之后,花了一小时把硬件搬个家,这是现在的机箱图,箭头标识的就是留给显卡的散热空间 然后跑了下3D Mark,我泪目了,不论是稳定性还是性能,都全面超越了老机箱,机箱空间真的很重要啊! GPU稳定性测试对比 旧 新 CPU && GPU分数对比 旧 新
《层层梦境》一个ACT Roguelite的巅峰之作
故事还是要从我偶然在油管上看到的一个GDC分享说起 封面很炫酷嘛,颜色明艳,画面清晰又朦胧,看标题应该是讲ACT连招动作设计的,于是就怀着好奇的心态点进去看了看,这一看,直接被圈粉了 演讲者从0开始,细致入微的讲解ACT游戏中的动作该如何设计才能增强表现力和打击感,并且附带了相当丰富的示例用于佐证,也正是这些示例深深吸引了我,我发现这游戏和我之前玩过的肉鸽战斗设计侧重点完全不一样,相比于《黑帝斯》,《暖雪》之流,《层层梦境》更注重核心单局的动作交互与体验,而不是一味的堆叠Build,从而演变成暗黑类的刷刷刷游戏,嗯,硬要说的话,可以归类于和《死亡细胞》同类的肉鸽,但我认为,《层层梦境》的战斗体验和玩法设计是当今ACT肉鸽最强,没有之一。 也是趁中秋节把游戏通关了,多有感触,遂有此文 (我不允许有肉鸽玩家没玩过层层梦境,也不允许有游戏开发者没看过这个动作设计的GDC分享) 2024.7.26发现了一片机核上的文章:《层层梦境》:小型独立团队如何打造杀手级战斗系统 游戏整体结构 游戏整体结构是相当正统的Roguelite,局外持续养成,局内永久死亡 剧情 由于游戏本身采用碎片化的...
从零开始基于TeamCity搭建项目的CI工作流
CI的介绍和意义 CI简单来说就是把一些流程化,重复性的人力操作放在机器上去执行的过程,从而节省大量用户的时间,并且保证构建得出的产物一定是主干最新的。 所以CI对于工程项目来说意义重大,当然对于Unity,UE这种游戏研发项目更是如此,因为稍微大点的项目出一次版本可能要10-20分钟,此外还有一些工程特化的功能例如AB构建,Shader变体搜集,各种本地缓存构建,甚至是性能监测报告,GI烘焙,PCG生成,场景切割等重度流程,很难想象这些不放在流水线上让机器自动执行,会浪费大家多少时间 为什么是TeamCity 对比Jenkins和TeamCity的使用感受,TeamCity有几个非常明显的优势 环境搭建简单,不论是Server还是Client 界面友好,美观大方 流水线拓展支持更加丰富的语言类型 环境变量提示友好,更不容易出错 Docker支持完善,方便做云服务器迁移 一些其他的基础设施比Jenkins更加完善(例如自动化单元测试),使用起来更加友好 综上,TeamCity相对于Jenkins是一个更加现代化的方案,所以我们也选择TeamCity作为CI方案 搭建教程 总...
UniTask中文文档
UniTask 为Unity提供一个高性能,0GC的async/await异步方案。 基于值类型的UniTask<T>和自定义的 AsyncMethodBuilder 来实现0GC 使所有 Unity 的 AsyncOperations 和 Coroutines 可等待 基于 PlayerLoop 的任务( UniTask.Yield, UniTask.Delay, UniTask.DelayFrame, etc…) 可以替换所有协程操作 对MonoBehaviour 消息事件和 uGUI 事件进行 可等待/异步枚举 拓展 完全在 Unity 的 PlayerLoop 上运行,因此不使用Thread,并且同样能在 WebGL、wasm 等平台上运行。 带有 Channel 和 AsyncReactiveProperty的异步 LINQ, 提供一个 TaskTracker EditorWindow 以追踪所有UniTask分配来预防内存泄漏 与原生 Task/ValueTask/IValueTaskSource 高度兼容的行为 有关技术细节,请参阅博客文章:UniT...
ET7+FariyGUI+huatuo+luban+yooasset接入教程
前言 ProjectS已正式启动,准备先搭建项目框架以及整理工作流程,框架方面准备进行如下开发工作,为日后的业务开发铺好道路 接入 ET 7.0 接入 huatuo C#代码热更方案 接入 YooAssset 资源热更方案 接入 FGUI UI方案 ,并提供MVVM UI框架 接入 luban 配置表方案,并提供周边工具链 接入 UniTask,全量替换ETTask 全面移植 NKGMoba技能系统,及其周边工具链 文章主要描述各仓库接入思路和过程,目前已完成接入工作,并已开源,https://github.com/wqaetly/ET/tree/et7_fgui_yooasset_luban_huatuo,已经在最大限度上保留ET特点了,并且存档了一个Release:https://github.com/wqaetly/ET/releases/tag/et7_fgui_luban_huatuo_yooasset,追求ET原生开发体验的朋友可以下载体验了。但对于我个人而言,使用起来还有诸多不便,所以还会再进行魔改,望周知。 留个封面背景图: ET7 ET7于前阵子发布,虽然...
代号ProjectS企划案
开端 我在初三时开始接触英魂之刃这款MOBA游戏,各种各样的英雄和有趣多变的英雄自然是给了第一次接触这种类型游戏的我留下了很深刻的印象,玩了一段时间后关注了贴吧,每天就在里面看各路大神和水友们发帖,直到有一天刷到了一篇自制英雄的帖子,大致内容就是楼主用文字的形式描述了自己心目中的英雄,当时只觉得很有意思,但也只是匆匆划过,没有下文 事实上直到今天有相当一部分的玩家对于自制英雄有相当大的热情: 2020年12月4日,《英魂之刃口袋版》举办新英雄设计大赛,邀请玩家发挥脑洞,一起参与MOBA英雄设计。活动开启后,许多玩家在英魂社区踊跃分享自己的创意和灵感,讨论互动。历时20余天,大赛累计收到投稿超过3000份,最终筛选出16个入围作品与50个优秀作品。 最近又在玩流放之路,其中主动技能宝石 + 被动技能宝石的设定极大丰富了各种技能之间的搭配种类,仔细思考可以搭配出很有意思的技能 回想起大学的时候玩过的恐怖黎明,虽然技能的可定制化程度不如流放之路,但通过星座信仰对职业架构进行补全的设定也是有自定义技能的味道在里面的 从上面的这几个例子,可以看到很多玩家对于自定义这个行为有相当大的热情...
游戏设计精粹《四》
游戏设计精粹《总目录》 游戏系统设计的基石:体验树 文章摘要个人总结介绍的是**体验树理论,它是分析游戏系统设计好坏的理论工具,它能将系统设计所带给玩家的体验量化、可视化,以此检视系统是否设计得足够好玩。**这个理论从诞生至今,已快20年,发展出了一整套完整、分支庞大的系统设计理论。 以经典的俄罗斯方块为例: 玩家具备初始的技能,玩家通过这些技能观察和认识游戏规则,并根据规则认知构建出来的认知模型,处理面临的问题,解决问题,验证想法,在过程中获得乐趣。 体验树理论可以进行各个方向的拓展,如果把体验树中各个方格进行拓展,就形成了**“输入-反馈-认知”基元**,如果把时间加进去,就能通过各个基元完整形成的时间,从而确定游戏卡点。如果将整个体验树放于直角坐标系中,横轴代表复杂度,纵轴代表游戏深度,就形成了**“复杂度-深度”体验模型**,复杂度越低,深度越深,代表游戏越好玩。介绍了一套将游戏中所有系统平铺,展开,然后通过节点可视化出来的的理论体系,并以此为基础提供游戏是否足够好玩的评判标准。在进行游戏系统设计的时候可以酌情参考这种做法。 Noita中涌现式设计与GamePlay的冲...












