登峰造极者，殊途亦同归。

地形系统思路来自 ProjectS中的GPU Driven 架构 首先明确ProjectS的世界大小，目前暂定整个世界面积为 20.48km * 20.48km ，实际上可以再大很多，但考虑到资源量级以及对于世界内容的填充需要颇费心思，暂定这么大了 既然地形分了LOD，那么纹理自然也要根据LOD进行区分 LOD0的Node对应的纹理信息（高度纹理，Material Id纹理等）分辨率为128*128，覆盖区域为64m*64m即一个纹素对应0.5m，已经很可以了，再高点画质就要比原神好了 LOD1的Node纹理分辨率为128*128，但覆盖区域为128m*128m LOD2的Node纹理分辨率为128*128，覆盖区域为256m*256m LOD3的Node纹理分辨率为128*128，覆盖区域为512m*512m LOD4的Node纹理分辨率为128*128，覆盖区域为1024m*1024m LOD5的Node纹理分辨率为128*128，覆盖区域为2048m*2048m 这也就意味着我们需要对整个世界做六种不同覆盖区域的纹理，可以理解为Mipmap，不同的LOD Node采样不 ...

还是最喜欢这个拜念三归，地狱的压迫感拉满！ 最近玩了暗黑破坏神4，感触颇多 技能Build 技能Build其实没什么好说的，依旧是基础技能+符文系统完善Build，但相较于恐怖黎明的星座，流放之路的技能树+升华，暗黑4的理解成本和玩家友好程度更加出色。它的巅峰系统居然是可以旋转的。。。，这意味着玩家可以不用太过拘泥于设计好的巅峰树，而是能最大限度地按照自己的意愿去体验整个系统 之前在内测时体验过所有角色，感觉到暗黑4是想让玩家尽可能的把手参与到战斗中，而不是进个图，几个buff一加，技能一开，直接跑跑跑完事，虽然说增加了一些上手难度，但确实是能让玩家更用心的去体验战斗的刺激。很合我胃口，毕竟我玩剑圣的，哈哈（顺带吐槽，狗曰的一如既往对平A近战不友好，各种暴毙 玩了这么多暗黑Like作品，技能流派来来回回就那么回事，什么双持+AOE剑圣，大风车，召唤平推流，万剑齐发。。。其实这类游戏发展到这种地步，Build上很难再做出让人眼前一亮的设计了，就像LOL最近新出的英雄，就是基于各种技能元素，缝来缝去，然后得到一个全新风格的英雄，不是说不好，反而是相当健康的一种发展模式，能让玩家在低 ...

本文是对https://www.gdcvault.com/play/1025480/Terrain-Rendering-in-Far-Cry 进行的中文翻译，翻译动机是PPT涵括了ProjectS的GPU Driven系统所有功能模块，需要学习下工业流程 大纲 地形渲染：渲染地形，将部分转移到GPU管线中 基础知识 GPU管线 着色：对上一步渲染的地形进行着色 悬崖着色：针对悬崖做的着色方案和优化 高级地形：将基础地形和其他几何结合 屏幕空间着色：在一个屏幕空间的Pass对地形进行着色 基于地形的特效：使用GPU上的地形数据来增强对其他资产的渲染，如树木、草和岩石 地形渲染 地形渲染基础 流程概述 一个简单且GPU友好的方式来渲染一个小区域的地形步骤如下： 首先渲染一个Mesh，作为地形的最小单位。 在VS中采样高度图，来改变顶点位置 使用一张albedo贴图在PS中进行着色，作为地形基础色 计算光照时再用一张normal贴图 使用四叉树来划分地形区域，整个世界构成item粒度从小到大依次为（LOD0）： Patch（Tile）：单个Grid，原分辨率1 ...

架构 前阵子敲定了ProjectS GI方案的大体架构，但只对着那几个Cube可看不出落地效果，也没法做针对性的优化，所以准备启动地形相关的开发工作 立项之时就考虑到美术成本问题，所以采用程序化生成作为构建ProjectS世界的主要手段，程序化生成意味着大量重复instance和大地形，这时候就得利用GPU Driven来作为整个PCG系统的底层支柱之一了，我们常说的GPU Driven包括以下几个方面 地形渲染 制作 Houdini 生成高度图+Mask VS 直接生成Mesh Houdini生成高度图+Mask方案对于Houdini来说更加轻量，不需要处理地形Mesh 直接生成最终Mesh可以离线对Mesh做处理，包括岩壁重展UV，LOD计算等 但对于ProjectS来说，没有太特殊的需求对Mesh做处理，一些岩壁拉伸问题也可以通过处理贴图渲染进行解决，最终选用高度图方案 渲染 DrawInstanceIndirectly通用Quad Mesh + LOD + 高度图采样 实现地形渲染 VS Mesh Cluster Rendering + LOD 实现地形渲 ...

我做了一个梦 我是一位书生 梦里似有一壶酒，不见其形，却感受得到它的悠然与清香 听人说，这酒产自故乡，但如今远在异乡 这股清香，一直陪伴着我，在疲惫不堪的时候，我把它当成一种抚慰 后来，我对它愈加喜欢了，我付出的越来越多，用尽全力去了解它，只想永远拥有它 但，酒这事物，越沉醉，越伤身 它总是懒得回应我，无论我再怎么苦苦哀求，它只愿意给我它的清香 哪怕一滴一毫的壶中酒都不愿予我 但，我对它依赖的太深了，我想要更多 它说，让我看看你的模样 我便决定踏遍天涯去找寻它的踪迹 找寻它的路上，太阳是暖的，风是甜的，就连凌晨的星空也是美的 见到它的那刻，我顿住了，它是凛冽的，热辣的，但也有那熟悉的清香 这样的它，让我沉醉 我陪它走了很久很久，我们都很开心，像是久别重逢的新人 它就在我身边，这让我感到从未有过的安心 趁着满天星辰，我问它，能否给我更多 恍惚间，我看它稳了稳身形，酒盖似也紧了些，我心中悲然，这应是它的回答 翌日，我早早来到约定的地点 这里有春天的微风，慵懒的暖阳，翠绿的湖水，簌簌作响的树叶 我们依旧走在路上，但除了熟悉的清香，那疏离的感觉，把我一步步的推往绝望 我陪它走了很久很久，走 ...

前言 前阵子在处理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点前就要到达机场 一路上倒也平稳，不知不觉就睡着了，忽然感受到一丝冷意，睁开充满困意的眼睛，发现车窗外已经飘起了小雪，觉得有些生气，毕竟在家这么多天连个雪影子都没看到，今天要走了，才开始下雪，都没办法好 ...

文章已于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上 ...