做2D游戏做到中期最让人头疼的往往不是玩法逻辑而是场景搭建。我最早做平台跳跃游戏时一张地图全靠手摆Sprite几百上千个碎块堆在Hierarchy里找东西靠翻改东西靠选调个墙体的位置要在一堆同名物体里辨认半天。最难受的是绘制批次和内存占用场景稍微大一点Profiler里Draw Call直接起飞。后来换了Unity TileMap整个关卡搭建方式才算理顺。这篇文章不打算给你念API文档而是把TileMap这套系统从概念、原理到实战说明白它到底怎么工作、应该怎么用以及在什么情况下它反而不合适。这篇文章适合两类人一类是刚开始学Unity、准备做2D游戏但还没有系统接触过瓦片地图的开发者另一类是已经用过TileMap但只停留在“拖个调色板往场景里画”的程度想搞清楚背后的数据结构和性能逻辑顺便解决几个常见坑的人。读完你至少能理解四件事TileMap为什么要挂在Grid下面、规则瓦片是怎么自动匹配邻居的、碰撞体该如何正确合并、以及运行时动态改格子应该注意什么。1. 从手动摆图到瓦片地图TileMap 到底解决了什么要理解TileMap先得回到一个最原始的问题为什么不能直接用Sprite把地图拼出来理论上完全可以。把一张张地块图片当作Sprite拖进场景用Transform摆好位置无非是工作量的问题。但这种做法在地图稍微复杂一点之后会呈现三个非常现实的问题。第一个是场景物体数量爆炸。假设你有做一个100x100格的地图用Sprite碎片摆放意味着场景里会出现一万个GameObject。每个GameObject都有Transform、SpriteRenderer即便内容一样Unity依然要把它们当作独立的实体来管理。Editor里卡顿是第一层运行时的管理开销是第二层而最明显的是在Profiler里能看到大量CPU时间花在C层级的节点管理上。第二个是绘制批次过高。SpriteRenderer默认按顺序渲染虽然Unity有动态合批但合批的前提是材质一致、贴图一致并且渲染顺序相邻。手动摆放的Sprite一旦穿插了碰撞体、粒子、UI等元素合批经常被打断。地图越大Draw Call越难压下去。第三个是编辑效率低下。改一格地块你得先找到那个Sprite物体再移动它的位置。如果某种地块要更换贴图需要批量替换还得担心漏掉某个角落。最恶心的是做地图迭代时整块区域重排几乎是噩梦。你甚至会想到写编辑器工具来批量摆放但写完又会发现工具只适合一次性操作不适合持续调整。TileMap解决这三个问题的思路其实是一次彻底的重构。它不再把每个地块当作一个独立的GameObject而是把整个地图抽象成一层二维网格数据。每个格子存储的是一个瓦片索引或者引用真正的瓦片资源也就是Tile是共享的。场景里你看到的是一块一块的地块数据结构里存的却只是一张大表。这样一来场景物体数量从“格子数”降到了“图层数”。一万个格子的地图在Hierarchy里只有几个Tilemap对象。绘制批次方面TilemapRenderer会尝试把同一张图集上的相邻瓦片合并成一个网格一次提交完成渲染。编辑效率更是质变你想改一整块区域框选、填充、橡皮擦几秒钟搞定还能配合规则瓦片让地块自动匹配边界。用一个不太严谨但很贴切的类比手动摆Sprite就像是用单独的砖块砌墙砖块之间没有联系拆一块是一块TileMap则像是给墙刷了一层电子表格你只需要维护“哪个位置是哪种砖”这个数据墙本身只是一个计算结果。但这里有一个关键的认知误区需要先纠正。很多初学者以为TileMap只是一个“画地图的工具”用了它画的图好看、方便。实际上TileMap是一套数据驱动的地图方案核心价值不在于“画”而在于“存”和“算”。你可以用代码动态生成地图也可以在地图运行时修改甚至可以把地图数据序列化到存档里。调色板只是编辑器层面的一个入口真正的核心是Tilemap组件上那张“表格”。理解到这一层你才能理解后面所有的设计取舍比如为什么要分多个Tilemap图层、为什么规则瓦片能自动匹配、为什么碰撞体要合并、为什么运行时改格子会触发重绘。2. 拆开看Grid、Tilemap、Tile、TilemapRenderer 各自的活儿很多新手创建TileMap时是直接右键 2D Object TilemapUnity自动生成了一套层级结构一个Grid父物体下面挂了Tilemap子物体。看起来很简单但如果你不知道这四个组件各自的职责后面遇到问题就会一头雾水。我见过不少人在Grid上瞎调Cell Size调完瓦片全部错位然后又不知道错在哪。2.1 Grid坐标基准与网格布局的提供者Grid是整个TileMap系统的坐标系基础。它不参与实际的地块渲染也不存储任何地图数据它的角色是回答一个问题“世界坐标里的这个点落在网格里的哪个格子”Grid有三个核心参数被高频使用Cell Size格子尺寸、Cell Gap格子间隙、Cell Layout网格布局。其中Cell Size经常被搞混。它和Sprite的Pixels Per Unit有直接换算关系。比如你的地块素材是32x32像素Sprite导入时PPU设为32那么一个格子对应的世界单位是1米Unity 2D里1单位通常是1米Cell Size就应该是(1, 1)。如果PPU是16同样是32像素的素材一个格子就是2米Cell Size要相应地改成(2, 2)。这里有个常见的做法是直接把Cell Size设为素材像素值除以PPU的结果这是对的只是容易漏掉像素对齐的问题后面专门说。Cell Layout则决定网格类型。绝大多数2D游戏用Rectangle矩形网格就行但如果你做的是斜45度视角的模拟经营类游戏需要选择Isometric等距网格如果你的地图是六边形战棋类游戏则要选Hexagonal六边形网格。网格类型一旦确定最好不要在项目中期修改因为瓦片坐标系统全变了已有的地图数据会错位。2.2 Tilemap那张真正的“表格”Tilemap就是那个存储二维数据的容器。表面上是网格里的一块块瓦片本质上是内部维护了一个类似字典的数据结构把网格坐标映射到Tile资源引用上。这个组件提供了非常丰富的读写API比如SetTile、GetTile、HasTile、ClearAllTiles、SwapTile等。这些API是你做运行时地图修改、建造破坏系统的入口。Tilemap还自带两个与碰撞相关的子组件TilemapCollider2D和TilemapCompositeCollider2D需要额外添加。前者的作用是根据瓦片自身的碰撞形状生成一个个独立的碰撞体后者的作用是把相邻的碰撞体合并成一个PolygonCollider2D。肉眼看起来差异不大但物理引擎处理一个大的复合碰撞体和处理几十上百个小碰撞体的开销完全是两个量级。后面我会专门展开讲。一个Tilemap对应一个图层所以做游戏时通常会建立多个Tilemap子物体比如地表层、墙壁层、装饰层、交互层。这样做的好处是不同图层可以有不同的排序、不同的碰撞设置还可以分别控制显隐。你只需要在处理逻辑时按层访问即可。2.3 Tile地图单元格的最小数据单元Tile本身是一个ScriptableObject资源文件。它把“显示哪张图”“碰撞形状是什么”“是否会影响导航”等属性打包在一起。这里的关键点是Tile是资源引用不是实例。一万个格子如果都引用同一个Tile内存里只会加载一份Tile数据一万个格子共享这一份引用。这就是TileMap内存开销远低于手动摆Sprite的根本原因之一。Tile上有个很容易被忽略的重要配置项叫做Collider Type。它有三种取值None、Sprite、Grid。None就是没有碰撞Sprite是根据精灵的自定义物理形状生成碰撞Grid则是把整个格子当作一个矩形碰撞。做平台跳跃游戏时平台地块通常用Sprite模式配合精灵图集里的Physics Shape可以做出边缘有弧度的地表碰撞。做整体地形时用Grid模式最简单粗暴。但无论选哪一种都建议配合Composite Collider使用否则瓦片多了碰撞体数量会非常夸张。2.4 TilemapRenderer决定怎么画出来这是真正干渲染活的组件。它有Mode属性分为Chunk和Cell两种。Chunk模式下Unity会把同一图集中的相邻瓦片合并成尽量少的网格块这是默认也是推荐模式对Draw Call最友好。Cell模式则是每个格子单独绘制几乎没有合批优势只在某些需要逐格控制的特殊场景下才会用到。TilemapRenderer还参与了排序。它跟你平时用的SpriteRenderer一样有Sorting Layer和Order in Layer。同一Tilemap对象下所有瓦片共享同一个排序层级所以做Y轴遮挡类的2D游戏时比如角色走到树后会挡住依赖排序层或Order in Layer是行不通的需要用分块Tilemap或者烘焙排序的方法来处理这个后面也会提。四个组件之间的关系可以这样理解Grid是尺子和坐标系Tilemap是数据表Tile是数据条目TilemapRenderer是把数据表画出来的画笔。你改Tilemap里的数据Renderer会去响应这个变化重新生成网格。如果你在运行时改了Tile但没有看到画面更新大概率是改错了对象或者没有调用需要的刷新接口后者在老版本Unity里是个高频坑。3. 动手搭一个 2D 瓦片关卡从创建 Tilemap 到调色板落地理论说了一堆现在实际操作一遍。我会带你把一个最基础的平台跳跃关卡地形跑通包含调色板创建、瓦片制作、绘制和分层。3.1 准备素材规范切割精灵图集很多人卡在这一步就出问题是因为精灵图集没有整理好。做瓦片素材时我建议遵循三条铁律所有地块素材放进同一张图集每块素材之间留足空白Padding至少4像素导入时Filter Mode设为Point。前两条影响是否合批和是否出现边缘出血第三条影响像素风游戏的清晰度。如果你做的是高清风格Filter Mode可以选Bilinear但边缘混血问题还是需要通过Sprite的Padding来解决细节后面坑点总结里说。以常见的16x16像素素材为例图集导入Unity后把Sprite Mode改为Multiple然后点击Sprite Editor把每一块切出来。切的时候要注意网格线要按像素准确对齐不要出现半像素的情况。切割完成后把Pixels Per Unit设置成16Mesh Type设为Full Rect如果不需要精确碰撞可以不设Sprite Physics Shape。3.2 创建Tilemap和调色板素材准备好后在Hierarchy面板里右键 2D Object Tilemap Rectangular。创建后层级结构是Grid下面挂着一个Tilemap。接着打开Tile Palette窗口Window 2D Tile Palette第一次打开会让你创建一个新的调色板。调色板本质上是一个文件夹里面放着可复用的瓦片资产。把切好的精灵直接拖进Tile Palette窗口Unity会自动为每张精灵生成对应的Tile资源。这里有个细节拖入精灵时Unity会询问是否同时创建瓦片资产。如果你的图集里有很多装饰性的单张Sprite比如花、石头它们不适合做成瓦片可以通过过滤器只选取需要的地块。也可以先批量创建然后在调色板里删除多余的。3.3 图层拆分地面层、墙壁层、装饰层接着创建两个以上的Tilemap。选中Grid右键 2D Object Tilemap再建一个。一个作为Ground碰撞层一个作为Wall也是碰撞层但排序更靠后还可以再建一个Detail纯装饰无碰撞。分层的意义在于碰撞和排序可以分开控制。Ground与Wall需要的碰撞体设置相同但装饰层的TilemapRenderer可以做单独的排序让角色从树后面经过时产生遮挡。这里要注意右手边的Tilemap Renderer组件的Sorting Layer设置。默认都在Default层靠Order in Layer区分。装饰层建议Order值比地表层高渲染时才会盖在上面。如果你有多个Sorting Layer也可以分配不同的SortingLayerName这个看项目需求。3.4 瓦片绘制用工具把草图画出来选中Ground这个Tilemap在Tile Palette里选择对应地块然后用画笔工具在Scene视图里绘制。几个常用的快捷键值得记住鼠标不选中场景物体时B是画笔D是橡皮擦G是填充油漆桶R是矩形选区。这里有个小技巧用油漆桶工具之前先选中你要填充的调色板瓦片然后按下G再点击场景中的封闭区域会自动填充整个连通区域。非常方便做地表草皮或者水面。绘制过程中如果发现瓦片对不齐网格检查一下Grid的Cell Size和Sprite的PPU是否匹配同时打开Scene视图右上角的Grid工具开关确保吸附开关打开。3.5 碰撞体加法和合并直接影响到物理性能选择Ground这个Tilemap对象Add Component添加Tilemap Collider 2D然后添加Tilemap Composite Collider 2D。关键操作来了添加Composite Collider 2D时Unity会提示你同时添加Rigidbody 2D并自动把Rigidbody 2D的Body Type设为Static。这个Rigidbody不是让你做物理模拟而是为了让Composite正常工作。如果你打开Tilemap Collider 2D组件会看到有一个Used By Composite选项它是自动被勾上的。加上Composite以后相邻瓦片的碰撞体合成一个整体物理系统的碰撞检测数量大幅下降。在包含大量瓦片的地图中这一步的性能提升通常是数量级的。更妙的是从地形上挖掉一块时复合碰撞体会自动重新生成不需要手动处理。3.6 导入Cinemachine摄像机跟随与地形边界约束有了地图之后玩家的摄像机不能随便乱走。这里推荐直接引入CinemachinePackage Manager里搜索安装创建2D Camera把目标绑定到角色。为了让摄像机不跑到地图外面给地形加一个Polygon Collider 2D作为边界这步要手动用Sprite或者专门建一个Edge Collider然后给Cinemachine Camera添加Cinemachine Confiner组件把Confiner Mode设为Confine 2D并把这个边界Collider赋给它。这一步解决的是Unity中非常常见的“摄像机跟随跑出地图”问题。如果你没有用Cinemachine而是用脚本写跟随也可以但需要自己做边界约束。Cinemachine的好处是已经处理了很多边界平滑和抖动细节尤其在2D游戏里它的丝滑程度比自己写的Update加Lerp要好。4. 规则瓦片让相邻地块自动匹配搭建效率大幅提升的关键用调色板手动画图对小型关卡完全够用。但如果你画的是草地边框、泥地、山体混在一起手动一格一格选择瓦片会累到怀疑人生。规则瓦片Rule Tile存在的意义就是处理这种场景你只需要用一种“笔”画Tile会根据周围格子的状态自动选出最合适的Sprite。4.1 简单讲讲规则瓦片的工作逻辑场景里的每个瓦片都有上下左右四个邻居也有些规则支持斜角判断。规则瓦片会针对每个可能的邻居状态组合指定一张Sprite或者指定一个规则。比如“如果左边和右边都有同类瓦片就显示中间地块”“如果左边有而右边没有就显示左边边缘地块”。当你不满足所有自定义规则时可以用“默认Sprite”来作为兜底。这种思路解决的是地形边缘的复杂匹配。手动画图时你眼睛看的是整块草地的轮廓和边界然后一块块挑对应的图块规则瓦片把这件事变成画出草地的主体边缘自动长出来。4.2 创建规则瓦片并配置规则在Project窗口右键 Create 2D Tiles Rule Tile创建规则瓦片资产。把瓦片资产拖入Tile Palette选中这个Rule Tile再点击调色板窗口左上角的“Edit Rule Tile”按钮不同Unity版本位置略有差异就会打开规则编辑界面。规则编辑器里是一个3x3网格中间一格代表“当前瓦片本身”。周围八格可以设置五种状态箭头图标表示“这个位置必须有一个同类瓦片”X图标表示“这个位置必须没有同类瓦片”问号表示“忽略这个位置”另外还有“要有但不要求同类”和“不能有且不要求非同类”的组合。通过组合这些状态你可以配置出草地边缘、转角、孤岛等全部情况。打个比方草地的“内部”规则是周围四格全部要有同类瓦片而草地“边缘”规则是左、右、上都有同类但下方没有就显示下缘的图块。把所有组合都填上草地上下左右边缘、四个转角就都齐了。4.3 规则瓦片的进阶玩法与动画瓦片除了Rule Tile2D Extras包里还提供了不少现成的瓦片类型比如Animated Tile动画瓦片和Random Tile随机瓦片。动画瓦片用于水面、熔岩这类动态地块它允许你把若干帧Sprite按顺序播放可以设置动画速度。随机瓦片则是在多个Sprite里随机挑选一个显示用来做草地多样性的细节非常合适。比如你在画草地时用随机瓦片有的地块带小花、有的带小石头视觉上就不会出现大面积同样的贴图看起来死板。随机瓦片和规则瓦片还可以组合使用一个规则瓦片匹配的是地形边缘但匹配到特定状态时可以引用一个随机瓦片。这个思路做出来的地形会非常自然。我实际做项目时通常会先建立一个“草地主体”规则瓦片再建立一个“草地边缘”规则瓦片两者通过规则关联到一起。画的时候只要把“草地主体”规则瓦片当作画笔往空白处抹边缘和转角全部自动生成。这种方法能让一个100格乘100格的地表在几分钟内完成且边界严丝合缝。4.4 规则瓦片配置时最容易犯的错最容易出错的地方是规则里外边缘状态没配全。常见的情况是画完之后发现转角处露底、上下边缘方向反了。翻车的根本原因是规则配置时只考虑了“相邻四格”而没考虑“对角”。比如草地出现一个孤岛需要同时匹配四个对角方向如果你没有为“四个对角都是草地、四边都是空地”这个组合指定Sprite瓦片就会变成默认Sprite或空白。解决办法只有一个在规则编辑器里把所有组合状态排一遍。不要嫌麻烦草地的边缘转角孤岛加起来通常不会超过16种组合。一次性配好整个项目受益。另外规则瓦片的Sprite需要在一张图集上否则不同图集之间的邻居匹配会导致合批断开严重的话会影响Draw Call。5. 碰撞、排序、摄像机把瓦片地图接入实际游戏场景地图画好只是第一步真正的考验是它进入物理、渲染、交互链路之后的表现。5.1 瓦片碰撞体的开销问题从十几个到几百个Collider做过大世界地图的人都有体会如果不做碰撞合并一个小关卡的地面就可能有几百个Collider。Unity的2D物理引擎在检测碰撞时每个Collider都需要参与BroadPhase计算。Collider数量一多哪怕物体静止物理线程的负担也会明显上升。解决办法我在3.5节已经提到就是Tilemap Collider 2D Composite Collider 2D的组合。这里有一个进阶问题如果只有部分瓦片需要碰撞怎么办最直接的方法是创建多个Tilemap一个用于纯视觉的地面层没有Tilemap Collider另一个用于碰撞层有碰撞组件。碰撞层里可以放那些碰撞体和地面视觉完全一致的瓦片也可以放一些不可见的“空气墙”瓦片只在碰撞层里存在。有一个细节值得提醒Composite Collider 2D的Geometry Type分为Outlines和Polygons。Outlines模式会把复合体生成一个外轮廓碰撞体适合实心地面物理效率更高Polygons模式会把内部区域也剖分成多个简单多边形。做平台跳跃关卡时建议用Outlines。但如果你有中空区域比如一个洞穴的入口Outlines可能会把洞口直接补上反而挡路。遇到这种情况可以把地面和洞口分到两个Tilemap分别处理碰撞。5.2 瓦片地图的阴影问题别让SpriteLit遮挡了所有光2D游戏一旦用了Universal RPURP的2D Light瓦片地图自身的渲染方式会影响光照效果。默认情况下TilemapRenderer使用的材质是Sprite-Lit-Default它本身是支持2D光照的。但有一类问题经常出现瓦片在光照下没有正确的法线导致阴影方向上表现得非常怪或者边缘的阴影硬得一塌糊涂。解决思路是修改瓦片Sprite的Custom Physics Shape。你在Sprite Editor里选择Custom Physics Shape可以为精灵画出逐像素或者逐形状的法线轮廓。瓦片碰撞体用的也是这个形状如果Collider Type是Sprite模式的话。注意这里的Physics Shape同时被光照系统和碰撞系统共用二合一其实很方便。改好Physics Shape后光照下的边缘过渡会自然很多不会再出现一个方块挡光挡成硬边的情况。另外如果你在项目里发现瓦片的阴影方向不受控制检查一下是否把瓦片放到了错误的Sorting Layer。2D光源的Normal Map影响的是材质光照计算不受Sorting Layer控制但阴影的投射和接收受SpriteRenderer的Cast Shadows配置影响。TilemapRenderer本身没有直接暴露Cast Shadows选项实际上是有的在URP项下TilemapRenderer的Additional Settings里有Shadow Casting Mode。记得把它设置为On或者 Shadows Only因为默认可能被关掉了。5.3 排序的边界很痛苦如何让角色合理地走进树后面2D游戏里Y轴排序角色根据Y坐标动态调整显示层级是个经典问题。Tilemap在地形层面用起来很顺手但涉及到动态遮挡时如果角色不想按Y轴动态改变Sorting Order而是想直接走到树后问题就来了。最简单的处理方案是不要把所有东西放在一个Tilemap层里。把门、树、屋顶这类需要压在角色上方的物件单独放到另一个Tilemap字符的动态排序只用在“地面层以上”的物体上。具体做法是给角色设置一个自定义的Sorting Order在Update里根据Y坐标来更新其Order in Layer值。地面Tilemap的Order值设一个基础值装饰Tilemap的Order设一个更高值角色Order在两者之间动态移动就会产生正确的遮挡效果。这里有一个常见坑角色的Order值不能和地面的Order值重叠否则会出现闪烁或者排序不稳定。建议要留出明显间隙比如地面是-100角色范围是-50到50装饰层是100。这样即便角色站在最下方Order也追不上装饰层。用一个大间隔数字做调节远比用0/1/2精确但混乱得多。5.4 运行时地图交互GetTile、HasTile 和 SetTile 的使用模式做建造游戏或Roguelike时运行时修改地图是刚需。基本思路是通过Tilemap的API在代码里读写格子数据。判断某个格子是否是特定地块用GetTile(new Vector3Int(x, y, 0))或HasTile。把地块换掉/放上去用SetTile(position, tile)。注意SetTile接收的是Vector3Int而你在场景里看到的世界坐标是Vector3。两者需要互相转换。Grid提供了WorldToCell和CellToWorld方法这是所有坐标换算的入口。每次调用SetTile都会触发一次Tilemap的重新生成和渲染更新。如果你在一个循环里改一两百个格子性能可能明显卡顿。原因是每次SetTile都可能让TilemapRenderer重新计算受影响网格块。对于需要频繁修改大量格子的场景比如爆炸炸掉一块地形应该先通过SetTiles或者SetTilesBlock批量修改再统一刷新。或者临时把Tilemap的CompressPaintingCanvas这类高级选项打开这个选项在运行时频繁修改时能显著减少内部数据结构的调整开销。很多教程会告诉你用GetTile拿瓦片再判断Tile资源名来识别地块类型。这个做法可以工作但性能一般。更好的方法是用Tilemap的自定义数据或者直接通过GetTilemapCollider2D的结果配合物理检测来判断空格和地块。识别具体是“哪种地块”时我习惯把Tile资产本身做成强引用数组索引用数字ID对应Tile资源而不是每次比较对象引用。6. 性能与几个高频坑为什么我的地形会闪、会裂、会乱最后这部分我准备把这些年踩过的坑集中复盘一下很多问题你在文档里根本搜不到只有项目做到特定阶段才会遇到。6.1 边缘裂缝图集Padding、Filter Mode和像素对齐瓦片边缘裂缝可以说是瓦片地图最高频的显示问题。表现是相邻地块之间有一条细缝或者边缘出现半透明的锯齿。根因通常有三个第一图集里各精灵贴图边缘像素不足导致采样时使用了相邻精灵的像素产生白色或透明边缘第二Filter Mode使用了Bilinear导致边缘像素被模糊后和旁边地块融合出错第三Pixel Per Unit和Cell Size没有精确对应造成半像素偏移。解决办法是图集切割时设置Padding至少4pxSprite导入时Filter Mode设为Point像素风或者保持Bilinear但确保图集边缘有透明区域Pixels Per Unit和Sprite实际像素尺寸严格一致。大多数2D游戏的美术资源在出图时就会处理这些但程序需要理解原因才能在不同项目中避免同样的坑。6.2 单元格数据和渲染更新不同步编辑器里改了运行时不显示老版本Unity里有一个高频坑代码里调用SetTile后Tilemap的渲染不一定立刻刷新。尤其在编辑器下调试时你可以在Inspector里看到数据变了但Scene视图看不到瓦片。这通常是因为Tilemap在运行时收到数据变化后渲染网格需要在下一次LateUpdate里重建。如果你的代码在LateUpdate之后才设置Tile那么真正的刷新还要再等一帧。更稳妥的做法是修改完一批瓦片之后调用Tilemap.RefreshAllTiles()或者Tilemap.RefreshTile(pos)手动触发刷新。这个方法本身开销不大但主动调用后编辑器里的显示通常能立刻同步。另外如果用了规则瓦片当周边地块发生变化时也需要主动刷新受影响的邻居规则的自动更新不会瞬间覆盖所有依赖区块。6.3 新地图块的动态合批问题想合批就别乱动TilemapRenderer默认是Chunk模式Chunk模式下绘制批次优化很好。但代价是瓦片每次增删都要重新生成网格块。这其实是一个典型的CPU vs GPU权衡。如果你在做运行时频繁破坏的地图比如“我的世界”风格合批块会不断重建性能上反而可能不如Cell模式或者不如把地图拆成多个小Tilemap再分块刷新。实际项目中我倾向于把“静态部分”和“动态部分”彻底分开。静态地面永远不修改给它一个独立的Tilemap用Chunk模式在初始化时烘焙好动态部分可破坏物、建造物用另一个Tilemap并设置适当的刷新策略。这样既能享受静态地图的低Draw Call又不会因为动态修改频繁触发全量重建。这个思路和你做导航网格烘焙时的动静分离逻辑非常像。6.4 地图加载速度与内存超大瓦片地图如何优化一张500x500的瓦片地图数据量其实很小每个格子只有几个字节的索引但渲染层和碰撞层的生成会占一定开销。碰到极大型地图时Unity官方建议采用分块加载或者按需生成。最直接的方式是代码控制可见范围——离摄像机太远的Tilemap直接SetActive(false)或者使用多个Tilemap块每个块负责一块区域按摄像机位置加载附近的块。内存方面Tile资源是ScriptableObject长时间不用的可以把引用释放但真正吃内存的是碰撞网格和渲染网格。如果你想降低内存占用可以关掉远处Tilemap的TilemapRenderer只保留碰撞如果需要的话。这个优化在其它的2D卷轴游戏中效果显著因为远处的地块已经不需要显示只保留碰撞数据就能支撑物理和检测。6.5 一个容易被忽略的顺序问题Grid和Tilemap的缩放如果你不小心在Grid上设置了Scale或者Rotation而不是只修改Grid组件里的Cell Size那整个世界坐标和网格坐标的映射就会错乱。很多初学者想调整地图大小直接改Grid的Scale结果瓦片全跑偏物理碰撞和渲染对不上。记住一条铁律Grid本身不要动Transform的Scale和Rotation参数全在Grid组件的Cell Size、Cell Gap和Cell Layout上设置。如果你确实需要整体缩放地图比如做像素完美缩放也应该通过Camera或Canvas来处理而不是网格系统。这个很容易踩踩过之后排查起来特别耗时因为场景里看起来一切正常但就是哪里不对。6.6 瓦片数据被误删、引用丢失怎么办Project窗口里如果你从图集生成的瓦片资产被误删场景里所有对应的地块会变成空白。这里有个好习惯瓦片资产和调色板文件都单独放到一个目录不要把瓦片资产和美术原图混在一起防止批量操作时误删。另外在预制体里保存的地图数据本质上保存的是Tile的引用GUID。GUID变了地图会大面积丢失。所以做大型项目时建议对瓦片资产建立命名规范避免美术工程重命名导致GUID丢失。如果你已经丢了引用又没有备份比较笨但有效的方法是打开Prefab文件或者场景文件搜索丢失的Tile GUID把新瓦片资产的GUID替换进去。这个方法应该只在实在没有办法时才用一般项目里还是靠版本管理工具找回更靠谱。最后的经验做了好几个2D项目之后我对TileMap这个系统最大的体会是它的学习曲线其实很平缓但真正用好它靠的不是看文档而是理解它的数据流和渲染模型。你用调色板画地图的本意是“画”但底层是“写数据”理解了这一点规则瓦片、动态修改、性能优化这些概念就是顺理成章的事情。如果你正打算做一个2D游戏不要怕花时间把瓦片图集和规则瓦片的基础整理好前期多花两个小时后面能省几十个小时的返工时间。 
长河君 · 2026/9/18 16:35:01 · 阅读 1.2k Unity TileMap 实战指南：从原理到性能优化，构建高效2D关卡
做2D游戏做到中期最让人头疼的往往不是玩法逻辑而是场景搭建。我最早做平台跳跃游戏时一张地图全靠手摆Sprite几百上千个碎块堆在Hierarchy里找东西靠翻改东西靠选调个墙体的位置要在一堆同名物体里辨认半天。最难受的是绘制批次和内存占用场景稍微大一点Profiler里Draw Call直接起飞。后来换了Unity TileMap整个关卡搭建方式才算理顺。这篇文章不打算给你念API文档而是把TileMap这套系统从概念、原理到实战说明白它到底怎么工作、应该怎么用以及在什么情况下它反而不合适。这篇文章适合两类人一类是刚开始学Unity、准备做2D游戏但还没有系统接触过瓦片地图的开发者另一类是已经用过TileMap但只停留在“拖个调色板往场景里画”的程度想搞清楚背后的数据结构和性能逻辑顺便解决几个常见坑的人。读完你至少能理解四件事TileMap为什么要挂在Grid下面、规则瓦片是怎么自动匹配邻居的、碰撞体该如何正确合并、以及运行时动态改格子应该注意什么。1. 从手动摆图到瓦片地图TileMap 到底解决了什么要理解TileMap先得回到一个最原始的问题为什么不能直接用Sprite把地图拼出来理论上完全可以。把一张张地块图片当作Sprite拖进场景用Transform摆好位置无非是工作量的问题。但这种做法在地图稍微复杂一点之后会呈现三个非常现实的问题。第一个是场景物体数量爆炸。假设你有做一个100x100格的地图用Sprite碎片摆放意味着场景里会出现一万个GameObject。每个GameObject都有Transform、SpriteRenderer即便内容一样Unity依然要把它们当作独立的实体来管理。Editor里卡顿是第一层运行时的管理开销是第二层而最明显的是在Profiler里能看到大量CPU时间花在C层级的节点管理上。第二个是绘制批次过高。SpriteRenderer默认按顺序渲染虽然Unity有动态合批但合批的前提是材质一致、贴图一致并且渲染顺序相邻。手动摆放的Sprite一旦穿插了碰撞体、粒子、UI等元素合批经常被打断。地图越大Draw Call越难压下去。第三个是编辑效率低下。改一格地块你得先找到那个Sprite物体再移动它的位置。如果某种地块要更换贴图需要批量替换还得担心漏掉某个角落。最恶心的是做地图迭代时整块区域重排几乎是噩梦。你甚至会想到写编辑器工具来批量摆放但写完又会发现工具只适合一次性操作不适合持续调整。TileMap解决这三个问题的思路其实是一次彻底的重构。它不再把每个地块当作一个独立的GameObject而是把整个地图抽象成一层二维网格数据。每个格子存储的是一个瓦片索引或者引用真正的瓦片资源也就是Tile是共享的。场景里你看到的是一块一块的地块数据结构里存的却只是一张大表。这样一来场景物体数量从“格子数”降到了“图层数”。一万个格子的地图在Hierarchy里只有几个Tilemap对象。绘制批次方面TilemapRenderer会尝试把同一张图集上的相邻瓦片合并成一个网格一次提交完成渲染。编辑效率更是质变你想改一整块区域框选、填充、橡皮擦几秒钟搞定还能配合规则瓦片让地块自动匹配边界。用一个不太严谨但很贴切的类比手动摆Sprite就像是用单独的砖块砌墙砖块之间没有联系拆一块是一块TileMap则像是给墙刷了一层电子表格你只需要维护“哪个位置是哪种砖”这个数据墙本身只是一个计算结果。但这里有一个关键的认知误区需要先纠正。很多初学者以为TileMap只是一个“画地图的工具”用了它画的图好看、方便。实际上TileMap是一套数据驱动的地图方案核心价值不在于“画”而在于“存”和“算”。你可以用代码动态生成地图也可以在地图运行时修改甚至可以把地图数据序列化到存档里。调色板只是编辑器层面的一个入口真正的核心是Tilemap组件上那张“表格”。理解到这一层你才能理解后面所有的设计取舍比如为什么要分多个Tilemap图层、为什么规则瓦片能自动匹配、为什么碰撞体要合并、为什么运行时改格子会触发重绘。2. 拆开看Grid、Tilemap、Tile、TilemapRenderer 各自的活儿很多新手创建TileMap时是直接右键 2D Object TilemapUnity自动生成了一套层级结构一个Grid父物体下面挂了Tilemap子物体。看起来很简单但如果你不知道这四个组件各自的职责后面遇到问题就会一头雾水。我见过不少人在Grid上瞎调Cell Size调完瓦片全部错位然后又不知道错在哪。2.1 Grid坐标基准与网格布局的提供者Grid是整个TileMap系统的坐标系基础。它不参与实际的地块渲染也不存储任何地图数据它的角色是回答一个问题“世界坐标里的这个点落在网格里的哪个格子”Grid有三个核心参数被高频使用Cell Size格子尺寸、Cell Gap格子间隙、Cell Layout网格布局。其中Cell Size经常被搞混。它和Sprite的Pixels Per Unit有直接换算关系。比如你的地块素材是32x32像素Sprite导入时PPU设为32那么一个格子对应的世界单位是1米Unity 2D里1单位通常是1米Cell Size就应该是(1, 1)。如果PPU是16同样是32像素的素材一个格子就是2米Cell Size要相应地改成(2, 2)。这里有个常见的做法是直接把Cell Size设为素材像素值除以PPU的结果这是对的只是容易漏掉像素对齐的问题后面专门说。Cell Layout则决定网格类型。绝大多数2D游戏用Rectangle矩形网格就行但如果你做的是斜45度视角的模拟经营类游戏需要选择Isometric等距网格如果你的地图是六边形战棋类游戏则要选Hexagonal六边形网格。网格类型一旦确定最好不要在项目中期修改因为瓦片坐标系统全变了已有的地图数据会错位。2.2 Tilemap那张真正的“表格”Tilemap就是那个存储二维数据的容器。表面上是网格里的一块块瓦片本质上是内部维护了一个类似字典的数据结构把网格坐标映射到Tile资源引用上。这个组件提供了非常丰富的读写API比如SetTile、GetTile、HasTile、ClearAllTiles、SwapTile等。这些API是你做运行时地图修改、建造破坏系统的入口。Tilemap还自带两个与碰撞相关的子组件TilemapCollider2D和TilemapCompositeCollider2D需要额外添加。前者的作用是根据瓦片自身的碰撞形状生成一个个独立的碰撞体后者的作用是把相邻的碰撞体合并成一个PolygonCollider2D。肉眼看起来差异不大但物理引擎处理一个大的复合碰撞体和处理几十上百个小碰撞体的开销完全是两个量级。后面我会专门展开讲。一个Tilemap对应一个图层所以做游戏时通常会建立多个Tilemap子物体比如地表层、墙壁层、装饰层、交互层。这样做的好处是不同图层可以有不同的排序、不同的碰撞设置还可以分别控制显隐。你只需要在处理逻辑时按层访问即可。2.3 Tile地图单元格的最小数据单元Tile本身是一个ScriptableObject资源文件。它把“显示哪张图”“碰撞形状是什么”“是否会影响导航”等属性打包在一起。这里的关键点是Tile是资源引用不是实例。一万个格子如果都引用同一个Tile内存里只会加载一份Tile数据一万个格子共享这一份引用。这就是TileMap内存开销远低于手动摆Sprite的根本原因之一。Tile上有个很容易被忽略的重要配置项叫做Collider Type。它有三种取值None、Sprite、Grid。None就是没有碰撞Sprite是根据精灵的自定义物理形状生成碰撞Grid则是把整个格子当作一个矩形碰撞。做平台跳跃游戏时平台地块通常用Sprite模式配合精灵图集里的Physics Shape可以做出边缘有弧度的地表碰撞。做整体地形时用Grid模式最简单粗暴。但无论选哪一种都建议配合Composite Collider使用否则瓦片多了碰撞体数量会非常夸张。2.4 TilemapRenderer决定怎么画出来这是真正干渲染活的组件。它有Mode属性分为Chunk和Cell两种。Chunk模式下Unity会把同一图集中的相邻瓦片合并成尽量少的网格块这是默认也是推荐模式对Draw Call最友好。Cell模式则是每个格子单独绘制几乎没有合批优势只在某些需要逐格控制的特殊场景下才会用到。TilemapRenderer还参与了排序。它跟你平时用的SpriteRenderer一样有Sorting Layer和Order in Layer。同一Tilemap对象下所有瓦片共享同一个排序层级所以做Y轴遮挡类的2D游戏时比如角色走到树后会挡住依赖排序层或Order in Layer是行不通的需要用分块Tilemap或者烘焙排序的方法来处理这个后面也会提。四个组件之间的关系可以这样理解Grid是尺子和坐标系Tilemap是数据表Tile是数据条目TilemapRenderer是把数据表画出来的画笔。你改Tilemap里的数据Renderer会去响应这个变化重新生成网格。如果你在运行时改了Tile但没有看到画面更新大概率是改错了对象或者没有调用需要的刷新接口后者在老版本Unity里是个高频坑。3. 动手搭一个 2D 瓦片关卡从创建 Tilemap 到调色板落地理论说了一堆现在实际操作一遍。我会带你把一个最基础的平台跳跃关卡地形跑通包含调色板创建、瓦片制作、绘制和分层。3.1 准备素材规范切割精灵图集很多人卡在这一步就出问题是因为精灵图集没有整理好。做瓦片素材时我建议遵循三条铁律所有地块素材放进同一张图集每块素材之间留足空白Padding至少4像素导入时Filter Mode设为Point。前两条影响是否合批和是否出现边缘出血第三条影响像素风游戏的清晰度。如果你做的是高清风格Filter Mode可以选Bilinear但边缘混血问题还是需要通过Sprite的Padding来解决细节后面坑点总结里说。以常见的16x16像素素材为例图集导入Unity后把Sprite Mode改为Multiple然后点击Sprite Editor把每一块切出来。切的时候要注意网格线要按像素准确对齐不要出现半像素的情况。切割完成后把Pixels Per Unit设置成16Mesh Type设为Full Rect如果不需要精确碰撞可以不设Sprite Physics Shape。3.2 创建Tilemap和调色板素材准备好后在Hierarchy面板里右键 2D Object Tilemap Rectangular。创建后层级结构是Grid下面挂着一个Tilemap。接着打开Tile Palette窗口Window 2D Tile Palette第一次打开会让你创建一个新的调色板。调色板本质上是一个文件夹里面放着可复用的瓦片资产。把切好的精灵直接拖进Tile Palette窗口Unity会自动为每张精灵生成对应的Tile资源。这里有个细节拖入精灵时Unity会询问是否同时创建瓦片资产。如果你的图集里有很多装饰性的单张Sprite比如花、石头它们不适合做成瓦片可以通过过滤器只选取需要的地块。也可以先批量创建然后在调色板里删除多余的。3.3 图层拆分地面层、墙壁层、装饰层接着创建两个以上的Tilemap。选中Grid右键 2D Object Tilemap再建一个。一个作为Ground碰撞层一个作为Wall也是碰撞层但排序更靠后还可以再建一个Detail纯装饰无碰撞。分层的意义在于碰撞和排序可以分开控制。Ground与Wall需要的碰撞体设置相同但装饰层的TilemapRenderer可以做单独的排序让角色从树后面经过时产生遮挡。这里要注意右手边的Tilemap Renderer组件的Sorting Layer设置。默认都在Default层靠Order in Layer区分。装饰层建议Order值比地表层高渲染时才会盖在上面。如果你有多个Sorting Layer也可以分配不同的SortingLayerName这个看项目需求。3.4 瓦片绘制用工具把草图画出来选中Ground这个Tilemap在Tile Palette里选择对应地块然后用画笔工具在Scene视图里绘制。几个常用的快捷键值得记住鼠标不选中场景物体时B是画笔D是橡皮擦G是填充油漆桶R是矩形选区。这里有个小技巧用油漆桶工具之前先选中你要填充的调色板瓦片然后按下G再点击场景中的封闭区域会自动填充整个连通区域。非常方便做地表草皮或者水面。绘制过程中如果发现瓦片对不齐网格检查一下Grid的Cell Size和Sprite的PPU是否匹配同时打开Scene视图右上角的Grid工具开关确保吸附开关打开。3.5 碰撞体加法和合并直接影响到物理性能选择Ground这个Tilemap对象Add Component添加Tilemap Collider 2D然后添加Tilemap Composite Collider 2D。关键操作来了添加Composite Collider 2D时Unity会提示你同时添加Rigidbody 2D并自动把Rigidbody 2D的Body Type设为Static。这个Rigidbody不是让你做物理模拟而是为了让Composite正常工作。如果你打开Tilemap Collider 2D组件会看到有一个Used By Composite选项它是自动被勾上的。加上Composite以后相邻瓦片的碰撞体合成一个整体物理系统的碰撞检测数量大幅下降。在包含大量瓦片的地图中这一步的性能提升通常是数量级的。更妙的是从地形上挖掉一块时复合碰撞体会自动重新生成不需要手动处理。3.6 导入Cinemachine摄像机跟随与地形边界约束有了地图之后玩家的摄像机不能随便乱走。这里推荐直接引入CinemachinePackage Manager里搜索安装创建2D Camera把目标绑定到角色。为了让摄像机不跑到地图外面给地形加一个Polygon Collider 2D作为边界这步要手动用Sprite或者专门建一个Edge Collider然后给Cinemachine Camera添加Cinemachine Confiner组件把Confiner Mode设为Confine 2D并把这个边界Collider赋给它。这一步解决的是Unity中非常常见的“摄像机跟随跑出地图”问题。如果你没有用Cinemachine而是用脚本写跟随也可以但需要自己做边界约束。Cinemachine的好处是已经处理了很多边界平滑和抖动细节尤其在2D游戏里它的丝滑程度比自己写的Update加Lerp要好。4. 规则瓦片让相邻地块自动匹配搭建效率大幅提升的关键用调色板手动画图对小型关卡完全够用。但如果你画的是草地边框、泥地、山体混在一起手动一格一格选择瓦片会累到怀疑人生。规则瓦片Rule Tile存在的意义就是处理这种场景你只需要用一种“笔”画Tile会根据周围格子的状态自动选出最合适的Sprite。4.1 简单讲讲规则瓦片的工作逻辑场景里的每个瓦片都有上下左右四个邻居也有些规则支持斜角判断。规则瓦片会针对每个可能的邻居状态组合指定一张Sprite或者指定一个规则。比如“如果左边和右边都有同类瓦片就显示中间地块”“如果左边有而右边没有就显示左边边缘地块”。当你不满足所有自定义规则时可以用“默认Sprite”来作为兜底。这种思路解决的是地形边缘的复杂匹配。手动画图时你眼睛看的是整块草地的轮廓和边界然后一块块挑对应的图块规则瓦片把这件事变成画出草地的主体边缘自动长出来。4.2 创建规则瓦片并配置规则在Project窗口右键 Create 2D Tiles Rule Tile创建规则瓦片资产。把瓦片资产拖入Tile Palette选中这个Rule Tile再点击调色板窗口左上角的“Edit Rule Tile”按钮不同Unity版本位置略有差异就会打开规则编辑界面。规则编辑器里是一个3x3网格中间一格代表“当前瓦片本身”。周围八格可以设置五种状态箭头图标表示“这个位置必须有一个同类瓦片”X图标表示“这个位置必须没有同类瓦片”问号表示“忽略这个位置”另外还有“要有但不要求同类”和“不能有且不要求非同类”的组合。通过组合这些状态你可以配置出草地边缘、转角、孤岛等全部情况。打个比方草地的“内部”规则是周围四格全部要有同类瓦片而草地“边缘”规则是左、右、上都有同类但下方没有就显示下缘的图块。把所有组合都填上草地上下左右边缘、四个转角就都齐了。4.3 规则瓦片的进阶玩法与动画瓦片除了Rule Tile2D Extras包里还提供了不少现成的瓦片类型比如Animated Tile动画瓦片和Random Tile随机瓦片。动画瓦片用于水面、熔岩这类动态地块它允许你把若干帧Sprite按顺序播放可以设置动画速度。随机瓦片则是在多个Sprite里随机挑选一个显示用来做草地多样性的细节非常合适。比如你在画草地时用随机瓦片有的地块带小花、有的带小石头视觉上就不会出现大面积同样的贴图看起来死板。随机瓦片和规则瓦片还可以组合使用一个规则瓦片匹配的是地形边缘但匹配到特定状态时可以引用一个随机瓦片。这个思路做出来的地形会非常自然。我实际做项目时通常会先建立一个“草地主体”规则瓦片再建立一个“草地边缘”规则瓦片两者通过规则关联到一起。画的时候只要把“草地主体”规则瓦片当作画笔往空白处抹边缘和转角全部自动生成。这种方法能让一个100格乘100格的地表在几分钟内完成且边界严丝合缝。4.4 规则瓦片配置时最容易犯的错最容易出错的地方是规则里外边缘状态没配全。常见的情况是画完之后发现转角处露底、上下边缘方向反了。翻车的根本原因是规则配置时只考虑了“相邻四格”而没考虑“对角”。比如草地出现一个孤岛需要同时匹配四个对角方向如果你没有为“四个对角都是草地、四边都是空地”这个组合指定Sprite瓦片就会变成默认Sprite或空白。解决办法只有一个在规则编辑器里把所有组合状态排一遍。不要嫌麻烦草地的边缘转角孤岛加起来通常不会超过16种组合。一次性配好整个项目受益。另外规则瓦片的Sprite需要在一张图集上否则不同图集之间的邻居匹配会导致合批断开严重的话会影响Draw Call。5. 碰撞、排序、摄像机把瓦片地图接入实际游戏场景地图画好只是第一步真正的考验是它进入物理、渲染、交互链路之后的表现。5.1 瓦片碰撞体的开销问题从十几个到几百个Collider做过大世界地图的人都有体会如果不做碰撞合并一个小关卡的地面就可能有几百个Collider。Unity的2D物理引擎在检测碰撞时每个Collider都需要参与BroadPhase计算。Collider数量一多哪怕物体静止物理线程的负担也会明显上升。解决办法我在3.5节已经提到就是Tilemap Collider 2D Composite Collider 2D的组合。这里有一个进阶问题如果只有部分瓦片需要碰撞怎么办最直接的方法是创建多个Tilemap一个用于纯视觉的地面层没有Tilemap Collider另一个用于碰撞层有碰撞组件。碰撞层里可以放那些碰撞体和地面视觉完全一致的瓦片也可以放一些不可见的“空气墙”瓦片只在碰撞层里存在。有一个细节值得提醒Composite Collider 2D的Geometry Type分为Outlines和Polygons。Outlines模式会把复合体生成一个外轮廓碰撞体适合实心地面物理效率更高Polygons模式会把内部区域也剖分成多个简单多边形。做平台跳跃关卡时建议用Outlines。但如果你有中空区域比如一个洞穴的入口Outlines可能会把洞口直接补上反而挡路。遇到这种情况可以把地面和洞口分到两个Tilemap分别处理碰撞。5.2 瓦片地图的阴影问题别让SpriteLit遮挡了所有光2D游戏一旦用了Universal RPURP的2D Light瓦片地图自身的渲染方式会影响光照效果。默认情况下TilemapRenderer使用的材质是Sprite-Lit-Default它本身是支持2D光照的。但有一类问题经常出现瓦片在光照下没有正确的法线导致阴影方向上表现得非常怪或者边缘的阴影硬得一塌糊涂。解决思路是修改瓦片Sprite的Custom Physics Shape。你在Sprite Editor里选择Custom Physics Shape可以为精灵画出逐像素或者逐形状的法线轮廓。瓦片碰撞体用的也是这个形状如果Collider Type是Sprite模式的话。注意这里的Physics Shape同时被光照系统和碰撞系统共用二合一其实很方便。改好Physics Shape后光照下的边缘过渡会自然很多不会再出现一个方块挡光挡成硬边的情况。另外如果你在项目里发现瓦片的阴影方向不受控制检查一下是否把瓦片放到了错误的Sorting Layer。2D光源的Normal Map影响的是材质光照计算不受Sorting Layer控制但阴影的投射和接收受SpriteRenderer的Cast Shadows配置影响。TilemapRenderer本身没有直接暴露Cast Shadows选项实际上是有的在URP项下TilemapRenderer的Additional Settings里有Shadow Casting Mode。记得把它设置为On或者 Shadows Only因为默认可能被关掉了。5.3 排序的边界很痛苦如何让角色合理地走进树后面2D游戏里Y轴排序角色根据Y坐标动态调整显示层级是个经典问题。Tilemap在地形层面用起来很顺手但涉及到动态遮挡时如果角色不想按Y轴动态改变Sorting Order而是想直接走到树后问题就来了。最简单的处理方案是不要把所有东西放在一个Tilemap层里。把门、树、屋顶这类需要压在角色上方的物件单独放到另一个Tilemap字符的动态排序只用在“地面层以上”的物体上。具体做法是给角色设置一个自定义的Sorting Order在Update里根据Y坐标来更新其Order in Layer值。地面Tilemap的Order值设一个基础值装饰Tilemap的Order设一个更高值角色Order在两者之间动态移动就会产生正确的遮挡效果。这里有一个常见坑角色的Order值不能和地面的Order值重叠否则会出现闪烁或者排序不稳定。建议要留出明显间隙比如地面是-100角色范围是-50到50装饰层是100。这样即便角色站在最下方Order也追不上装饰层。用一个大间隔数字做调节远比用0/1/2精确但混乱得多。5.4 运行时地图交互GetTile、HasTile 和 SetTile 的使用模式做建造游戏或Roguelike时运行时修改地图是刚需。基本思路是通过Tilemap的API在代码里读写格子数据。判断某个格子是否是特定地块用GetTile(new Vector3Int(x, y, 0))或HasTile。把地块换掉/放上去用SetTile(position, tile)。注意SetTile接收的是Vector3Int而你在场景里看到的世界坐标是Vector3。两者需要互相转换。Grid提供了WorldToCell和CellToWorld方法这是所有坐标换算的入口。每次调用SetTile都会触发一次Tilemap的重新生成和渲染更新。如果你在一个循环里改一两百个格子性能可能明显卡顿。原因是每次SetTile都可能让TilemapRenderer重新计算受影响网格块。对于需要频繁修改大量格子的场景比如爆炸炸掉一块地形应该先通过SetTiles或者SetTilesBlock批量修改再统一刷新。或者临时把Tilemap的CompressPaintingCanvas这类高级选项打开这个选项在运行时频繁修改时能显著减少内部数据结构的调整开销。很多教程会告诉你用GetTile拿瓦片再判断Tile资源名来识别地块类型。这个做法可以工作但性能一般。更好的方法是用Tilemap的自定义数据或者直接通过GetTilemapCollider2D的结果配合物理检测来判断空格和地块。识别具体是“哪种地块”时我习惯把Tile资产本身做成强引用数组索引用数字ID对应Tile资源而不是每次比较对象引用。6. 性能与几个高频坑为什么我的地形会闪、会裂、会乱最后这部分我准备把这些年踩过的坑集中复盘一下很多问题你在文档里根本搜不到只有项目做到特定阶段才会遇到。6.1 边缘裂缝图集Padding、Filter Mode和像素对齐瓦片边缘裂缝可以说是瓦片地图最高频的显示问题。表现是相邻地块之间有一条细缝或者边缘出现半透明的锯齿。根因通常有三个第一图集里各精灵贴图边缘像素不足导致采样时使用了相邻精灵的像素产生白色或透明边缘第二Filter Mode使用了Bilinear导致边缘像素被模糊后和旁边地块融合出错第三Pixel Per Unit和Cell Size没有精确对应造成半像素偏移。解决办法是图集切割时设置Padding至少4pxSprite导入时Filter Mode设为Point像素风或者保持Bilinear但确保图集边缘有透明区域Pixels Per Unit和Sprite实际像素尺寸严格一致。大多数2D游戏的美术资源在出图时就会处理这些但程序需要理解原因才能在不同项目中避免同样的坑。6.2 单元格数据和渲染更新不同步编辑器里改了运行时不显示老版本Unity里有一个高频坑代码里调用SetTile后Tilemap的渲染不一定立刻刷新。尤其在编辑器下调试时你可以在Inspector里看到数据变了但Scene视图看不到瓦片。这通常是因为Tilemap在运行时收到数据变化后渲染网格需要在下一次LateUpdate里重建。如果你的代码在LateUpdate之后才设置Tile那么真正的刷新还要再等一帧。更稳妥的做法是修改完一批瓦片之后调用Tilemap.RefreshAllTiles()或者Tilemap.RefreshTile(pos)手动触发刷新。这个方法本身开销不大但主动调用后编辑器里的显示通常能立刻同步。另外如果用了规则瓦片当周边地块发生变化时也需要主动刷新受影响的邻居规则的自动更新不会瞬间覆盖所有依赖区块。6.3 新地图块的动态合批问题想合批就别乱动TilemapRenderer默认是Chunk模式Chunk模式下绘制批次优化很好。但代价是瓦片每次增删都要重新生成网格块。这其实是一个典型的CPU vs GPU权衡。如果你在做运行时频繁破坏的地图比如“我的世界”风格合批块会不断重建性能上反而可能不如Cell模式或者不如把地图拆成多个小Tilemap再分块刷新。实际项目中我倾向于把“静态部分”和“动态部分”彻底分开。静态地面永远不修改给它一个独立的Tilemap用Chunk模式在初始化时烘焙好动态部分可破坏物、建造物用另一个Tilemap并设置适当的刷新策略。这样既能享受静态地图的低Draw Call又不会因为动态修改频繁触发全量重建。这个思路和你做导航网格烘焙时的动静分离逻辑非常像。6.4 地图加载速度与内存超大瓦片地图如何优化一张500x500的瓦片地图数据量其实很小每个格子只有几个字节的索引但渲染层和碰撞层的生成会占一定开销。碰到极大型地图时Unity官方建议采用分块加载或者按需生成。最直接的方式是代码控制可见范围——离摄像机太远的Tilemap直接SetActive(false)或者使用多个Tilemap块每个块负责一块区域按摄像机位置加载附近的块。内存方面Tile资源是ScriptableObject长时间不用的可以把引用释放但真正吃内存的是碰撞网格和渲染网格。如果你想降低内存占用可以关掉远处Tilemap的TilemapRenderer只保留碰撞如果需要的话。这个优化在其它的2D卷轴游戏中效果显著因为远处的地块已经不需要显示只保留碰撞数据就能支撑物理和检测。6.5 一个容易被忽略的顺序问题Grid和Tilemap的缩放如果你不小心在Grid上设置了Scale或者Rotation而不是只修改Grid组件里的Cell Size那整个世界坐标和网格坐标的映射就会错乱。很多初学者想调整地图大小直接改Grid的Scale结果瓦片全跑偏物理碰撞和渲染对不上。记住一条铁律Grid本身不要动Transform的Scale和Rotation参数全在Grid组件的Cell Size、Cell Gap和Cell Layout上设置。如果你确实需要整体缩放地图比如做像素完美缩放也应该通过Camera或Canvas来处理而不是网格系统。这个很容易踩踩过之后排查起来特别耗时因为场景里看起来一切正常但就是哪里不对。6.6 瓦片数据被误删、引用丢失怎么办Project窗口里如果你从图集生成的瓦片资产被误删场景里所有对应的地块会变成空白。这里有个好习惯瓦片资产和调色板文件都单独放到一个目录不要把瓦片资产和美术原图混在一起防止批量操作时误删。另外在预制体里保存的地图数据本质上保存的是Tile的引用GUID。GUID变了地图会大面积丢失。所以做大型项目时建议对瓦片资产建立命名规范避免美术工程重命名导致GUID丢失。如果你已经丢了引用又没有备份比较笨但有效的方法是打开Prefab文件或者场景文件搜索丢失的Tile GUID把新瓦片资产的GUID替换进去。这个方法应该只在实在没有办法时才用一般项目里还是靠版本管理工具找回更靠谱。最后的经验做了好几个2D项目之后我对TileMap这个系统最大的体会是它的学习曲线其实很平缓但真正用好它靠的不是看文档而是理解它的数据流和渲染模型。你用调色板画地图的本意是“画”但底层是“写数据”理解了这一点规则瓦片、动态修改、性能优化这些概念就是顺理成章的事情。如果你正打算做一个2D游戏不要怕花时间把瓦片图集和规则瓦片的基础整理好前期多花两个小时后面能省几十个小时的返工时间。