一款SLG产品的地图表现往往在玩家打开游戏的前十五秒内就决定了第一印象。但真正做过SLG的都知道漂亮只是最不重要的一环——《三国志·战略版》和《万国觉醒》这类产品的地图动辄几百乘几百格如果客户端在地表渲染和数据组织上没想清楚别说十五秒三五秒就能让中低端手机烫成暖手宝。我这几年经手的SLG项目从早期原型到上线版本地表渲染方案前前后后推翻过三轮。最初图省事用一张大图直接铺后来发现业务逻辑根本绕不开地格数据于是换成Tilemap再后来地格数据翻倍增长才发现真正的问题不是怎么画而是数据怎么流动。这篇文章把从Tilemap到Shader的完整改造链路记录下来重点围绕地表渲染、迷雾效果和数据分层架构三块给同样在SLG赛道上踩坑的团队一个参考。1. SLG地图在客户端卡在哪儿三个纠缠不清的问题先说一个很多团队都会遇到的场景策划拿着地图编辑器画好了一张满是城池、森林、山脉、河流的大地图美术资源也导出来了服务端地图数据结构设计好了结果一接客户端帧率掉到十几帧。排查半天发现瓶颈根本不在GPU而在CPU——因为客户端用了几万个GameObject拼地图每生成一个格子都要实例化一个带SpriteRenderer的节点。这类问题之所以普遍是因为SLG地图系统天然同时踩中三个坑一是数据量。以一张600×600的标准SLG地图为例逻辑格的规模是36万个。任何一个需要遍历全图的逻辑比如寻路、视野计算、势力范围扫描复杂度稍高一点就会吃掉大量CPU时间片。而客户端如果用物体堆砌的方式渲染36万个格子就对应36万个Transform和36万个DrawCall离上线标准差着两个数量级。二是数据与表现耦合。很多项目的早期版本一个地格就是一个类类里既存地形类型、资源点归属又存地块是否被探索过、是否有部队驻扎。看似方便实际上每来一个需求比如某城池着火时周围草地要烧焦就得往这个类里塞新的字段然后找到渲染处加上表现逻辑。改到后期一个格子的类可能有二十多个属性序列化、同步、回放、测试全被拖垮。三是表现力不足。纯代码生成的格子如果只是用Sprite摆上去地块之间边界生硬探索过的区域和未探索区域没有过渡行军路线经过的地方缺少痕迹反馈。玩家不看玩法光看画面就觉得这是一款页游古早味产品。要在性能可控的前提下做出活的大地图必须借助Shader在GPU侧做文章。这三个问题其实是互相纠缠的数据量大了得靠分层和合批压性能数据分层没做好Shader想表现也无从下手因为一个地块的邻居信息、状态信息拿不到表现力不足光有性能也留不住玩家。我在新项目里设计的思路很简单用Tilemap解决怎么画的问题用数据分层解决数据从哪来的问题用Shader解决画得好看且不贵的问题。下面按这条主线拆开讲。2. Tilemap的改造实践从编辑器到运行时再到Chunk化加载2.1 为什么最终选Tilemap而不是自研网格合并第一版方案做自研网格合并思路是把所有地形块按图集拼成一张大Mesh然后逐帧渲染。优点是DrawCall极低缺点也明显编辑器能力缺失——策划要在地图上添加装饰物、调整地形边界没法可视化操作动态修改地形时要让美术重新编辑再导出流水线太长。换到Unity的Tilemap之后最直接的收益是编辑器生态策划可以用Tile Palette在Scene视图里像画画一样涂地形涂完还能保存为Prefab运行时可以用Tilemap.SetTile按坐标更新地块适合处理建筑拆除、地形破坏这类动态玩法。而且TilemapRenderer在运行时会自动把相邻且同图集的Tile合批一个几百格可见区域的ChunkDrawCall常常个位数。大地图项目里我强烈建议把Tilemap当作地块渲染容器而不是整张地图渲染器。也就是说不要建一个巨大的Tilemap把整个地图铺满而是切成若干个Chunk级别的Tilemap每个Chunk覆盖固定范围的逻辑格。2.2 Chunk化加载的实现细节Chunk划分的原则是以屏幕可见范围加载缓冲为单块规模。我的项目里逻辑格是64像素一格Chunk大小取32×32个逻辑格也就是每个Chunk覆盖2048×2048像素的贴图空间。32这个数字不是拍脑袋定的它同时满足2的幂次和Tilemap的刷新粒度——Tilemap在SetTile时会做脏区域标记Chunk越小改动一个Tile触发的刷新范围越小但这会让Chunk数量变多加载调度压力变大。代码如下核心是一个按坐标管理Chunk并触发加载/卸载的组件public class ChunkLoader : MonoBehaviour { public int chunkSize 32; // 每个Chunk覆盖的逻辑格数 public int viewRadius 2; // 预加载半径按Chunk数量计算 private DictionaryVector2Int, TilemapChunk chunks new DictionaryVector2Int, TilemapChunk(); public void Update() { Vector2Int currentChunk WorldToChunk(Camera.main.transform.position); ListVector2Int needShow GetChunksInCircle(currentChunk, viewRadius); ListVector2Int needHide new ListVector2Int(chunks.Keys); foreach (var c in needShow) { needHide.Remove(c); // 仍在可见范围内的Chunk不移除 if (!chunks.ContainsKey(c)) { LoadChunk(c); } } foreach (var c in needHide) { UnloadChunk(c); } } private Vector2Int WorldToChunk(Vector3 worldPos) { int gx Mathf.FloorToInt(worldPos.x / tileSize); int gy Mathf.FloorToInt(worldPos.y / tileSize); return new Vector2Int(gx / chunkSize, gy / chunkSize); } }这里有个细节值得注意卸载Chunk时不要直接Destroy整个Tilemap对象而是把Tilemap的Tile数据清掉然后把GameObject放进对象池。玩家在大地图上平移时Chunk的创建和销毁非常频繁直接Instantiate/Destroy会产生显式GC峰值中低端手机上表现为周期性掉帧。复用对象池之后这个GC峰值就消失了。2.3 多层Tilemap拆分与排序规则地表的视觉结构不能只有一个Tilemap。我的一个中型SLG项目里Tilemap是竖着叠了四层层级内容Sorting Order说明GroundLayer草地、沙地、水域、山地底块0最基底地形决定地块可通行属性DecorationLayer树木、岩石、灌木1装饰物不阻挡行军但影响视线BuildLayer城池、要塞、资源点建筑2玩家可见建筑状态变化频繁OverlayLayer迷雾、行军路径、选区高亮3半透明覆盖层Shader负责透明度四层拆开之后最大的便利是建筑变化时不需要重绘地形块。比如玩家在某个空地建了一座城只需要在BuildLayer的对应坐标SetTileGroundLayer完全不动如果是拆除建筑也只需要把BuildLayer那个格子的Tile置空。另一个好处是迷雾层独立于地形层迷雾用单独的Shader处理不用和地形Tile的渲染逻辑混在一起。排序规则上有一个容易踩的坑TilemapRenderer的Sorting Order是层内排序它和SpriteRenderer的排序属于同一个SortingLayer体系。如果你把兵单位用一个单独的SortingLayer放在地表层和建筑层之间就会出现兵被建筑遮挡但露出地基的问题。我的做法是让兵单位挂在单位SortingLayer排序位置比建筑高再用高度偏移让单位在视觉上走进建筑背后时通过Y轴小于建筑锚点的方式形成遮挡。这个细节和Tilemap本身无关但单位与地表的融合感对SLG沉浸感影响很大。2.4 Tilemap在运行时动态修改的坑SLG里地表不是静态的。最常见的是拓地玩法——玩家占领某个地块后地格颜色从敌方变为友方还有沼泽流沙这类临时地形效果一段时间后会消失。这些都需要在运行时调用Tilemap.SetTile。踩过的坑是高频SetTile会造成明显的卡顿。原因在于Tilemap的脏区重绘和Collider重建。如果一个32×32的Chunk里频繁SetTileTilemapRenderer会认为整个Chunk需要刷新每帧刷几十个Tile就会拖累帧率。解决方案是把SetTile调用合并而且尽量批量提交// 避免逐格SetTile优先使用SetTiles批量接口 TileBase[] tileArray new TileBase[totalCount]; // 构造tileArray填入对应坐标的Tile引用 tilemap.SetTiles(positions, tileArray);另一个更彻底的方案是不要在Tilemap上做高频变化的地表表现把这些内容挪到Shader层。占领地块的颜色变化、行军路径的高亮、迷雾的淡入淡出本质都是状态变化视觉渐变动画放到Tilemap上每次都是改数据而放到Shader上只是改一个uniform或一张控制贴图。这也是后面单独用Shader处理迷雾和状态覆盖层的初衷。3. 数据分层架构逻辑层、持久层和渲染层不再打架很多SLG项目卡在最核心的地图数据设计上。一个最常见的错误写法是public class MapCell { public int TerrainType; // 地形 public int OwnerId; // 归属 public bool IsExplored; // 是否已探索 public int BuildingId; // 建筑 public int ResourceValue; // 资源值 public bool IsOnFire; // 是否着火 public int CampId; // 阵营 // 需求扩张时继续加字段... }这种写法看起来直观但所有系统都在读写同一个类耦合越来越重。我要做的是把它拆成三层逻辑层LogicModel、持久层DataModel、渲染层ViewModel。3.1 逻辑层只放玩法规则相关的数据逻辑层是服务端权威数据在客户端的镜像只关心玩法不关心画面。比如地块类型决定了能否通行、资源产出倍率归属与视野这个地块属于哪个玩家/势力建筑状态是否存在建筑、建筑等级临时效果流沙、火焰的剩余时间戳逻辑层的核心要求是纯数据无表现。它的数据结构不依赖于任何Unity类型比如坐标不存Vector2Int而是存两个短整型方便服务端同步和断线重连时快照对比。逻辑层由服务端消息驱动客户端收到地图相关协议后更新对应的MapCell数据。注意领域事件机制——别让PVP系统、资源系统、任务系统直接去改MapCell而是发一个MapCellUpdatedEvent谁感兴趣谁订阅。3.2 持久层与存档和同步强相关持久层负责跟存档、回放、断线重连打交道。它和逻辑层相比最大的差异是持久层是扁平化的为了序列化做服务。逻辑层是一个个MapCell对象而持久层可能是三个byte数组——terrainType[]、ownerId[]、buildingLevel[]。这个设计的目的是减少存档体积和同步带宽。36万个格子如果用一份字典序列化数据量随格子数量线性膨胀但拆成三个紧凑数组后再配合按Chunk的压缩存一份全量地图也就几百KB同步时还能做差异比较。3.3 渲染层只面向Tilemap和Shader渲染层不关心这座城是三级还是四级只关心这一格应该显示成什么样子。渲染层的职责是把逻辑层的Tile类型映射到具体的TileBase或者Shader参数维护迷雾贴图、覆盖层贴图等GPU侧数据负责坐标转换逻辑坐标 → 世界坐标 → 屏幕像素最关键的一点是渲染层必须监听逻辑层的事件而不是被逻辑层直接驱动访问。比如拓地事件触发时渲染层监听到AreaClaimedEvent然后去更新覆盖层Shader的控制贴图而不是在逻辑代码里直接调SetTile或者改Material。事件驱动的收益在策划迭代时特别明显。有一次策划要求占领地块周围边框闪烁的效果如果渲染逻辑被散落在各个系统里每个系统都要改而事件驱动模式下只需要在渲染层新加一个监听AreaClaimedEvent的模块生成一个三帧闪烁的动画参数传给Shader即可其他系统完全不用动。3.4 数据流全貌与同步容错最终的数据流是这样一条单向管道服务端协议 → 逻辑层(纯C#数据) → 领域事件 → 渲染层(Tilemap/Shader) → 屏幕任何一环出了问题都能单独回滚。比如渲染层崩了逻辑层的数据还都在重连时可以整体重建逻辑层被错误数据污染时配合持久层的快照拉回也能恢复到同步点。在同步容错上有一个实战经验客户端不要无条件信任服务端的全量地图同步。一张大地图的同步数据量很大如果通信拥堵玩家点进地图容易出现半张图空白的问题。稳妥做法是进入地图先下载一份按Chunk组织的地形归属建筑快照然后依赖增量事件修正。快照优先级以玩家当前位置为中心做环形下载而不是老老实实按坐标顺序下载。4. Shader实战迷雾、地块过渡和动态地表的实现思路与关键代码数据分层解决的是数据从哪来Shader解决的是画得又快又好看。这一节是本文的硬核部分——涉及三个实用的Shader技巧视野迷雾Fog of War、地块边缘过渡、动态状态覆盖层。4.1 用ControlTexture做视野迷雾而不是逐格半透明Tile迷雾最烂的实现是每一个未探索格子上面叠一个半透明黑色Sprite。36万个格子就要创建36万个Sprite哪怕合并成一大块Mesh内存和更新频率也扛不住。推荐方案是用一张分辨率等于地图格数的ControlTexture配合TilemapShader采样。具体操作地图600×600格就创建一张512×512向上取2的幂的RenderTextureR通道存可见度0完全未知1已探索0.5当前视野内可见。视野变化时把可见区域对应的像素值写入RT。因为整个地图只有一张RT更新时改动极小——一支500人的部队移动只需更新约几十个像素。地表Shader采样时用片元的世界坐标换算成对应的uv再采样这张RT用R通道值混合迷雾层的颜色。关键代码HLSL片段适用于URP// 顶点着色器里计算好世界坐标对应的控制纹理uv float2 fowUV (worldPos.xz - _MapWorldOffset) / _MapWorldSize; // 片元着色器 float visibility tex2Dlod(_FOWTex, float4(fowUV, 0, 0)).r; float3 fogColor _FogColor.rgb; float3 baseColor tex2D(_MainTex, TRANSFORM_TEX(uv, _MainTex)).rgb; float3 finalColor lerp(fogColor * 0.05, baseColor, visibility); // 单位视野内完全不透明探索过但不在视野内的半透明未知区域虚化 float alpha saturate(visibility * 1.5); return float4(finalColor, alpha);值得注意的是ControlTexture的大小不一定要和逻辑格完全一致。如果迷雾边界需要柔化可以降低RT分辨率到逻辑格的1/4利用硬件双线性过滤自动产生过渡带。不过过低的RT分辨率会让小地块比如一格小溪边缘模糊需要结合项目地块的美术风格微调。4.2 地块边缘过渡读取邻域而不是靠美术拼AutoTileSLG最影响观感的就是地形过渡带草地到沙地的交界、水域到陆地的岸边。如果全靠美术预先画好各种过渡块草地-沙地上、下、左、右、对角图集体积会爆炸而且每新增一种地形组合就要补素材。更聪明的做法是通过Shader判断当前片元属于哪一格再读取相邻格的地形类型动态混合两种地形的纹理。这里依赖一张地形ID贴图地图的每一格写入一个灰度值代表地形类型ID。Shader中根据片元所在格的中心坐标采样上下左右四个邻居的ID如果邻居和当前格类型不同就在边界处做相邻地形的纹理混合或色差混合。核心伪代码float4 neighbors float4( tex2Dlod(_TerrainIDTex, float4(centerUV float2(0, _TexelSize.y), 0, 0)).r, // 上 tex2Dlod(_TerrainIDTex, float4(centerUV - float2(0, _TexelSize.y), 0, 0)).r, // 下 tex2Dlod(_TerrainIDTex, float4(centerUV - float2(_TexelSize.x, 0), 0, 0)).r, // 左 tex2Dlod(_TerrainIDTex, float4(centerUV float2(_TexelSize.x, 0), 0, 0)).r // 右 ); float combined (neighbors.x ! currentID) (neighbors.y ! currentID) (neighbors.z ! currentID) (neighbors.w ! currentID); // 根据combined值在普染色和过渡色之间插值 float blend smoothstep(0.5, 2.5, combined); float3 terrainColor lerp(currentColor, transitionColor, blend);用这种方式新增地形类型只需要加一个ID不必补美术素材。代价是每帧要多采样4-5次控制纹理在移动端会增加少量GPU开销但相比逐格物体渲染便宜得多。实测在Adreno 660这种中端GPU上整屏的一千多个地块做边缘过渡完全没有压力。4.3 动态状态覆盖层占领、拓地、行军高亮的统一实现SLG场景里频繁出现的地块高亮行军目的地、着色归属变化、闪烁可攻击状态也都可以收敛到一个覆盖层Shader中。我的做法是再建一层和地面Tilemap对齐的覆盖层网格它不对应实际资源而是用一张状态控制图来控制网格上每个像素的颜色。这张控制图的像素含义与前面的迷雾RT不同它有RGBA四个通道R代表阵营颜色A的权重G代表阵营B的权重B代表高亮强度A代表整体透明度。对应的Shader可能长这样float3 stateColor tex2D(_StateTex, stateUV).rgb; float3 highlight stateColor.r * _CampColorA stateColor.g * _CampColorB; float3 baseColor tex2D(_MainTex, uv).rgb; float3 blended lerp(baseColor, highlight, stateColor.b); // 边缘柔化 float edge abs(stateColor.b - 0.5); float alphaMask smoothstep(0.1, 0.0, edge); return float4(blended, alphaMask);状态控制图的数据来源是逻辑层的归属字段和行军路径计算模块。事件驱动下逻辑层发出这块地从A玩家变成B玩家的事件渲染层只要把这个事件转成控制图上对应像素的RGBA值更新即可。因为控制图分辨率低和地图大小等量更新一个像素的开销可以忽略不计。4.4 迷雾的动态表现与性能取舍还有一个日常运营期总会遇到的痛点迷雾区域的边界变化频繁。每次推进营寨或者部队视野变化迷雾RT都要局部擦除。这里推荐在CPU侧管理一个FogBrushTexture把要标记为可见的圆形区域烘焙成一张径向渐变Mask然后通过Blit把Mask混合到迷雾RT上而不是直接逐像素SetPixel。Blit操作会在GPU上执行CPU压力几乎为零。实际开发时我发现很多性能问题不是采样次数多而是Shader代码里的分支语句和纹理采样次数失控。这里给一个排查建议用RenderDoc抓一帧统计每个像素的占用率如果某个地表Shader的计算量明显高于预期大概率是采样次数超标或者循环语句嵌入到了片元着色器。永远记住可预计算的放CPU按帧变化的放uniform按像素变化的才放片元着色器。5. 性能治理DrawCall、内存和Shader变体的取舍5.1 别迷信一张Tilemap一个DrawCall我见过不少团队一开始就指望TilemapRenderer把所有东西合批结果合批在运行时因为材质差异或图集未合并而失效。TilemapRenderer合批有个前提同层Tile必须使用同一张SpriteAtlas并且材质实例相同。所以项目中要明确规矩GroundLayer的地形Tile全部打在同一张Atlas上Decoration和BuildLayer的Tile各自打图集Shader只使用一套材质属性通过MaterialPropertyBlock传状态避免因为材质参数差异导致两次DrawCall。5.2 纹理压缩格式和内存SLG地表纹理的面积非常大假设一张4096×4096的地形图集以RGBA32格式加载内存是64MB如果压缩成ASTC 6×6内存会砍到不到11MB。移动端强烈建议统一使用ASTC压缩并在真机上验证压缩率与画质。另外一个容易忽略的内存点是Tile资源引用。Editor环境下TileAsset本身包含Sprite引用如果打包时没有正确处理会出现同一张Sprite被多个TileAsset重复加载的情况。我的做法是编写编辑器工具在Build前统一扫描TileAsset把重复的Sprite引用替换为图集引用再重新生成图集。5.3 Shader变体膨胀最隐蔽的包体杀手使用Shader功能时功能装得越来越多迷雾、边缘过渡、覆盖层、动态雪地……如果每个功能都用[Toggle]或[KeywordEnum]做开关最终编译出的Shader变体数量是几何级增长的。项目包体超过预期很多时候就是变体膨胀。控制变体的办法不为玩家客户端保留Editor专用关键字使用#pragma multi_compile_local并按场景预编译不要担心打包时自动生成全部组合同一设备上ShaderVariantCollectionSVC做白名单交付前跑一遍真机资源检测把不用的变体清掉移动端另一个经验是避免在片元着色器里使用if判断关键字尽量用整数运算或在CPU侧用四套Material参数替代四个Shader变体。SLG的Shader数量不多但每个都够重用CPU侧的跨帧参数来做功能开关比编译成几十个变体要省得多。5.4 渲染顺序与Overdraw治理SLG大地图有个隐性问题四层Tilemap叠在一起加上覆盖层的半透明混合一片视野范围内overdraw很容易到3-4倍。在全屏泛光或高分辨率下这会让GPU负载大幅上升。治理手段有两个层次渲染顺序优化把Ground、Decoration、Build、Overlay四层按从下到上渲染避免高层半透明遮挡后底层不必要输出。URP里可以用RenderQueue区分地面层用Opaque队列覆盖层用Transparent队列并且写入深度避免无效像素的混合。剔除优化如果地图足够大可以开启物体级剔除只渲染相机可见的Chunk。这比可视距离裁剪更高效因为按Chunk级别剔除时Ground层的绘制区域能缩小到屏幕分辨率大小而不是整个Tilemap的AABB。6. 移动端环境下的踩坑记录与排查链路6.1 坐标对齐问题逻辑格、Tile坐标和世界坐标的混战项目早期最多的问题是坐标系统混乱。策划在编辑器里看到的是58, 132格服务端发的是x58,y132的紧凑数组客户端Shader计算本应使用世界坐标→UV坐标但一旦Tile尺寸设置不是整数像素世界坐标换算回UV就会出现半个格子的偏移导致迷雾边界错位。排查手段很土但有效在Scene视图里用一个可移动Cube把Tilemap的Grid网格显示打开逐个坐标对照Tile的中心、边缘和Shader采样的世界坐标点是否完全重合。我最后用了一个统一的MapCoordUtil类所有坐标换算都走这一个入口不允许别的系统自己写换算彻底终结了这个坑。6.2 Tilemap Collider生成时机运行时碰撞体导致物理开销如果一个SLG需要在关卡里做寻路遮挡、建筑可碰撞最常见的做法是给Tilemap挂TilemapCollider2D。但它的运行原理是基于每个Tile的Collider形状生成PhysicsShape运行时经常因为地形频繁变化而重建导致卡顿和对撞检测的抖动。我的建议是运行时不要直接用TilemapCollider2D。寻路时直接查逻辑层的地形矩阵判定哪个格子不可通行比走物理碰撞高效得多还顺便统一了逻辑和表现的边界。如果需要阻止单位被地形推挤可以用一个简化后的凸多边形Collider描述大型湖泊、山脉的轮廓挂在独立物体上而不是给每块地形加碰撞。6.3 营地移动与地图大范围变化的帧率颠簸当玩家把主城从一个地方迁到另一个地方服务端会下发一批地图大范围变化的消息。如果客户端把变化转成几百次SetTile调用瞬间帧率会跌破10帧。我的解法是把这类大规模区块变动合并成一个地图刷新任务放在一帧里只处理一部分ChunkCPU负载平滑分摊。同时立即触发迷雾RT的全图可见度更新防止视觉上出现被剪裁一半的撕裂感。7. 总结一点个人心得回到最开始的问题SLG大地图地表渲染的核心不是某一项技术而是如何把地图数据、渲染表现和玩法逻辑拆成清晰的管道。Tilemap负责地形块的呈现和编辑器工作流数据分层解决36万个格子在客户端、服务端、存档之间高效流转Shader负责迷雾、地块过渡和状态反馈这些画出来的玩法。三者配合才能在保证美术表现的前提下让中端机也能流畅运行大地图。我做这套架构的最大体会是解法最好是在原型阶段就定好的而不是等地图铺满了再推倒重来。如果你的SLG项目还没有处理地图数据与渲染的关系强烈建议先从数据分层入手再考虑Tilemap和Shader细节。数据不清爽渲染做得再花哨也迟早要在线上付出代价。最后分享一个我自己一直在坚持的技巧任何打开关比如迷雾是否启用雪地是否覆盖都尽量做成可以运行时动态切换的Shader参数。运营活动、版本迭代时不用重新出图、不用改版本一个小小的开关就能让策划自己验证效果省下的沟通和返工时间非常多。
