魔术师Dix的博客

Unity 官方除了一个 GPU 粒子特效的解决方案：Visual Effect Graph，即 VEG，能支持百万级粒子特效的播放。在性能要求高的使用场景中，这个解决方案就能完美解决原本 Particle System 性能低下的问题。关于 VEG 的基本使用方法参考官方文档和 GitHub 上的示例工程即可，这里不做介绍。这里主要介绍程序如何通过代码调用实现批量生成粒子特效的实现方法。

在部分游戏中，其寻路不是要求最短路径，而是要求优先走预设的路径。这里需要 NPC 在路径上移动，此路径需要与美术绘制的道路重合，此时并不是按照最短路径移动。这里设计一种基于路径烘培的 SDF 图（SDF 概念参考），并以无环有向图、NavMesh 进行寻路搜索的方案。

SDF ，即有号距离场 Signed Distance Function，简单介绍如下：有号距离场是一种用于表示三维空间中每个点与一个几何形状之间的相对位置关系的函数。对于空间中的任意点，有号距离场返回一个实数，这个实数表示该点与几何形状的相对位置：正数表示点在几何形状的外部，负数表示点在内部，零表示点恰好在几何形状上。有号距离场图则是将这种函数的值以图形的形式表示出来。在图中，每个点的位置表示它对应的有号距离场的值。

很多程序员一谈到做 AI、设计 AI 框架的时候，第一步就想的是要用状态机还是行为树。其实这只是实现方式，而不是 AI 的顶层设计。无论状态机还是行为树，都可以满足绝大部分 AI 的需求，一定程度上没有绝对的优劣之分。而 AI 最为关键的问题，则是更为抽象的顶层设计。

场景生产流程通常会经历前期准备、Layout、Blockout、场景资产制作/编辑/迭代、灯光布置与烘培等阶段。本文重点强调前期准备、Layout 和 Blockout 三个阶段：因为这三个阶段为目前国内项目中常常缺失的部分。至于最后的资产制作、灯光等，根据项目不同，属于锦上添花，丰俭由人了。这篇文章的主要观点摘抄自《游戏造梦师：游戏场景的开发与设计》。

最近读完了这本《游戏人工智能编程 案例精粹》，感觉获益匪浅，在对游戏人工智能的设计上有了更深的感悟。这本书既适合初学者学习，因为次书会从最基础的数学物理公式推导一步一步介绍到完整的人工智能开发；同时也适合进阶程序员，因为其设计思路、解决方案能给人以很大启发。要注意的是：这里讲的人工智能，并非现在大火的强人工智能（AI），而是游戏中的行为体智能控制（例如控制 NPC 行动的状态机）。

最早看到这个概念是在《腾讯游戏开发精粹II》里，看了之后感觉非常实用，于是将其列为开放世界的一个必备组件。其运行逻辑简单总结就是：例如监测到帧率下降时，则进行减少一些特效、音效，对不重要的 AI 降频等操作，使帧率提升。这样使得游戏整体帧率保持平稳，且能最大限度保证玩家的游戏体验。

所谓白模（BlockMesh），就是在关卡设计初期，使用极简模型搭建的示意，用来测试关卡的合理性和可玩性。这不是一个新概念，在众多高质量游戏制作中都是必不可少的流程。这里我推荐一篇顽皮狗关卡策划 David Shaver 关于白模分享（原版PDF下载）五分钟GDC 01:游戏Blockmesh关卡设计技巧——图文版 - 哔哩哔哩Hello 大家好，这里是五 分 钟GDC，今天给大家带来的是游戏关卡设计中Blockmesh 的技巧。首先，让我们先了解一下什么是Blockmesh。

游戏开发流水线，即从构思到成品的一系列过程。相信有的朋友已经迷惑了：哪个项目不是从构思到成品呢？诚然，所有项目都是从构思到产品。但关键在于 “一系列过程”。你经历过的项目，他们的这个过程是相同的吗？有通用的步骤吗？每做完一个项目，能让我下一个项目进行地更快吗？也许，有的项目是先写好策划案，美术和程序再依照制作；有的项目是一边做功能，一边补案子；有的项目做了编辑工具；有的项目有原型流程图……然而，如果不能将游戏的开发步骤形成规范，且既能从项目中抽象出来，也能适配到项目中去；

