烟雨迷离半世殇的成长之路

前言 前阵子在处理ProjectS中的AI行为时，发现怪物AI规划出的行为很容易造成怪物重叠，这归根到底是个动态避障问题，而当前游戏AI有以下几种常见动态避障算法： VO : 提出速度域的概念，Velocity Obstacle 就是VO的由来。通过相对位置，并从自身出发考虑一个安全的移动方向，即避开VO区域（速度危险区）。但在移动过程中会出现抖动。原因就是反复计算安全区，当第一次避开危险区到达安全区之后，发现最佳移动方向（不一定安全，一般指朝向目标点方向）可能不再危险，就将移动方向转回来，结果发现其他寻路对象也这么考虑，也将移动方向转回来，所以第三次就又将方向转向其他方向。由此引发了移动时的方向抖动 RVO: 在VO的基础上，每次转动方向时，只转动计算出来的变化量的一半。从数学计算角度去减少出错（抖动）概率 RVO2/ORCA: VO与RVO都是在空间计算上来规划一个安全区域，而RVO2则是将其转化成了一个线性规划的问题（即用一个个平面将自己与需要考虑的对象的安全区域分割开来再采取一个共面区域，这个区域就是安全区） 对于这三种算法的详细解析，可参见：GameAIPro3_Ch ...

本文是对GameAIPro2_Chapter18_Context_Steering_Behavior-Driven_Steering_at_the_Macro_Scale 进行的中文翻译 译文 介绍 在游戏行业中，转向行为（Steering Behaviour）是非常普遍的。他们之所以这么流行，是因为其只需要使用简单组件就可以快速实现核心功能。 然而，转向行为并不适合用于某些类型的游戏。当玩家能够挑选并监控单个实体时，避免碰撞和自然的移动就变得非常重要。为了实现这一目标可能会导致行为组件的膨胀并变得紧耦合，实体运动逻辑也会变得脆弱和难以维护。 在本章中，我们将概述如何识别那些转向行为不太适合的游戏，并提出一种针对这些问题的新方法，它被称之为上下文转向行为（Context Steering）。上下文转向行为（Context Steering Monobehaviours）是小巧的和无状态的（StateLess），并提供任何行为本身所期望的运动约束。当上下文转向行为用于取代游戏F1 2011上的原转向行为时，代码库减少了4000行，但AI在避免碰撞、超车和执行其他有趣的行为方面表现得 ...

游戏设计精粹《总目录》 游戏叙事设计：游戏故事主题设计探讨-50个故事主题设计汇总 文章摘要个人总结 创造游戏重复可玩性的14种方法及解说 文章摘要个人总结 超越罐头：艾尔登法环与下一代开放世界 文章摘要个人总结 辐射挽歌：永远不要背叛你的核心用户 文章摘要个人总结

今年算是颇为平淡的一年，没什么惊喜，也没什么失落，但生活就是这样，我们把这些平淡记下，多年后回首往昔，这些平淡就会成为我们珍贵的回忆与感动的来源 在工作方面，倒真不是我懒，工作总结相关的事情没什么好说的，大家都懂，无非都是些套话，场面话，我也懒得在个人博客里写那些，所以就以总结，记录个人生活经历为主了 一月 归乡 1.25号回到老家的县城，感觉有点饿了，先整碗朝思暮想的大碗米线 老家是一如既往的清冷，不过这种清冷我很喜欢，很安静，窗外的大部分时间都是阳光明媚，冬阳暖暖的 由于只带了个MAC，所以就只是整理了下守望先锋GDC的大纲，一边整理，一边感受着若有若无的家乡冬天特有的冷清，别有一番意味 休整了几天后，手就闲不住了，去村头小卖部买了几盒鞭炮，耍一耍 二月 返途 2月7日，早上5点，天还黑着，就坐着父亲的轿车，准备赶早上10点的飞机，因为要提前两小时值机，所以8点前就要到达机场 一路上倒也平稳，不知不觉就睡着了，忽然感受到一丝冷意，睁开充满困意的眼睛，发现车窗外已经飘起了小雪，觉得有些生气，毕竟在家这么多天连个雪影子都没看到，今天要走了，才开始下雪，都没办法好 ...

前言 临近个人独立项目第一次技术演示，终于也是蚌埠住开始优化场景效果了，说到场景效果，避不开的就是GI，这篇文章就是记录下整个GI系统的架构和开发过程 GI知识体系 直接光照 出于项目风格以及资源可复用性考虑，采用了风格化PBR的光照模型，当然现在风格化还没开始做，就先用Unity URP的Lit代替了 间接光照 环境光 IBL HDR的CubeMap，同时用作天空盒和烘焙GI时的天光 SSAO 增强画面立体感最廉价的方案就是AO，所以也使用了Unity URP的SSAO，做了下DownSample，减少SSAO Effect RT消耗 Shadow Map 基于Unity自带的级联阴影，由于俯视图的特殊性，所以基本上2级的级联阴影就够用了，之所以在俯视图的情况下还是选用级联阴影，是为了兼容玩家们转动到第三人称视角的情况 漫反射 Light Map && Shadow Mask 出于对Unity自带GI系统的使用阴影，选择了广受好评的Bakery插件，简单直观的参数设置和详细的文档说明使用起来事半功倍 烘焙模式为Shadow Mask（Dist ...

