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

前言 以此文章来记录ProjectS从企划到开发到宣发到上线的全过程，其中涉及玩法构思，资源制作，技术思考，市场分析，上架操作等，几乎包含了从零开始制作独立游戏的全部知识和经验，希望对大家能有所启发，本系列文章将会持续更新 玩法设计 代号ProjectS企划案 技术方案 GamePlay框架 ET7+FariyGUI+huatuo+luban+yooasset接入教程 基于行为树的MOBA技能系统：总目录 ProjectS中的AI转向系统（Context Steering） ProjectS中的体素碰撞和寻路 CI/DI方案 从零开始基于TeamCity搭建项目的CI工作流 剧情架构 PCG框架 ProjectS中的地形系统-Procedural Content Generation（PCG） 渲染框架 ProjectS中的纹素密度规划 ProjectS中的GPU Driven ProjectS中的全局光照系统-Voxel-based Global Illumination（VXGI） ProjectS中的地形系统-Terrian Rendering ...

留个备份，也给大家当个参考 日常 WizTree 目前来讲最好用的硬盘空间占用预览工具，够快，够美观 process-explorer 进程管理器，可以方便查看进程情况，经常用来dump命令行参数 clumsy 弱网测试工具 WPS 基巴来的微软Excel打开的时间都可以给他马上香了 还是看看远方的WPS吧，Words，PPT，PDF，Excel全都有了 processon 画图功能还可以，主要还是可以在线分享，个人已入永久会员，推荐 翻译插件 可以使用免费的谷歌翻译，也可以选择AI的API，嵌入式翻译网页中的外文，非常好用，而且支持PDF，PPT的文档翻译 游戏白嫖 推荐体验后上车哦 BandiZip 最好用的解压缩软件 工作学习 Typora 写文章非常好用，推荐配合 https://github.com/wqaetly/MyTyporaTheme 食用 图片上传到服务器推荐：https://picgo.github.io/PicGo-Doc/zh/guide/ 正则表达式辅助网站 其实现在有了AI之后不是很有必要了 在线汇编 基本上支持所有语言 Js ...

整理总结一波il2cpp攻防的知识点，希望能从插件脚本小子稍微变强一点点 Unity il2cpp由来已久，由于il2cpp本身是开源的，自然也就诞生了很多针对未加密Unity项目的自动化破解工具，Hack工具，比较为人熟知的有： Il2CppInspector，Katy姐的作品，其个人博客：katyscode 中也有il2cpp相关知识和攻防实践 Il2CppDumper，Perfare个人博客：il2cppdumper.com Cpp2IL，更加智能，自动化的IL2CPP的反编译工具 Il2CppInterop，MelonLoader等Hook工具，可以在转储globalmetadata后非常便利的对游戏逻辑进行Hook，从而达到作弊的目的 frida-il2cpp-bridge，运行时转储、跟踪或劫持任何 IL2CPP 应用程序，而无需 global-metadata.dat 文件 对于一些较为基础的概念和说明，网上也有很多文章分享，这里推荐大家去逛逛看雪论坛，贴几篇文章在这： 什么？IL2CPP APP分析这一篇就够啦！ 针对魔改unity引擎的il2cpp dump方 ...

书接上文 从ProjectS复制文档出来，更改时间的时候发现已经是2022年的事情了，这三年来除了核心玩法外几乎没有任何实质性的进展，原因很复杂，但扪心自问，还是定的目标太大，时间太少，便索性搁置了 前两天灵光一闪，想做一个别致的打砖块游戏，既然三消能和战斗结合，那打砖块一样可以 MDA 机制 目前我见过的打砖块游戏都是限定在了玩家控制一根弹性杆子不断击打一个球来消除关卡中的所有砖块从而通关，其中包含了随机奖励（各种增益道具）和风险（减益道具，接不到球=死亡），一些游戏还会加入时间机制，如果规定时间内没有完成关卡会生成一些怪物，增大关卡烈度，冒着风险，获取回报！这就是游戏的本质，可以说一个极简的打砖块玩法模型已经达成了这个目标，但这还不够，我们看看传统打砖块有什么局限性和可以改进的地方，我会从这些角度出发，尝试让打砖块变得更加好玩 交互形式单一 不论增加再多的道具，仍然是把交互形式局限在了接球，发球上，且球发出后，玩家基本上就处于挂机状态，无法再干预战局，像极了一场单局极短的自走棋 单局内的打砖块这么多年以来已经被无数的开发者探索殆尽，他们尝试改变环境边缘，杆子长短，弹球属性 ...

序 相信大家同我一样，过年期间被哪吒疯狂刷屏，并且这势头愈演愈烈截止今天预测都已经百亿票房了，那么本虾头男也是坐了一天牢之后孤身一人去了最近的iMax影院一探究竟了 百亿帝王，名副其实 我写观后感一般都是夸夸，各位看官看个乐呵即可 PBR（基于物理的渲染）为王 既然是动画影评，首当其冲的自然是画面观感了 时至今日，迪斯尼原则的BRDF（Disney Principled BRDF），仍然在3D动画影业占据着主流地位，市场反应也证明了其旺盛的生命力和正确性 至于为什么，我想 截至《绝区零》来聊聊二次元游戏的未来 部分很好说明了，那就是所谓的真实感和共鸣度 经过这些年的不断改良优化，3D动画领域和3D二次元游戏领域中的PBR已经相当成熟和漂亮了 正是因为这股真实感，让我在整个观影过程中都有身临其境的感觉（当然3D的IMAX也功不可没），仿佛敖闰都触手可及（虾头+1） 中国风的配色与画面构成 基础的配色选择和设计这里就不多说了，如果基础规则都没掌握，也不用做电影了 不同于鬼佬们的大力出奇迹的明艳配色，哪吒的配色在大部分镜头都很“润”，整个画面的明度并不高（特效高亮部分除外），很 ...