开放大世界的寻路一直是很困扰我的一个点，地图大、还是动态可变的，所以寻路会有很多要求。根据上面的需求，像 NavMesh、JPS+ 虽然效率高，但是重建代价大；用 A* 重建代价小但是效率也太差了；而 FlowField 又不支持多目标寻路。最后，我根据项目本身的需求，设计了一套适用于航海主题的海洋+岛屿的寻路解决方案。这个方案能够满足项目要求，且只有一个 O(1) 的复杂度，还可以分布寻路，地图的重建开销也很低。当然，这里对岛屿、地图设计做了一些限制，同时是针对航海特化的方案。

客户端（逻辑层）服务器都采用ECS架构（只有ECS能满足设计需求）。总体上还是使用状态同步，各个客户端看到的表现不一致。玩家主要关心周边的单位，而不是全部的AOI块内的单位。同步时，只同步移动（路径）信息，其他信息一概不同步（包括血量）服务器提供一个协议，供客户端直接拉取某个玩家的具体信息（客户端主动请求，避开主服务器的同步，类似于灯塔）。客户端根据相机范围来主动向服务器拉取（只读）。这个请求需要做到能无代价。

对于开放大世界的物理碰撞，根据现有解决方案，需要将带物理的物体控制在 1k 以下，就能很好地在手机上运行并支持玩法。对于特殊的需求（例如翻墙、攀岩）等，通过射线手段进行辅助检测，减少物理碰撞的开销。基于 GpuTerrain 实现的地形，则需要通过生成 SDF 图的方式来辅助碰撞，基本上能满足需求。对于一些对碰撞精度要求较高的需求，也可以通过取巧的方式来实现。（例如，如需要玩家在前进过程中自动绕开一些小型灌木。

经过前面几个章节的介绍，开放世界的数据管理就已经初具雏形了。实际上，开放世界数据最麻烦的，就是各种地图渲染数据。如果地图渲染数据解决了，逻辑数据处理起来也是相对容易的。所以这里讲的，核心也是在地图渲染数据。这个视频是使用这一套技术整出来的Demo，有美术的配合就好看很多了。Island_G效果演示（8月版本）_哔哩哔哩_bilibili岛屿效果演示视频，项目中的Island_G。除了常规的天气、后期等，此版本主要增加了草海效果。这个版本的草海是根据新的草海插件美术手动绘制的，在CPU多线程进行渲染。

草海是开放大世界渲染的必不可少的因素，Unity 原生的 Terrain 草海效率较低，而且无法与 RVT 结合起来，无法在移动端上实现。因此我们自己搓出来一套草海系统，使用 C# 多线程辅助运算，并能支持割草、烧草等进阶玩法。草的位置、密度、类型还需要根据美术和地形的信息进行自适应。最终效果可以看这个演示视频：GpuTerrain+草海_哔哩哔哩_bilibili地形用GpuTerrain渲染；草海是自定义实时生成运算+Gpu渲染。

之前写的两篇开放世界技术栈都是公司其他同事做的，所以很多细节了解不详细。但这次是全程我自己搭建的轮子，可以讲得稍微详细些。之前写的大规模物件渲染的 GPU 版本，虽然渲染量大效率高，但是有个很致命的缺陷：无法与游戏逻辑进行交互。因为主要渲染数据都是放在 GPU 中，为了效率要尽可能减少异步回读，也要尽量减少同步数据量，所以要物体与逻辑交互就基本不可能了。但是使用 Unity 的 Dots 系统再加上 GPU Instance 技术，就可以很好地解决这个问题。

GPU Driven 的静态物件渲染，听起来很高级，其实具体操作很简单，基础就是直接调用 Graphics.DrawMeshInstancedIndirect 这个 Unity 内置接口就可以了。但我们项目对这个流程做了一些优化，使得支持的实体数量有大幅提升。这套系统主要也是公司的 TA 实现的，这里我也只简明扼要地介绍一下原理。