故事还是要从去年春节说起，当时临近除夕实在闲的蛋疼，随意摩挲着MAC唯一比较舒服的触摸板，突然想起我的行为树乱糟糟的布局，就想着能不能搞个自动布局算法，充分利用空间的同时让行为树更加整洁大方，说干就干 吭哧吭哧3天时间（是的，你没猜错，我猪脑又过载了）终于是写完了一版行为树自动布局工具，当时够用了，于是就没管了 前阵子在给 基于行为树的MOBA技能系统：朝花夕拾 · 现代化的动画系统设计与开发 开发Playable Debug工具的时候，需求是横向布局对齐，参考了 Reingold-Tilford Algorithm 进行实现 最近我的运行时节点编辑器依旧有自动布局的需求，本来可以直接复用之前写的节点自动布局算法，但由于运行时节点编辑器和NodeGraphProcessor的节点数据结构天差地别，改起来非常折磨，想到后面可能还有什么地方有自动布局的需求，干脆抽离出一个通用的算法库，同时支持 从上到下，从左到右，从右到左，从下到上的树结构自动布局 说起来有4类情况，其实只需要写一个算法，然后对结果进行旋转 + 后处理即可 这次没有再埋头苦干，而是翻阅了大量资料，找到了一个无论是算 ...

基于行为树的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, flo ...

直到今天之前，我都认为机箱空间一般都不怎么影响性能，毕竟还有那种ITX机箱的存在不是？ 我的显卡是微星魔龙3060ti双风扇版本，本身的散热是过硬的，但不知怎么，在高负荷的情况下会有很严重的咔吧咔吧的响声，我一直以为是显卡本身的问题，但碍于我没有备用的亮机卡，也就一直没有送去维修。直到昨天，我突发奇想，会不会因为机箱留给显卡本身的散热空间太小了，从而导致积热？这是之前机箱的图 感觉有可能，正好看这个机箱很不爽了，说换就换，今天机箱到了之后，花了一小时把硬件搬个家，这是现在的机箱图，箭头标识的就是留给显卡的散热空间 然后跑了下3D Mark，我泪目了，不论是稳定性还是性能，都全面超越了老机箱，机箱空间真的很重要啊！ GPU稳定性测试对比 旧 新 CPU && GPU分数对比 旧 新

故事还是要从我偶然在油管上看到的一个GDC分享说起 封面很炫酷嘛，颜色明艳，画面清晰又朦胧，看标题应该是讲ACT连招动作设计的，于是就怀着好奇的心态点进去看了看，这一看，直接被圈粉了 演讲者从0开始，细致入微的讲解ACT游戏中的动作该如何设计才能增强表现力和打击感，并且附带了相当丰富的示例用于佐证，也正是这些示例深深吸引了我，我发现这游戏和我之前玩过的肉鸽战斗设计侧重点完全不一样，相比于《黑帝斯》，《暖雪》之流，《层层梦境》更注重核心单局的动作交互与体验，而不是一味的堆叠Build，从而演变成暗黑类的刷刷刷游戏，嗯，硬要说的话，可以归类于和《死亡细胞》同类的肉鸽，但我认为，《层层梦境》的战斗体验和玩法设计是当今ACT肉鸽最强，没有之一。 也是趁中秋节把游戏通关了，多有感触，遂有此文 （我不允许有肉鸽玩家没玩过层层梦境，也不允许有游戏开发者没看过这个动作设计的GDC分享） 游戏整体结构 游戏整体结构是相当正统的Roguelite，局外持续养成，局内永久死亡 剧情 由于游戏本身采用碎片化的叙事手法，所以仅仅通关一次的话还不足以了解故事的全貌（参考黑帝斯需要多次游玩才能知道整个游戏 ...

CI的介绍和意义 CI简单来说就是把一些流程化，重复性的人力操作放在机器上去执行的过程，从而节省大量用户的时间，并且保证构建得出的产物一定是主干最新的。 所以CI对于工程项目来说意义重大，当然对于Unity，UE这种游戏研发项目更是如此，因为稍微大点的项目出一次版本可能要10-20分钟，此外还有一些工程特化的功能例如AB构建，Shader变体搜集，各种本地缓存构建，甚至是性能监测报告，GI烘焙，PCG生成，场景切割等重度流程，很难想象这些不放在流水线上让机器自动执行，会浪费大家多少时间 为什么是TeamCity 对比Jenkins和TeamCity的使用感受，TeamCity有几个非常明显的优势 环境搭建简单，不论是Server还是Client 界面友好，美观大方 流水线拓展支持更加丰富的语言类型 环境变量提示友好，更不容易出错 Docker支持完善，方便做云服务器迁移 一些其他的基础设施比Jenkins更加完善（例如自动化单元测试），使用起来更加友好 综上，TeamCity相对于Jenkins是一个更加现代化的方案，所以我们也选择TeamCity作为CI方案 搭建教程 ...