1. 项目概述战争迷雾系统在游戏中的核心价值在策略游戏、MOBA或者RPG项目中你有没有遇到过这样的需求玩家控制的单位视野有限地图的大部分区域被黑暗或迷雾笼罩只有当单位移动过去或者通过技能、建筑“点亮”区域时地图才会被逐渐揭示这个机制就是经典的“战争迷雾”Fog of War。它不仅仅是隐藏地图信息那么简单更是塑造游戏策略深度、营造紧张氛围和引导玩家探索的核心工具。想象一下在《星际争霸》里你不清楚对手在阴影处集结了多少兵力在《英雄联盟》中你需要插眼来获取河道和野区的视野——这种对未知的博弈正是战争迷雾带来的核心乐趣。然而在Unity里从零实现一套高效、稳定且视觉效果出色的战争迷雾系统对很多开发者尤其是独立开发者或项目初期的团队来说是一个不小的挑战。它涉及到实时视野计算、大规模网格或纹理的动态更新、高效的渲染技术以及如何与你的游戏逻辑如单位、技能、视野提供者无缝集成。自己写可能会在性能瓶颈、边缘情况处理如视野穿透墙壁、平滑的迷雾边缘上耗费大量时间。这也是为什么一个成熟的、经过优化的“Fog of War”资产包能成为项目开发中的加速器。最近在研究和整合几个Unity项目时我深度使用并剖析了一款市面上评价不错的Fog of War资产。这篇文章我就以一个实际使用者的角度来彻底拆解这类资产的核心实现原理、如何高效集成到你的项目中以及那些官方文档可能不会明说但在实际开发中能让你少走弯路的“坑”和技巧。无论你是正在选型还是已经入手但用起来不太顺手相信这些从一线实战中总结的经验都能给你带来直接的帮助。2. 战争迷雾系统的核心设计思路与方案选型在动手集成或者自己造轮子之前我们必须先想清楚战争迷雾系统到底要解决哪些问题以及不同的解决方案各自的优劣。这决定了你后续所有工作的方向和可能遇到的瓶颈。2.1 战争迷雾的三大核心需求首先一个合格的战争迷雾系统需要满足三个基本需求视野的实时计算与更新系统需要能根据场景中每个“视野提供者”如英雄、小兵、侦察守卫的位置、视野范围实时计算出地图上哪些区域是“已探索”永远可见、哪些是“当前可见”在视野内、哪些是“未探索/不可见”被迷雾覆盖。这个计算必须高效因为每帧都可能有很多单位在移动。视觉效果的渲染计算出的“可见性”信息需要转化为屏幕上的视觉效果。通常“不可见”区域用黑色或半透明的迷雾覆盖“已探索但当前不可见”区域可能会用灰色或半透明显示地形轮廓。渲染需要平滑、美观且不能有明显的性能开销。与游戏逻辑的交互游戏中的其他系统如AI寻路、技能释放判定、小地图显示都需要查询某个位置是否在视野内。例如AI敌人只会在进入玩家视野后才开始攻击技能无法对迷雾中的目标施放。2.2 主流技术方案对比基于纹理 vs. 基于网格市面上常见的Unity战争迷雾实现主要分为两大技术流派它们各有适用场景。方案一基于渲染纹理Render Texture的后处理方案这是目前许多高质量资产包包括我使用的这个首选的方法。其核心思路是原理在场景上空平行于地面放置一个不可见的“迷雾平面”。系统为这个平面准备一张渲染纹理一张“画布”纹理上的每个像素texel对应游戏世界中的一个水平位置。然后为每个视野提供者如一个圆形视野在这张纹理上“画”出一个白色的圆形代表可见区域。所有视野提供者绘制完成后这张纹理就变成了一张“可见性遮罩”白色可见黑色不可见。最后通过一个全屏后处理Post-processingShader采样这张遮罩纹理来决定最终屏幕像素的显示是正常显示还是用迷雾颜色覆盖。优点视觉效果极佳可以轻松实现平滑的、带有羽化边缘的迷雾效果甚至可以做动态的迷雾流动、噪声扰动等高级特效。性能相对可控视野计算在CPU端完成向纹理绘制图形渲染开销集中在后处理。只要纹理分辨率设置合理如1024x1024对现代GPU压力不大。与渲染管线兼容性好无论是内置管线、URP还是HDRP都可以通过自定义后处理或Renderer Feature实现。缺点内存占用需要至少一张渲染纹理。精度依赖纹理分辨率低分辨率下视野边缘可能会有像素感或锯齿。高分辨率则会增加填充开销。“高度”处理稍复杂对于有高度差的地图如山地单纯的平面纹理可能无法正确处理“站在高处看低处”的视野遮挡需要额外处理如高度图。方案二基于网格Mesh或计算着色器的方案这种方案更“原始”一些常见于一些追求极致性能或特定效果的实现。原理将游戏世界的地面划分为一个精细的网格Grid每个网格顶点或单元格存储一个“可见性”状态如0不可见1已探索2当前可见。每帧通过CPU或GPU使用Compute Shader计算每个视野提供者对网格的影响更新这些状态。在渲染时通过一个Shader读取每个片元像素对应的网格可见性数据来决定是否显示迷雾。优点逻辑查询极快判断一个点是否可见直接查询网格数据即可是O(1)操作非常适合需要频繁进行视野判定的游戏逻辑。可精确处理3D遮挡结合射线检测可以相对准确地处理地形高低差、墙壁遮挡等真正的“视线”问题。缺点视觉效果实现复杂要实现平滑的迷雾边缘需要在Shader里做复杂的插值或采样模糊效果不易控制。CPU/GPU计算压力可能大如果网格非常精细如1000x1000每帧更新所有受影响的单元格计算量不小。使用Compute Shader虽能加速但增加了技术复杂度。内存占用可能高精细的网格意味着大量的数据。选型心得对于大多数追求画面表现和开发效率的RTS、MOBA、RPG项目基于渲染纹理的后处理方案是更稳妥和主流的选择。它平衡了效果、性能和实现复杂度。本文后续详解的资产也正是基于这一方案。而基于网格的方案更适合那些对实时逻辑查询性能要求极端高且对迷雾视觉效果要求不那么花哨的战术模拟或策略游戏。2.3 资产包的核心组件架构解析一个设计良好的Fog of War资产包通常会提供以下几个核心组件它们共同协作完成整个系统FogOfWarManager (单例管理器)这是系统的大脑。负责初始化渲染纹理、管理所有视野提供者FogRevealer的列表、每帧驱动可见性纹理的更新、以及提供公共API供其他游戏逻辑调用如IsVisible(Vector3 position)。FogRevealer (视野揭示器组件)这是一个需要挂载到任何需要提供视野的游戏对象如玩家单位、建筑、眼位上的组件。它定义了该对象的视野参数视野半径、视野角度用于扇形视野、揭示类型是永久揭示“已探索”还是仅当前可见等。管理器每帧会收集所有Revealer的信息并用于更新遮罩纹理。FogOfWarRenderer (渲染组件)负责将管理器计算出的可见性遮罩纹理通过后处理的方式应用到最终画面上。它可能会挂载在相机上或者通过URP的Renderer Feature集成。FogOfWarShader (着色器)这是视觉效果的核心。一个自定义的Shader接收可见性遮罩纹理作为输入并结合迷雾颜色、边缘平滑度等参数对屏幕图像进行混合处理。理解了这套架构我们在集成和使用时就能有的放矢知道该配置哪里出了问题该检查哪个环节。3. 核心细节解析与高效集成实操要点拿到一个Fog of War资产包直接拖进场景往往不能完美工作。你需要根据自己项目的具体情况进行一系列配置和微调。下面我结合实战拆解几个最关键的细节和操作要点。3.1 渲染纹理分辨率与“世界-纹理”映射关系这是影响视觉效果和性能的第一个关键参数。在FogOfWarManager中你会找到一个类似Texture Size或Resolution的设置通常是256, 512, 1024, 2048这样的2的幂次方。如何选择分辨率低分辨率 (如256/512)性能最好但迷雾边缘锯齿严重视野圆形可能呈现明显的“方块感”。只适合用于快速原型、极简风格游戏或移动端低端设备。中分辨率 (如1024)这是绝大多数桌面和手机游戏的甜点选择。在1080p屏幕上能提供足够平滑的边缘性能开销可接受。也是我项目中使用的设置。高分辨率 (如2048)视觉效果最细腻几乎看不到像素边缘。但代价是渲染纹理的内存占用和每帧的填充率Fill Rate开销翻倍增长。除非你的游戏地图巨大且视角拉得很近否则收益不大。“世界-纹理”映射与“模糊”参数 管理器还需要知道渲染纹理覆盖的游戏世界范围World Size。例如你的游戏地图是200x200单位那么World Size就设为(200, 200)。系统会建立这个世界范围到纹理UV的映射。 即使设置了1024的分辨率直接采样也可能有硬边。因此资产包通常会提供一个Blur或Softness参数。它的原理是在Shader中对遮罩纹理进行多次采样和模糊如高斯模糊从而让可见与不可见的过渡区域变得平滑。适当增加模糊迭代次数或强度可以在不显著提高纹理分辨率的情况下极大改善边缘视觉质量是性价比很高的调整。实操技巧不要盲目追求高分辨率。建议从1024开始如果发现边缘有锯齿优先尝试增大Blur参数。在游戏运行时可以尝试动态修改这两个参数在Scene视图里直观对比效果和帧率变化找到最适合你项目的平衡点。3.2 视野揭示器FogRevealer的参数精讲FogRevealer组件是连接你游戏单位和迷雾系统的桥梁它的参数设置直接决定了每个单位的“视力”。基础参数Radius半径最直观的参数单位是游戏世界单位米。决定了该揭示器能“照亮”多大范围的圆形区域。Line of Sight视线/是否检测遮挡这是最容易出问题也最重要的参数之一。如果启用系统在计算该单位的视野时会从单位位置向视野边缘发射射线Raycast如果射线被设置了特定层如“Wall”的物体阻挡则被阻挡的部分不会被揭示。这用于实现“隔墙看不见”的真实视野。你需要确保你的墙壁、障碍物碰撞体所在的图层在管理器的Blocking Layer Mask中已被正确设置。FOV Angle视野角度如果你需要扇形视野比如一个探照灯或拥有正面视野的士兵可以设置这个角度如90度。结合Rotation参数可以控制扇形方向。揭示类型Vision Type通常有两种。Current当前视野单位所在时区域可见单位离开区域重新被迷雾覆盖但可能变为“已探索”状态。用于移动单位。Permanent永久揭示一旦被揭示该区域永远保持“已探索”状态即使所有单位离开也不会再被黑色迷雾覆盖而是以“已探索”状态如半透明灰色显示地形。常用于占领的建筑、关键目标点。性能相关参数Update Interval更新间隔不是每帧都必须更新视野。对于移动缓慢或静止的单位如防御塔可以设置一个更新间隔如0.2秒以减少每帧的计算量。对于高速移动的玩家英雄则可能需要每帧更新间隔为0。3.3 与URP/HDRP的集成与后处理配置现代Unity项目越来越多地使用URP通用渲染管线或HDRP高清渲染管线。许多老牌的Fog of War资产最初是为内置管线设计的在URP中集成可能需要额外步骤。URP集成高质量的资产包通常会提供URP版本的支持。核心变化在于渲染部分不再是简单的相机后处理脚本而是一个Renderer Feature。你需要在URP Asset的Renderer列表中找到你使用的Renderer。在其Renderer Features列表中添加资产提供的FogOfWarRenderFeature。在该Feature的配置中关联你的FogOfWarManager实例和所需的材质球通常资产已提供。常见坑点如果添加后迷雾效果不显示首先检查Renderer Feature的执行顺序Injection Point。它通常需要在AfterRenderingOpaques之后但在天空盒等透明物体之前。可以尝试调整顺序。Shader与材质配置迷雾的视觉效果最终由Shader和材质球控制。材质球上通常有这些关键参数Fog Color不可见区域的颜色通常是黑色或深蓝色。Explored Fog Color已探索但当前不可见区域的颜色通常是半透明的灰色或褐色让你能看到地形轮廓但看不清动态单位。Blend Factor迷雾颜色与场景颜色的混合强度。Noise TextureNoise Speed可以添加一张噪声图并让其缓慢移动模拟迷雾的动态流动效果极大增强氛围感。避坑指南在URP中如果同时使用了其他后处理效果如Color Grading, Bloom需要注意渲染顺序。战争迷雾作为一个“覆盖”效果理论上应该在其他颜色调整效果之后应用以确保迷雾颜色正确。如果发现开启Bloom后迷雾区域也在发光就需要调整Renderer Feature的顺序或者修改Shader使其不影响后续的Bloom采样。4. 实战集成流程与核心功能实现理论讲得再多不如动手做一遍。下面我以一个典型的第三人称RTS/角色探索项目为例展示如何从零开始将Fog of War系统集成到项目中并实现几个核心游戏功能。4.1 步骤一基础环境搭建与资产导入创建新项目或打开现有项目确保你的项目渲染管线明确这里以URP为例。导入Fog of War资产包通过Unity Asset Store或Package Manager导入。导入后检查文件夹结构通常会有Prefabs,Scripts,Shaders,Textures等目录。配置URP渲染管线如适用如果你的项目还没创建URP Asset通过Create Rendering URP (with Universal Renderer)创建。找到资产包中用于URP的Renderer Feature脚本可能是一个.cs文件和一个.shadergraph文件。将其复制到项目目录。打开你的URP Asset在Renderer List中选中默认的Renderer在Renderer Features列表点击加号添加FogOfWarRendererFeature。创建并配置FogOfWarManager在场景中创建一个空物体命名为“FogOfWarSystem”。将FogOfWarManager脚本挂载上去。或者直接从资产包的Prefabs文件夹中将提供的管理器预制体拖入场景。关键配置Texture Size: 设为1024。World Size: 根据你的游戏地图大小设置。例如如果你的地图平面是从(-100, -100)到(100, 100)那么World Size就设为(200, 200)。这里一定要设置准确否则视野映射会错乱。Blur Iterations: 设为2或3根据视觉效果微调。Blocking Layer Mask: 设置为你的障碍物所在的层例如“Wall”、“Obstacle”。将配置好的管理器预制体保存下来方便后续场景使用。4.2 步骤二为游戏单位添加视野为玩家角色添加FogRevealer选中你的玩家角色预制体或场景中的实例。添加组件搜索并添加FogRevealer。参数配置Radius: 设为15根据你的游戏尺度调整代表可视距离。Line of Sight:勾选以实现真实的视线遮挡。Vision Type: 选择Current。Update Interval: 设为0玩家角色需要每帧更新视野。为NPC或建筑添加视野为敌方单位或中立建筑同样添加FogRevealer。对于敌方巡逻兵参数类似玩家Vision Type为Current。对于己方或中立建筑如灯塔、瞭望塔可以设置更大的Radius如30并将Vision Type设为Permanent表示一旦建成永久揭示一片区域。运行测试运行游戏控制角色移动。你应该能看到角色周围一个圆形的区域被点亮角色移动后身后的区域会逐渐被“已探索”迷雾覆盖而前方的黑暗区域被不断揭示。尝试走到墙后面观察视野是否被正确阻挡。4.3 步骤三实现游戏逻辑交互——技能与AI战争迷雾系统不能只是一个视觉效果它必须与游戏逻辑联动。技能释放判定假设你有一个指向性技能只能对“可见”的敌人释放。在技能的释放判定代码中在检查目标距离、是否友军之前先加入视野检查。// 假设有一个 SkillTargeting 脚本 public class SkillTargeting : MonoBehaviour { public GameObject target; public bool CanCastSkill() { if (target null) return false; // 关键通过 FogOfWarManager 单例检查目标位置是否可见 // 假设管理器提供了静态方法 IsVisible if (!FogOfWarManager.Instance.IsVisible(target.transform.position)) { Debug.Log(目标在战争迷雾中无法释放技能); return false; } // ... 其他判定条件距离、魔法值等 return true; } }这样当玩家试图点击一个隐藏在迷雾中的敌人时技能会释放失败并给出提示。敌人AI行为控制一个经典的AI需求是敌人在迷雾中时处于“闲置”或“巡逻”状态一旦玩家进入其视野则转为“追击”或“攻击”状态。在敌人的AI状态机脚本中每帧或定时检查。public class EnemyAI : MonoBehaviour { public Transform player; private FogRevealer playerRevealer; // 假设获取到玩家的Revealer public float sightRadius 10f; private bool isPlayerInSight false; void Update() { if (player null) return; float distanceToPlayer Vector3.Distance(transform.position, player.position); // 条件1距离足够近 if (distanceToPlayer sightRadius) { // 条件2视线无遮挡可选如果需要真实的视线 // 这里可以用Physics.Raycast检查 if (!Physics.Linecast(transform.position, player.position, LayerMask.GetMask(Wall))) { // 条件3最关键玩家是否在战争迷雾的“可见”区域内 // 我们需要检查玩家位置是否对我方敌人可见。这需要反过来思考 // 实际上战争迷雾是全局状态。更简单的逻辑是如果玩家不在任何友方单位的“当前视野”内则AI不主动攻击。 // 但为了简化我们可以假设敌人自己有一个“视野范围”只要玩家进入这个物理范围且无遮挡AI就行动。 // 更真实的做法是敌人也有自己的FogRevealer但只用于AI逻辑判断不参与渲染玩家的迷雾。 // 这里演示一个简化版直接使用距离和射线判断。 isPlayerInSight true; // 切换到攻击状态... } else { isPlayerInSight false; } } else { isPlayerInSight false; } // 根据 isPlayerInSight 切换状态 if (isPlayerInSight) { ChaseOrAttackPlayer(); } else { PatrolOrIdle(); } } }更高级的实现可以让敌人的FogRevealer组件只用于逻辑计算设置一个特定的层不被主迷雾渲染器处理然后AI直接查询FogOfWarManager.Instance.IsVisible(player.position, enemyTeamId)来判断玩家是否在其团队的视野内。4.4 步骤四小地图与战争迷雾的结合小地图通常需要显示已探索的区域和当前视野。我们可以复用主迷雾系统的数据。创建小地图相机创建一个正交投影Orthographic的相机从顶部俯视场景将其Culling Mask设置为只渲染地形、静态物体等小地图元素不渲染角色、特效等。创建小地图渲染纹理在Assets中创建一张Render Texture将其拖拽给小地图相机的Target Texture。在小地图上应用迷雾创建一个RawImage UI元素来显示小地图。将小地图相机输出的Render Texture赋值给RawImage的Texture。关键步骤混合迷雾信息我们需要编写一个自定义的Shader用于在小地图的RawImage上绘制。这个Shader需要接收两个输入一个是小地图渲染纹理另一个是FogOfWarManager生成的“可见性遮罩纹理”。在Shader中对于小地图的每个像素采样遮罩纹理对应的点。如果值为1当前可见则正常显示小地图颜色。如果值为0.5已探索但不可见则将小地图颜色与灰色混合降低饱和度。如果值为0未探索则直接显示为黑色或深色。这样小地图就能动态反映战争迷雾的状态了。性能优化小地图的更新频率可以低于主画面。可以设置FogOfWarManager每0.5秒或1秒才将最新的可见性纹理传递给小地图Shader而不是每帧。5. 常见问题、性能优化与排查技巧实录即使按照步骤操作在实际开发中你还是会遇到各种各样的问题。下面是我在多个项目中踩过坑后总结出的常见问题清单和解决方案。5.1 视觉效果类问题问题1迷雾边缘有严重的锯齿或像素块。排查首先检查FogOfWarManager中的Texture Size是否设置过低如256。然后检查Blur模糊参数是否过小或为0。解决将Texture Size提升至1024。逐步增加Blur Iterations如从1加到3。注意模糊迭代次数每增加1性能开销几乎翻倍需在效果和性能间权衡。检查资产包的Shader中是否使用了Point采样模式。尝试在Shader中将遮罩纹理的采样模式改为Linear双线性过滤可以让边缘更平滑。这可能需要你修改资产提供的Shader代码。问题2迷雾看起来“浮”在空中或者与地面贴合不好。排查这通常是因为迷雾渲染的“高度”或“深度”测试问题。在基于后处理的方案中迷雾是作为一个全屏效果应用的它默认不知道场景中物体的深度。解决确保你的FogOfWarRenderer或后处理材质正确接收并处理了相机的深度纹理Depth Texture。在URP中需要在URP Asset设置中启用Depth Texture。检查Shader代码。一个正确的迷雾Shader应该采样深度纹理计算当前像素的世界位置然后只对地面Y坐标在一定范围内或深度值在特定范围内的像素应用迷雾。如果Shader没有深度判断迷雾就会平等地覆盖所有物体包括天空盒和UI造成“漂浮感”。你可能需要联系资产作者或寻找一个支持深度测试的版本。问题3移动平台Android/iOS上帧率下降明显。排查移动平台GPU性能有限对渲染纹理和全屏后处理更敏感。解决降低分辨率将Texture Size从1024降至512。减少模糊将Blur Iterations降至1或0。降低更新频率为非关键的FogRevealer如环境生物、远处的建筑设置Update Interval如0.3秒。分帧更新修改FogOfWarManager的更新逻辑不要在同一帧内更新所有Revealer。可以将Revealer列表分组每帧只更新其中一组分摊计算压力。考虑简化版在移动端的低质量设置中可以完全关闭战争迷雾或者使用一个极简的、基于距离渐变的雾效来代替。5.2 功能逻辑类问题问题4单位明明没有墙但视野就是被莫名其妙地阻挡了一块。排查这是Line of Sight射线检测的典型问题。解决检查Layer Mask确认FogOfWarManager的Blocking Layer Mask设置正确只包含了真正阻挡视线的层如Wall, Obstacle。确保你的地面Ground、触发器Trigger等层没有被错误地包含进去。检查碰撞体检查那个位置的障碍物是否有碰撞体Collider并且碰撞体形状是否与模型匹配。有时一个过大的Box Collider会阻挡不必要的视线。调试射线在代码中临时开启调试绘制将FogRevealer发射的每条射线都画出来Debug.DrawRay在Scene视图里运行游戏直观地看哪条射线被什么物体挡住了。射线数量和精度资产包在计算圆形视野的遮挡时通常是从中心向圆周发射多条射线。如果射线数量太少Ray Count参数可能会导致遮挡检测不准确。适当增加这个数量但要注意性能。问题5如何让不同阵营拥有独立的战争迷雾需求在RTS游戏中玩家只能看到自己阵营的视野电脑对手也有自己的视野且互不可见。实现思路这是高级功能并非所有基础资产包都支持。核心思路是使用多张渲染纹理。在FogOfWarManager中为每个阵营Team维护一张独立的可见性遮罩纹理。FogRevealer组件需要增加一个Team ID字段。每帧更新时根据Revealer的Team ID将其视野绘制到对应阵营的纹理上。在渲染时对于玩家控制的阵营使用玩家阵营的纹理来决定迷雾。对于敌方单位可以完全不渲染或者用另一种方式处理例如始终渲染但用红色轮廓提示这属于游戏设计范畴。这个实现相对复杂需要对资产包的绘制和渲染逻辑有较深的修改能力。一些高级的资产包可能直接提供了多玩家/多阵营支持。5.3 性能优化速查表优化方向具体措施预期效果风险/代价降低CPU计算1. 为静止/低速单位设置Update Interval。2. 减少Line of Sight的射线数量(Ray Count)。3. 使用对象池管理大量Revealer的启用/禁用。减少每帧的GetComponent、位置计算和射线检测开销。视野更新延迟可能导致视野边缘“卡顿”感。降低GPU填充率1. 降低Texture Size(如1024-512)。2. 减少后处理Blur Iterations(如3-1)。3. 在低端设备关闭迷雾特效。减少渲染纹理的像素填充和Shader计算量提升帧率。视觉效果下降边缘锯齿更明显。减少Draw Calls确保迷雾后处理材质是唯一的且不会被动态批处理破坏。在URP中合理配置Renderer Feature顺序避免多余Pass。保持渲染管线简洁。通常无风险属于良好实践。内存优化1. 使用RenderTextureFormat.R8等低精度格式存储遮罩如果支持。2. 及时释放不用的Render Texture。减少GPU内存占用。可能需要修改Shader以适应不同的纹理格式。最后分享一个我个人的调试习惯在开发阶段我会在FogOfWarManager中留一个调试开关可以一键将迷雾可视化模式切换到“显示遮罩纹理”。这样屏幕上会直接显示那张黑白的可见性纹理哪里白可见、哪里黑不可见一目了然。这对于快速定位视野计算错误、遮挡问题有奇效。实现起来也简单就是准备两个后处理材质一个正常渲染迷雾一个只显示原始纹理通过一个按键来切换。这个技巧能帮你节省大量猜测和打Log的时间。
