1. 项目概述当瓦片需要“呼吸”时网格为何必须“定海神针”在Unity里做2D游戏尤其是平台跳跃、RPG或者策略类项目Tilemap瓦片地图几乎是标配。它让关卡设计变得像拼图一样直观高效。但不知道你有没有遇到过这样的需求游戏里某个区域的瓦片需要根据玩法动态变化大小——比如一个会周期性膨胀收缩的毒气区域或者一个受玩家能量影响而脉动的魔法地板。你的第一反应可能是简单直接改Tilemap里Sprite的Scale不就行了如果你真这么试过大概率会立刻遇到一个让人头疼的问题当你放大一个瓦片Tile时它确实变大了但它所占据的那个网格Grid的尺寸也跟着一起被撑大了后果就是原本严丝合缝的地图瞬间变得支离破碎相邻的瓦片之间出现了难看的缝隙或者更糟整个Tilemap的坐标和对齐全都乱套了。玩家角色原本能稳稳站立的平台边缘现在可能因为网格的错位而掉下去。这背后的核心矛盾在于在Unity的默认Tilemap系统中瓦片的视觉表现Sprite的缩放和它的逻辑占位网格单元Cell的大小是强耦合的。所以我们今天要啃的硬骨头就是“Unity Tilemap动态瓦片缩放保持网格尺寸不变”。这个需求的核心价值在于“解耦”让瓦片的视觉缩放独立于其所在的网格逻辑框架。网格必须像棋盘上的格子一样固定不变这是游戏逻辑如碰撞检测、坐标计算、寻路的基石而瓦片作为棋盘上的棋子则可以自由地放大、缩小、旋转实现丰富的动态视觉效果。这不仅仅是解决一个显示BUG更是为2D游戏动态环境交互打开了一扇新的大门。无论你是想制作动态变化的地形还是为特定瓦片添加生动的视觉效果掌握这项技术都能让你的游戏世界更加鲜活。2. 核心思路拆解从“蛮干”到“巧劲”的三种路径面对这个问题最直接的“蛮干”方法就是去修改Unity的源码或者用非常Hack的方式去打断内部关联但这显然不现实也不稳定。经过实践我总结了三种主流且可靠的实现方案它们分别从不同的层级切入各有优劣和适用场景。2.1 方案一基于Shader的视觉缩放纯GPU方案这是性能最优雅、对游戏逻辑零侵入的方案。其核心思想是不动瓦片Tile的Transform也不动网格Grid而是通过自定义Shader在渲染阶段对瓦片贴图进行缩放。实现原理我们为Tilemap使用的材质球编写一个自定义的Shader。在这个Shader中我们新增一个属性比如_TileScale它是一个float2类型代表UV坐标的缩放系数。在片元着色器Fragment Shader里我们对输入的UV坐标进行反向缩放计算。简单来说如果我想让贴图视觉上放大2倍那么我就在Shader里将采样的UV坐标范围缩小到原来的0.5倍这样同一张贴图就被“拉伸”到了更大的屏幕区域但瓦片占据的网格空间丝毫未变。优点性能极高所有计算在GPU上完成不增加CPU负担不破坏合批。逻辑无损Collider、坐标转换等所有游戏逻辑完全不受影响因为它们感知到的依然是原始大小的瓦片。动态灵活可以通过MaterialPropertyBlock为不同的Tilemap甚至不同的瓦片单独设置缩放系数实现局部动态效果。缺点与注意事项Shader入门门槛需要一定的Shader编写和调试能力。纹理采样边缘问题缩放中心默认是UV的(0,0)点即左下角。如果你需要以瓦片中心进行缩放需要在Shader中进行UV坐标偏移计算否则放大时瓦片会向一个方向“飘走”。这是一个关键细节公式大致为scaledUV (originalUV - 0.5) / _TileScale 0.5。与Tilemap动画的兼容性如果瓦片本身是动画瓦片Animated Tile需要确保自定义Shader能正确处理动画UV。提示对于不熟悉Shader的朋友可以先用一个简单的测试Shader入手。在Unity中创建一个Unlit Shader在frag函数里修改i.uv你就能立刻看到效果。这是理解此方案最快的方式。2.2 方案二动态创建子游戏对象GameObject per Tile这是一种更“Unity传统”的思路将每个需要缩放的瓦片替换为一个独立的、带有SpriteRenderer的子GameObject。实现原理我们不再使用标准的Tile来绘制这些特殊瓦片。取而代之的是在生成Tilemap时或在运行时检测到特定瓦片时我们在该瓦片对应的网格世界坐标位置实例化一个预设体Prefab。这个预设体包含一个SpriteRenderer其Sprite就是原来瓦片的图片。然后你可以随意缩放这个GameObject的Transform因为它已经完全脱离了Tilemap的网格系统独立存在于场景中。优点直观易控完全使用Unity常规的Transform系统进行缩放、旋转控制方式非常直观。功能扩展性强可以轻松为这个GameObject添加额外的组件如自定义碰撞体、粒子效果、动画控制器等实现复杂的交互。无需Shader对美术和策划更友好他们可以直接在场景中调整预览。缺点与注意事项性能开销大每个动态瓦片都是一个独立的GameObject会显著增加Draw Call如果材质不同并加重CPU的管理负担。不适合大规模使用比如成百上千个。管理复杂度高你需要自己管理这些动态生成对象的生命周期创建、销毁、缓存并确保它们的坐标与Tilemap网格同步。遮挡排序问题Tilemap有内置的排序层级Order in Layer手动创建的SpriteRenderer需要仔细设置Sorting Layer和Order in Layer才能与静态Tilemap正确混合显示。实操心得这个方案最适合用于场景中数量稀少但交互复杂的“特效瓦片”比如一个会被点爆的炸药桶瓦片或者一个播放复杂动画的传送阵。你可以为其预制体添加完整的动画状态机和音效这是纯Shader方案难以比拟的。2.3 方案三运行时替换SpriteAsset层面操作这个方案比较取巧它操作的是瓦片所使用的Sprite资产本身通过程序化地生成不同缩放尺寸的Sprite副本来实现。实现原理Unity的Tile在绘制时引用的是一个Sprite资产。我们可以在运行时根据需要的缩放比例通过代码如Texture2D.ReadPixels配合Sprite.Create动态生成一个新的、尺寸不同的Sprite。然后将这个新Sprite赋值给Tilemap中特定位置的Tile或者直接创建一个使用该Sprite的新Tile并替换上去。优点兼容性最好替换后的Tile依然是标准TileTilemap的所有功能如规则瓦片、动画瓦片和优化合批都得以保留。逻辑统一对于游戏逻辑而言它处理的仍然是标准的Tilemap和Tile没有引入新的实体类型。缺点与注意事项内存与性能隐患动态创建Sprite会产生新的纹理资源如果不进行缓存管理极易造成内存泄漏和GC垃圾回收压力。必须建立一套“缩放比例-Sprite”的缓存字典。实时性较差生成Sprite特别是大图是CPU密集型操作不适合每帧都进行。更适合在加载关卡时预先处理好几种固定比例的Sprite。修改的是资产引用这会导致所有使用原Sprite的Tile都发生变化除非你用了Sprite的多个副本。通常需要配合Tilemap的特定瓦片替换API只修改目标位置的瓦片。注意这是三种方案中陷阱最多的。如果你决定采用务必设计一个健壮的缓存池并在场景切换时妥善清理生成的Sprite资产否则内存增长会悄无声息地拖垮你的游戏。3. 方案抉择与实战环境搭建纸上谈兵终觉浅绝知此事要躬行。理论说完我们得动手选一个。对于大多数追求性能和优雅解耦的场景方案一Shader方案是首选。它不仅解决了核心问题还保持了Tilemap系统的完整性性能开销最小。因此接下来的深度实操我们将以方案一为主线为你完整还原实现过程。首先我们搭建一个标准的测试环境在Unity中创建一个2D项目。在Hierarchy面板右键 - 2D Object - Tilemap创建一个默认的Tilemap它会自动带一个Grid父物体。准备一张简单的瓦片图Sprite比如一个32x32像素的方块导入到项目中并设置为Sprite类型。打开Window - 2D - Tile Palette创建一个调色板将你的瓦片Sprite拖进去然后在场景中的Tilemap上绘制一片区域。现在如果你选中某个瓦片在Inspector里修改其Sprite的Scale立刻就能看到之前提到的“网格被撑大”的灾难现场。我们的目标就是消灭这种现象。4. 核心实现编写自定义Tilemap缩放Shader我们选择编写一个Surface Shader因为它能更好地与Unity的灯光系统如果你使用2D光照配合。但为了最简演示我们从Unlit Shader开始更清晰。4.1 创建基础Unlit缩放Shader在Project面板右键 - Create - Shader - Unlit Shader命名为“UnlitTileScalable”。 用代码编辑器打开它我们进行关键修改Shader Custom/UnlitTileScalable { Properties { _MainTex (Texture, 2D) white {} // 新增缩放属性默认(1,1)表示不缩放 _TileScale (Tile Scale, Vector) (1, 1, 0, 0) // 新增缩放中心偏移用于实现以瓦片中心缩放 _Pivot (Pivot (XY), Vector) (0.5, 0.5, 0, 0) } SubShader { Tags { RenderTypeOpaque } LOD 100 Pass { CGPROGRAM #pragma vertex vert #pragma fragment frag #include UnityCG.cginc struct appdata { float4 vertex : POSITION; float2 uv : TEXCOORD0; }; struct v2f { float2 uv : TEXCOORD0; float4 vertex : SV_POSITION; }; sampler2D _MainTex; float4 _MainTex_ST; // 包含了纹理的Tiling和Offset float2 _TileScale; float2 _Pivot; v2f vert (appdata v) { v2f o; o.vertex UnityObjectToClipPos(v.vertex); // 关键计算对UV进行缩放和偏移 // 1. 将UV从[0,1]空间转换到以Pivot为中心的原点空间 // 2. 除以缩放系数 // 3. 转换回[0,1]空间 float2 scaledUV (v.uv - _Pivot) / _TileScale _Pivot; // 应用纹理的Tiling和Offset来自材质球 o.uv TRANSFORM_TEX(scaledUV, _MainTex); return o; } fixed4 frag (v2f i) : SV_Target { fixed4 col tex2D(_MainTex, i.uv); return col; } ENDCG } } }代码解析_TileScale这是我们控制缩放的核心。(2,2)表示视觉放大到2倍因为UV除以2(0.5,0.5)表示视觉缩小到一半。_Pivot缩放中心点。默认(0.5,0.5)代表Sprite的中心。这是实现“中心缩放”的关键避免了瓦片缩放时位置偏移。在顶点着色器vert中我们对传入的原始UV进行了变换。公式(v.uv - _Pivot) / _TileScale _Pivot是二维缩放的标准矩阵变换在UV空间的体现。4.2 创建材质并应用到Tilemap在Project面板右键上面创建的Shader - Create - Material会自动生成一个使用该Shader的材质球。选中你的Tilemap Renderer组件将Material属性拖拽替换成我们新建的这个材质球。现在在Tilemap Renderer的材质属性下方你应该能看到“Tile Scale”和“Pivot”两个属性。尝试在编辑器里将“Tile Scale”从(1,1)改为(2,2)。神奇的事情发生了所有瓦片的图案都变大了但是你的网格线在Scene视图开启Grid显示纹丝不动瓦片之间的接缝依然完美。你已经实现了核心效果。4.3 实现动态与差异化缩放在编辑器里手动调材质球参数只能全局缩放。我们想要的是动态的、可编程的、甚至每个瓦片不同的缩放。这就需要用到MaterialPropertyBlock。MaterialPropertyBlock允许你在运行时修改Renderer的材质属性而无需创建新的材质实例这对于性能非常友好。我们写一个简单的脚本DynamicTileScaler.cs挂载到Tilemap物体上using UnityEngine; using UnityEngine.Tilemaps; [RequireComponent(typeof(TilemapRenderer))] public class DynamicTileScaler : MonoBehaviour { private TilemapRenderer tilemapRenderer; private MaterialPropertyBlock propertyBlock; [Header(全局缩放控制)] public Vector2 globalTileScale Vector2.one; public Vector2 scalePivot new Vector2(0.5f, 0.5f); [Header(测试用动态变化)] public bool oscillateScale false; public float oscillationSpeed 1.0f; public float oscillationMin 0.8f; public float oscillationMax 1.2f; void Start() { tilemapRenderer GetComponentTilemapRenderer(); propertyBlock new MaterialPropertyBlock(); // 初始获取一次当前的属性块避免覆盖其他已设置的属性 tilemapRenderer.GetPropertyBlock(propertyBlock); } void Update() { // 获取当前的属性块 tilemapRenderer.GetPropertyBlock(propertyBlock); // 动态计算缩放示例呼吸效果 if (oscillateScale) { float scale Mathf.Lerp(oscillationMin, oscillationMax, (Mathf.Sin(Time.time * oscillationSpeed) 1f) * 0.5f); globalTileScale new Vector2(scale, scale); } // 设置Shader属性 propertyBlock.SetVector(_TileScale, globalTileScale); propertyBlock.SetVector(_Pivot, scalePivot); // 应用属性块 tilemapRenderer.SetPropertyBlock(propertyBlock); } // 提供一个公共方法供其他脚本控制特定Tilemap的缩放 public void SetTileScale(Vector2 scale) { globalTileScale scale; } }将这个脚本挂到你的Tilemap物体上运行游戏。勾选Oscillate Scale你会看到整个Tilemap上的瓦片像在呼吸一样有节奏地放大缩小而网格系统稳如泰山。更进一步差异化缩放如果想让Tilemap上不同位置的瓦片有不同的缩放呢这需要更精细的控制。思路是我们不能为每个瓦片单独设置属性块那样性能太差但我们可以利用顶点数据。一种高级做法是修改Shader接受一张Texture2D作为“缩放图”Scale Map每个像素的RG通道存储对应世界坐标瓦片的缩放值。然后在顶点或片段着色器中根据瓦片的世界位置去采样这张缩放图得到各自的缩放系数。这涉及到将世界坐标传递到Shader以及RenderTexture的使用实现复杂度较高通常用于需要大量差异化动态效果的场景如受冲击波影响的地面。5. 避坑指南与性能优化实录在实际项目中应用这项技术我踩过不少坑这里分享给你希望能帮你省下几个小时甚至几天的调试时间。5.1 坑一Shader缩放导致的纹理过滤瑕疵当你把瓦片放得很大时可能会发现纹理边缘变得模糊或者出现锯齿。这是因为放大超出了纹理原始分辨率。解决方案使用高质量原图确保你的瓦片Sprite原始尺寸足够大或者使用Filter Mode为Point (no filter)来保持像素风格但这在缩放时会有明显的马赛克感。在Shader中启用Mipmap对于平滑缩放确保纹理导入设置中Generate Mip Maps是开启的并且在Shader中正确采样。我们的简单Unlit Shader默认会使用纹理设置的过滤模式。考虑使用Substance或程序化纹理对于需要极度放大的情况可以考虑使用支持无缝缩放的材质方案。5.2 坑二与2D光照和法线贴图的冲突如果你使用了Unity的2D Renderer with LightsURP或内置RP的2D光照我们的自定义Shader可能会破坏光照。因为标准2D光照需要特定的Shader路径和光照模型。解决方案基于Lit Shader模板修改不要从Unlit Shader开始而是复制一个Sprites/Default或URP下的2D/Sprite-Lit-DefaultShader在其基础上添加我们的缩放UV逻辑。确保光照计算部分如法线、漫反射是在缩放后的UV基础上进行的。仔细处理法线贴图如果你的瓦片有法线贴图用于2D光照那么法线贴图的UV必须和漫反射贴图进行完全相同的缩放变换否则光照会错位。5.3 坑三排序与层级错乱动态缩放瓦片可能会与Tilemap内其他未缩放的瓦片或者场景中其他Sprite的渲染排序产生冲突。解决方案固定材质渲染队列在我们的Shader中可以明确指定QueueTransparent或QueueGeometry确保它在一个确定的顺序渲染。利用Tilemap Renderer的排序属性确保你的Tilemap Renderer上的Sorting Layer和Order in Layer设置正确动态缩放不应改变这些基础排序设置。对于方案二GameObject方案要手动设置每个生成的SpriteRenderer的sortingOrder通常可以设置为TilemapRenderer.orderInLayer 1之类的值让它绘制在Tilemap之上。5.4 性能优化要点PropertyBlock是朋友如前所述始终使用MaterialPropertyBlock来修改材质参数而不是material.SetVector。后者会创建新的材质实例破坏动态合批并增加内存开销。缩放变化频率避免每帧都剧烈变化缩放值。如果缩放是平滑过渡的考虑在Update中处理如果是触发式的只在状态改变时更新一次属性块。Shader复杂度我们的缩放计算放在顶点着色器vert中这是性能最好的位置。片段着色器frag的调用次数远多于顶点应避免在那里做复杂的每像素UV计算。对于大量差异化缩放如果必须实现成百上千个瓦片独立缩放Scale Map纹理方案一张RGBA32纹理可以存储大量数据在性能上远优于实例化上千个GameObject。但需要权衡的是这会增加Shader的采样指令和带宽消耗。6. 方案横向对比与选型决策表为了让你在具体项目中能快速做出选择我将三种核心方案的关键特性总结如下特性维度方案一Shader缩放方案二子GameObject方案三运行时替换Sprite核心原理在GPU着色器中变换UV用独立GameObject替代Tile动态生成并替换Sprite资产性能影响极低(GPU计算保持合批)高(增加GameObject和Draw Call)中(CPU生成纹理内存管理负担)逻辑影响无(网格坐标完全不变)有(需额外管理对象与网格对齐)无(仍是标准Tile)动态灵活性高(可每帧变化可局部控制)极高(可附加任意组件与逻辑)低(适合有限预定义状态)实现复杂度中 (需编写/调试Shader)低 (使用常规Unity对象)中高 (需处理资产创建与缓存)内存开销低 (仅增加Shader参数)高 (每个对象都有开销)中 (取决于缓存多少Sprite变体)最佳适用场景大面积动态地形、环境特效 (如波浪、脉动)少量高交互性物体 (如可破坏箱子、机关)瓦片需要在几种固定视觉状态间切换我的个人经验是对于90%需要“动态瓦片缩放”的场景方案一Shader方案都是最优解。它完美地贯彻了“解耦”思想在效果和性能之间取得了最佳平衡。方案二仅在需要为瓦片附加非常复杂、超出渲染范畴的逻辑时才考虑。方案三则更像一个特定情况下的补丁除非项目有特殊限制如必须使用标准Tile碰撞否则不推荐作为首选。7. 扩展思考不只是缩放掌握了保持网格不变的缩放技术你的思路可以进一步打开。这套“视觉与逻辑解耦”的思维模型可以应用到更多Tilemap的动态效果上动态旋转在Shader中除了缩放UV还可以旋转UV。让瓦片图案旋转而碰撞体保持原方向。这对于制作旋转的风扇叶片、转动的齿轮地板非常有用。顶点动画在Shader的顶点着色器中对瓦片四个顶点的位置进行小幅度的周期偏移可以实现水面波动、地面柔软起伏的效果而网格逻辑位置依然是固定的。纹理动画结合时间变量_Time在Shader里让瓦片纹理滚动、闪烁或进行复杂的UV变换实现熔岩流动、电流传导等效果所有这些都不会干扰到游戏单位的移动逻辑。本质上一旦你通过Shader接管了Tile的最终渲染表现你就拥有了巨大的创作自由。你可以把Tilemap的网格仅仅当作一个精准的坐标定位系统而在其之上构建一个视觉上丰富多彩、动态变化的游戏世界。这就是技术为设计赋能的一个生动例子。