Unity 原生有一个 Tarrain（地形）系统，但可惜并不能直接用于开放世界，当然是因为其效率问题。现在开放世界主流是使用 GpuTerrain + RVT ，也是一个成熟技术了。在项目中实现这个技术的是公司的 TA（我只做了接入），具体不了解，这里也只是大概说明下这个技术。如果对这套技术缺乏了解的，建议直接去看参考文章，而不是本文（因为本文写得非常简略，也不包含实现方案）。如果已经了解了的，这篇文章也可以跳过。

在介绍技术栈之前，需要先了解下项目需求（因为有不少方案都是基于需求而定制的）。我们这个项目是一个海洋主题的项目，整个大世界是由一片大洋和星罗棋布的岛屿组成。最大的岛屿占地 2048*2048 米，最小的岛屿占地 256*256 米，整个世界大大小小岛屿总量约 1万。评估下来，总世界面积超过 4000 平方公里，总陆地面积约 922 平方公里。其中，岛屿有上岛玩法，即玩家可以扮演一个 NPC 登陆游玩，类似 RPG 游戏，可以进行解谜、战斗、探索等。玩家岛屿固定大小，可以在地图上迁移。

一般来讲，如果需要制作位图字体，一般是使用 BMFont 这种第三方工具：然而这个工具对于非程序员来说，操作起来较为繁琐困难。每次美术修改了字体之后，需要重新导出，而且还要在Untiy中做数据转换，最后才能在Untiy中看到字体。这里为了方便工作流，制作了一个一键导出的 Unity 内置位图字体生成工具：蒲公英。摸鱼小分队 / Unity位图生成工具：蒲公英 · GitCodeUnity位图生成工具：蒲公英 直接在Unity中生成位图字体，不需要再使用BMEditor。

Unity 在配置 LodGroup 时，其分级切换的计算方法是按照物体在相机视野中占据的比例计算的。在运行时，如果相机视野范围（Field of View）没有改变，那么这个值可以直接换算成物体距离相机的距离。这里就讨论下如何计算得到这个距离。

在自动化流程中，通常都是从外部命令行启动 Houdini，而不是在软件里进行烘培和输出。完全体是通过类似 Jenkins 等自动化工具来启动 Houdini 自动生成流程。我使用的 Houdini 版本为 19.5.640，对应的 Python 版本为 3.9 。

解决 Unity 打包出现 'NativeArrayUnsafeUtility' does not contain a definition for 'SetAtomicSafetyHandle' 的编译错误。

在 Dots 中创建实体的开销是很低的，但是其性能究竟如何？Unity 提供了单个创建 Entity 和批量创建的API，该如何选择？

前言：之前用的GCloudVoice，一个很坑的SDK。后来用着用着突然发现不能用了，神奇！然后去登录控制台一查，发现腾讯把这个东西的相关网页从腾讯云平台上删除了。现在只能在百度上面搜到他的原始网页，不过这些也不重要了，只要知道现在就用新的语音SDK：GME（游戏多媒体引擎）就好了。OK，在删除了腾讯云语音之后，现在开始重新学习新的SDK。正文：1、新的SDK接入首先从官...

Unity推出的这个 UI ToolKit，据说是要用来替代UGUI。既然这么有野心，那肯定要搞来看一看。这次使用目标就是用这个 UI ToolKit 生成一堆类似HUD的头标，然后看看使用难易程度和性能如何。

在进行Unity游戏开发的时候，一直有一个痛点，那便是相同功能的代码在不同项目之间如何共同使用？苍耳提供了一个解决方案。

之前有做过给Unity打so包的工作，这里记录一下，以备不时之需。因为不是安卓开发，平时不怎么用Android Studio，所以就教程写得详细一些，方便以后照搬。