差不多该动手实现ProjectS中地形的RVT了，所以整理一波学习资料，依旧是以FarCry为主体 注意本文中同样的词汇在不同上下文中有不同的意思，以RVT为例，在Procedural Virtual Textures部分，RVT代表Procedural Virtual Textures，但在Adaptive Virtual Textures部分，RVT则代表Adaptive Virtual Textures，基于历史发展，简单排列下术语 VT：Virtual Texture，包含SVT（Mega-Texture），RVT（Procedural Virtual Textures，经典RVT），AVT（Adaptive Virtual Textures，Far Cry4提出的改良版RVT） Page：VT的其中一部分，其实叫Tile会更加合理一些，可以理解为VT是由一个个Page组成的，也是我们渲染到RT上的最小单位 Indirection Texture：VT和真实RT映射表，也叫Page Table Physical Texture Cache：最终用于渲染的的RenderTex ...

前言 接触图形学中颜色相关的概念许久了，色域，LDR，HDR，ToneMapping，伽马空间，线性空间，sRGB，ACES等名词也都算耳熟能详，但一直以来都是零散细碎的知识点，从来没系统整理过。 个人一直关注UE的发展和官方油管频道，恰巧看到了一个颜色管线的视频，算是事无巨细的详解了上面每一个概念和他们之间的关系，遂有此文，与诸君共赏。 今天我们要讨论发生在引擎和渲染过程中的颜色管线以及特定的颜色转换 线性渲染 我们先想象一个简化版的渲染管线，一个纹理输入，在线性空间下渲染，经过后处理，最后显示在窗口中（或者存储到一个文件中） 我们先从中间看起，即Linear Rendering in RGB，既然是渲染，我们首先应该关注的就是颜色值 颜色值代表光量，可以是范围很大的值，也可以是范围很小的值 并且他们是线性的，这意味着如果我们将颜色值翻倍，我们得到的光量也是翻倍的 他们用于引擎的工作环境和运行时环境的颜色空间中 在更加深入之前，我们先了解一下颜色的基础知识 颜色基础知识 一般我们在谈论颜色空间的时候，同时涵盖了颜色编码和颜色空间这两个概念，我们先来看颜色空间 颜色空间 ...

2024年是我职业生涯以来过的最快的一年，一方面是大部分时间都在加班中度过，另一方面是对游戏行业的烈火般的热情终究是在这一年燃烧殆尽，感觉曾经认定的一切都是没有意义的，便近乎自暴自弃的荒废了大半闲暇时光 为何？ 我自诩脾气虽然不算好，但耐力还算说得过去，饶是如此，一次次被人打断的工作状态，一个个问了一遍又一遍问题，不断积压的压力和怒气，长时间没有获取的满足感。。。，这些种种最终让我如同泄了气的皮球，歇斯底里，状若疯魔，因为我一直以为，游戏行业不该是这样 在那之后，我如同失去了心气神，从锱铢必较，据理力争，变成了得过且过，能跑就行 无数个夜深人静里，我平静的思考，开始回顾自己从写下第一行printf("Hellow World");，第一个游戏Demo，第一个B站技术视频，第一篇技术博客，第一次参加实习，第一次正式工作，到如今这般田地，我到底做错了什么，其他人又错在哪里 都没有错 我为项目尽心尽力，一方面承接除剧情外的各个模块的功能需求，性能优化，一方面应付已经上百人的CG美术团队，泥人尚有三分脾气，我偶尔怒从心中起又有何不可？不如说，我能做到这一步已经是仁至义尽 ...

地形系统思路来自 ProjectS中的GPU Driven 前言 再来回顾下传统地表材质与我们定好的方案之间的对比： 传统Weight Blend方案：通过纹理 + Mask图实现多纹理混合渲染 每多一张纹理贴图，就要多一份遮罩数据。 由于每点的mask总和为1，所以改变一层需要动到其他所有层的数据，耦合度太高，不方面大规模修改迭代。 编辑器在处理edit layer时，由于需要全局的归一化操作，所以会让上层的layer表现非常奇怪。 随着edit layer的增加，内存和操作延时也会是个问题。 渲染时由于每个地块使用的weightmap各不相同，所以加大了合批处理的难度。 Material Id方案：确保每个点只有一种纹理贴图的情况下，通过一张Material Id图控制，最后通过双线性插值混合平滑，这里的材质不是指材质球，而是指一个数据结构，其中包含材质参数，贴图索引以及其他信息 优点是这张MaterialId，它相当于一个间接的索引，每个值表示一张纹理图。8位的单通道materialID图就足以支持超过200种纹理图。它的大小可控，不会随着纹理数量的增加而增加。同时 ...

机缘巧合下，遇到了地形渲染上常见的接缝问题，常见类型有如下几种： 图集+双线性插值导致采样结果错误 Mipmap跳变，导致两个像素采样得到的值跳变 采样器Point模式采样精度不足，导致在纹素临界处跳变 不同LOD Mesh导致的模型接缝 以上几点在 不帅的 地形5种常见接缝的修复方案 中均有解决方案，而ProjectS遇到的问题，严格来说也可以归类于第二点，不过原因却是有些耐人寻味，请看下文 临时写法造成的意外 出于快速验证方案的目的，我直接通过if-else进行纹理采样，逻辑也很简单，根据不同的index采样不同的纹理 1234567891011121314151617float4 SampleTexture2D(int index, float2 uv){ float2 finalUV = TRANSFORM_TEX(uv, _GrassTex); if (index == 0) { return SAMPLE_TEXTURE2D(_GroundTex, sampler_GroundTex, finalUV); & ...