在SLG等游戏中，相机总是固定为俯视角（上帝视角）。为了更好地管理游戏数据，需要对地图进行分块，只处理视野内的部分。判定某个单位是否在视野内有很多方法了，但是要么不够精确，要么性能不够，要么无法与AOI配合。 一个可行的方案就是将相机在地面上的视野计算出一个AABB 2D 包围盒，然后基于此包围盒来计算 AOI、显隐等。这个方案效率够高，而且对俯视角适配较好。

在自定义 Unity 的Package插件的时候，我们需要编写一个Json文件：package.json 。 其中有个 version 字段，表示其版本，其值是一个字符串。本文旨在简单解释这个version字段的格式和规则。

视锥体剔除是Unity常用的剔除方法，其原理就是通过判定目标包围盒与组成相机视锥体的6个平面进行同侧判定，只要在6个平面之间的包围盒即为可见。本文根据其原理，给出一个视锥体裁剪的剔除算法的实现，并兼容ECS。

在平面上，格子坐标通常是个二维坐标（X，Y），但是二维坐标有很多不方便的地方，且如果作为键值，其取值效率不高。因此大部分情况下，需要将二维坐标转换成ID来使用（且能从ID转换回坐标）。 常用的方式就是X*N+Y，N为一个足够大的数。但是这种方式有问题，其只能支持全正数或者全负数，一旦有正有负，就会坐标转换失败。因此需要一种较为便捷的算法，能将二维坐标映射成ID，且能互相转换。......

​有时我们需要使用Unity的GPU 异步回读的功能，也就是使用如下API：AsyncGPUReadback 。那么这个API是否能无脑使用呢？他的兼容性如何呢？

这里的六边形地图，指SLG游戏中的大世界地图，用六边形的网格进行平铺。例如文明，以及部分SLG手游。这里介绍六边形地图格子的基本概念，以及具体数学实现代码。

伪随机是游戏中常用的功能，但是我看网上的实现都比较复杂，或者不够随机（比如用线性同余法）。所以就自己实现一个算了，用最简单的方式。需求类似于抽卡那种，例如10连抽必中1张（概率10%），然后这1张在这10次里面是随机出现的。如果第一张就抽中了，那后面9张都不会中；同理，如果前9张都每中，则最后一张必中。实现算法基本思路如下：先获取一个概率（P），然后得到当前概率下的...

前言： 设一个1024*1024的地块，需要实时计算有哪些地块在相机范围内。为了提高运行效率，这里用ComputeShader来计算。1、准备工作 先在Unity右键创建一个ComputeShader，然后再创建一个Canvas，放一张RawImage（用于接受调试用的图片）。 然后创建一个控制类，添加以下控制组件：public class ComputeTest : MonoBehaviour{ #region 外部赋值属性...

具体原理我是参考的这篇文章：https://gameinstitute.qq.com/community/detail/116994本地具体实现实现方法（不调用Camera的API）如下：1、获取相机的VP矩阵： 物体顶点坐标转换成屏幕坐标是用MVP矩阵，但是因为我们这边本来就使用的世界坐标进行转换，所以只需要VP矩阵即可。获取VP矩阵的方法如下： private Matrix4x4 Matix_V...

前言：最近项目里有一个需求，要求某个单位（3D）一直显示在所有物体的最上层，哪怕他在其他物体后面。经过一番折腾解决了，这里提供几种思路。这里先起一个Demo，如下图：可以看到，黄色方块是在白色方块后面的。在Game视图中可以看到，黄色方块是被白色方块挡住了一部分。现在我们用一些操作把黄色方块提到最前。一、使用2个相机这种可以说是最简单的了：把主相机复制一份，然后剔除掉黄色方块的层。再在复制出来的相机里设置为Depth Only并且只照黄色方块的层：可以看到这个黄.

把3D坐标映射到UI上，这种操作多用于类似血条、人物名之类的东西。这种其实是可以整个通用的方法来解决的：通过3D坐标直接修改UI控件的位置：

首先：Odin是一个绝对需要用的插件（稳赚不赔）但是Odin Inspector在手机上可能会有些问题……

如何判定一个物体/坐标是否在视野范围内？本文提供三种解决方案。