企业官网建设流程全解析

我最早做2D项目的时候，地图还是用最原始的方式拼的：把一张张地面图片拖进场景，然后手动对齐坐标。当时项目小，感觉还行，直到有一次需要铺一块50×30的地面，场景里多了两千多个Sprite物体，编辑器开始卡顿，保存场景要等半天，策划想改个布局更是噩梦。后来我把这套代码全部推倒，换成了基于格子的平铺网格地图方案，也就是Unity的Tilemap，从那以后做2D地图的效率才算真正上了轨道。这篇文章就是把我这几轮折腾下来的经验整理一遍，从底层原理到实际操作，再到我踩过的坑，一点一点说清楚。

1. 手动摆Sprite的痛点：为什么最终换成了Tilemap

1.1 手动摆放看起来简单，后续成本高得吓人

很多初学者第一次做地图，下意识的做法就是往场景里拖图片。一张草地的Sprite，复制几份，拖到对应位置，看起来也像那么回事。但问题是，这种方案只适合几十个格子的演示级场景。

一旦地图规模上去，麻烦接踵而至。首先是场景文件体积急剧膨胀，每个Sprite都是一个GameObject，每个GameObject都有自己的Transform、SpriteRenderer，这些数据全部要序列化进场景文件。其次是编辑器性能，成千上万个物体堆在Hierarchy里，每次选中、移动都要遍历，操作起来明显卡顿。更麻烦的是重构成本——假如地面要整体往右挪三个格子，你得全选然后手动改坐标；假如要改地面纹理，几百个Sprite逐个换图，光是想想就头疼。

我自己遇到的最崩溃一次，是给一个模拟项目加点围墙逻辑。本来只要知道某个格子有没有墙就行，结果因为所有墙体都是独立Sprite对象，我只能遍历场景里所有带特定标签的物体去判断，又慢又脆弱。

1.2 Tilemap真正解决了哪几个问题

Tilemap这套方案的核心思路，是把"地图里的每一格"当作数据而不是物体。整个地图是一个二维数组，每个格子存一个瓦片（Tile）的引用。这样做的好处非常直接：

• 场景里只有一个Tilemap对象，几千个格子不会产生几千个GameObject，层次结构极度清爽。
• 绘制地图靠调色板笔刷，点一下刷一片，不需要手工对齐坐标，天然贴合网格。
• 逻辑判断可以精确到格子，用代码的WorldToCell就能知道某一点落在哪个格子，很方便做寻路、放置、消除之类功能。
• 瓦片资源本身是共享的，同一种草地瓦片无论刷多少格，底层数据都是引用，不会重复存储图片。

这个取舍的本质，是把一张地图从"物体的集合"变成了"数据的视图"。游戏运行时，Tilemap Renderer负责把数据渲染出来，开发者操作的是数据本身。理解了这个定位，后面很多功能设计就容易想通。

1.3 不是所有项目都适合Tilemap

分配一下应用场景。如果游戏是自由放置、随意旋转、物体大小不一的那种，比如装饰类玩法，那直接用普通Sprite反而灵活。Tilemap强在规则整齐、格子横平竖直的场合，典型的就是2D像素风的地图、回合制棋盘、消除游戏、塔防地图、模拟经营的地块。

如果你的游戏需要六边形格子或者斜45度视角，Tilemap也可以支持，Grid组件里能切换Cell Layout为Hexagon或者Isometric。但这类项目上手复杂度会高一些，建议先把矩形网格玩熟再说。

2. 网格地图的底层骨架：Grid、Tilemap与瓦片资产的分工

2.1 Grid：地图坐标系的定海神针

Unity的平铺网格地图由三个核心角色组成，很多人分不清它们的区别，其实用生活中的例子类比就很好理解。

Grid就像一张坐标纸。它定义了单元格的大小、形状（矩形、六边形、斜角），以及世界坐标和格子坐标之间的换算规则。它的作用纯粹是空间上的，不负责存任何地图内容。

新建Tilemap时，Unity会自动创建一个父物体Grid，下面挂Tilemap子物体。Grid组件上的Cell Size决定了每个格子的世界尺寸。默认是(1, 1, 0)，也就是一个格子占一个单位的世界坐标。如果你的瓦片是16×16像素，而项目里Pixels Per Unit设的16，那一个瓦片就恰好占一个格子。

Grid本身有几种布局模式，矩形（Rectangle）是最常用的，适合绝大多数2D项目。六边形（Hexagon）和等距（Isometric）适合特殊视角游戏，它们还分成Pointed Top、Flat Top、Y Axis等细分选项。初学阶段不用碰这些，直接用Rectangle即可。

2.2 Tilemap：真正存格子数据的容器

Tilemap是贴着Grid的一块画布，它内部维护着一个以Vector3Int为键的字典，每个格子坐标对应一个瓦片资源引用。你在调色板里刷上去的那个"瓦片"，本质上就是往这个字典里写了一条记录。

Tilemap身上的组件也有讲究。TilemapRenderer负责渲染，TilemapCollider2D负责生成碰撞体。还有TilemapAnimation等等，是按需添加的。

关键要理解的是，Tilemap本身不直接操作GameObject，它把大量瓦片在渲染层做了合并处理。所以哪怕地图上有一万个格子，生成的绘制命令通常也是少量的大块网格，而不是一万个精灵的绘制调用。这也是Tilemap性能好的根本原因。

2.3 Tile Asset：瓦片到底是什么

瓦片（Tile Asset）是一份可复用的资源文件，它保存在Project面板里，用来描述"怎么把一张图片画到一个格子上"。

一个Tile Asset的核心配置包括：

最常见的做法是给每种地形建一个Tile Asset，所有地面瓦片都引用同一张路面图，但它们的Collider Type、颜色等可以不同。比如普通地面设为None，墙壁设为Grid，这样碰撞问题跟着瓦片走，不用额外摆放碰撞体。

Grid的Collider Type为Grid时，碰撞体会按格子形状生成；为Sprite时，则按Sprite的实际轮廓生成，适合不规则的障碍物瓦片。

理解了这三层关系之后，再去操作Unity的Tilemap功能，心里就有一根线了：Grid管坐标系，Tilemap管数据，Tile Asset管资源。剩下的调色板、笔刷、规则瓦片，都是操作这三者的工具。

3. 纹理导入与像素单位：这一步错了后面全歪

3.1 Pixels Per Unit与Cell Size必须对账

很多新手照着教程做，结果刷出来的瓦片要么过大、要么过小，或者相互重叠、出现缝隙，问题基本都出在纹理导入的Pixels Per Unit（PPU）和Grid的Cell Size没有对好。

PPU的含义是：这张图里的多少个像素，对应世界坐标里的1个单位。如果一张瓦片是16×16像素，PPU设为16，那它在世界坐标里就是1×1单位，正好填满默认大小的一个格子。

这里容易出现的情况是，美术给的瓦片是32×32像素，但PPU保持默认的100不变。结果一个瓦片在世界坐标里只有0.32×0.32单位，刷出来的格子明显比Grid的格子小，边缘露出一圈空隙。

我的建议是，确定一套统一标准后就别再改。比较省事的方式：如果你的瓦片是16×16像素，PPU设16；如果是32×32像素，PPU设32。然后Grid的Cell Size保持(1, 1, 0)。如果美术素材尺寸不统一，宁可先统一素材，也不要在PPU上做奇怪的口算，否则后面每个瓦片都要单独调，非常痛苦。

3.2 锚点选择直接影响对齐效果

纹理导入的Sprite Editor里有一个Pivot选项，很多人忽略它。对于平铺地图的瓦片，锚点选择很关键。

地面、墙壁这类瓦片，我建议锚点放在Bottom（底部中心），或者在Sprite Editor里手动把枢轴点设置在左下角。原因很简单，瓦片拼地图的时候，我们通常希望它的下边缘对齐格子边界，这样高度不同的地形叠在一起不会因为中心对齐而产生上浮或下沉的视觉偏差。

如果你用的是Center锚点，刷出来的瓦片会以格子中心为基准，看起来也还行，一旦混入不同高度的装饰瓦片，就会出现"种下去的树浮在空中"的现象。因为树的图片比格子高很多，中心对齐时它的底部就悬空了。

所以在做瓦片导入的时候，我的固定流程是：先选中全部瓦片素材，批量把Sprite Mode切为Multiple，然后进Sprite Editor切片，顺手把所有切片的Pivot都改成Bottom。

3.3 Filter Mode与压缩方式的细节

像素风瓦片还有一个坑：Filter Mode默认是Bilinear（双线性过滤），会让像素边缘变模糊，放大时出现一圈半透明的过渡。像素游戏本来就追求那种颗粒分明的质感，被这么一糊，画面就失去味道了。

正确做法是把Filter Mode改为Point (no filter)，让每个像素保持清晰锐利。压缩格式同样值得注意，如果项目跑在移动端，默认的压缩格式可能会让像素边缘产生奇怪的颜色溢出。对于像素风瓦片，我一般把Compression设为None。

这些设置如果逐个手动改很烦，而且容易遗漏。我的做法是把纹理放到固定的目录，例如Assets/Art/Tiles，然后提前写好一个编辑器脚本，在OnPostprocessAllAssets里对指定目录自动应用导入设置。这样以后拖任何新瓦片进来，都不用再手动操作一遍。

4. 从瓦片资产到调色板：真正开始"画地图"

4.1 创建瓦片资产的两种姿势

瓦片资产有两种创建方式，一种是在Project面板右键，Create > Tile，然后把Sprite拖进去；另一种是打开Tile Palette窗口，勾选Create New Palette之后，直接从图集里拖图片，Unity会自动帮你创建Tile Asset。

我更推荐后者。因为调色板会顺带把一个Tile资产组织成可管理的结构，后面刷地图的时候直接在调色板面板里选，不用频繁去Project面板翻找。

如果瓦片数量很多，手动创建Tile资产仍然很费劲。这时候可以通过代码批量生成。思路是在编辑器模式下遍历所有Sprite，为每个Sprite创建一个Tile Asset，并设置它的Sprite引用和碰撞类型。代码很简单：

using UnityEditor; using UnityEngine; using UnityEngine.Tilemaps; public static class TileAssetGenerator { [MenuItem("Tools/Generate Tile Assets From Sprites")] public static void Generate() { string folder = "Assets/Art/Tiles"; string[] guids = AssetDatabase.FindAssets("t:Sprite", new[] { folder }); foreach (string guid in guids) { string path = AssetDatabase.GUIDToAssetPath(guid); Sprite sprite = AssetDatabase.LoadAssetAtPath<Sprite>(path); if (sprite == null) continue; Tile tile = ScriptableObject.CreateInstance<Tile>(); tile.sprite = sprite; tile.colliderType = Tile.ColliderType.None; string tilePath = path.Replace(".png", ".asset").Replace(".jpg", ".asset"); AssetDatabase.CreateAsset(tile, tilePath); } AssetDatabase.SaveAssets(); } }

这个脚本的好处是一次性把所有瓦片变成Tile资产，节省大量手工操作时间。注意目录路径要按你的实际项目结构调整。

4.2 Tile Palette：刷子、橡皮和填充工具

Tile Palette是一个独立窗口，通过Window > 2D > Tile Palette打开。首次打开会提示创建新调色板，给调色板起个名，比如WorldTiles，Unity会自动建一个同名文件夹来存放瓦片资产。

把Tile资产拖进调色板窗口，就会看到一个个小格子，这就是你的"颜料盘"。刷地图时，选中调色板里的瓦片，选择合适的笔刷工具，再在Scene视图里往Tilemap上刷即可。

调色板自带笔刷有几个：

• 画笔（Paint）：单击或拖拽刷瓦片
• 橡皮（Eraser）：擦除格子
• 填充（Fill）：把一个封闭区域整体填满，适合快速铺大片地面
• 选择（Select）：选中一块区域后可以框选、拖动、复制

我实际最常用的组合是：先拿Fill快速铺整块草地，再用Paint刷出道路和墙体，最后用橡皮修细节。整个绘图过程就像在用画图软件，效率比拖Sprite高了不知道多少倍。

4.3 一个完整的地图搭建演示流程

以一个简单的小场景为例，跑一遍完整流程。

我假设有一张三合一的图集，包含草地、泥土、石块三种素材。第一步，新建一个场景，创建Grid和Tilemap，命名Tilemap_Ground。第二步，把图集导入，把纹理类型设为Sprite (2D and UI)，Sprite Mode设为Multiple，切片后确认所有切片Pivot为Bottom。第三步，打开Tile Palette，新建调色板，把切片好的三种素材拖进去，让Unity生成对应的Tile资产。第四步，切换到画笔工具，选中草地瓦片，在Grid覆盖的区域内拖拽，先刷出大概轮廓；再换泥土瓦片，刷出道路；最后用石块瓦片点缀边缘，随手擦掉几个多余的格子。

整个过程十分钟左右，一张像样的地图就出来了。如果全程手动摆Sprite，光对齐坐标就得折腾半个多小时，而且后面改起来更麻烦。

5. 规则瓦片自动连接：一刷子刷出一整片地形

5.1 规则瓦片的出现动机

平铺地图有一个绕不开的痛：地形的边缘过渡。比如一块草地周围挨着泥土，你会希望草地的边缘有一圈自然的"过渡瓦片"，和泥土平滑衔接。如果全靠手工一格格去挑，工作量瞬间翻倍，而且很容易漏。

Unity 2D Tilemap Extras里的Rule Tile（规则瓦片）专门解决这个问题。它的原理是：让瓦片自己记录"在什么邻居条件下显示什么Sprite"。刷的时候你只需要刷一种核心瓦片，周围的过渡瓦片由规则自动补上。

5.2 规则配置：3×3矩阵与匹配优先级

Rule Tile的配置面板里有一个3×3的九宫格矩阵，中心那一格代表瓦片自身，周围八格表示八个邻居方向。每个格子可以设置三种状态：

• 绿色（满足）：这个方向的邻居必须是同类瓦片
• 红色（不满足）：这个方向的邻居必须不是同类瓦片
• 灰色（忽略）：不管这个方向是什么，都不影响匹配

每一个规则可以指定对应的Sprite。多个规则从上到下排列，Unity会从上往下逐个尝试，第一个匹配成功的规则生效。

做草地边缘的时候，我通常给每个方向都建一条规则。例如：

配置规则时要格外注意优先级顺序。通用规则要放在具体规则下面，否则会被提前匹配掉。我一开始就是把"上方有草地"的规则放在了通用规则后面，结果所有位置都匹配了通用规则，边缘效果完全没出来。

5.3 规则瓦片的常见陷阱

规则瓦片有一个容易踩的坑：它要求"同类瓦片"必须是同一个Tile资产。如果地图上既有普通草地瓦片，又有规则草地瓦片，它们不会被识别为同类，规则就会失效。所以要么全部用规则瓦片，要么保证邻居瓦片引用的是同一个资产。

另一个问题是性能边界。规则瓦片在编辑时会实时计算邻居关系，格子数量特别大的区域会有些卡顿。通常项目里几千个格子的地图影响不大，但如果你用代码在运行时批量创建大量规则瓦片，就要注意计算量了。

Unity还提供了加了Random参数的规则变体，可以在匹配到同一条件时随机显示多个Sprite之一。这个功能我经常用来铺大片的绿地，让草地有一些随机的深浅变化，看起来自然很多。

6. 碰撞、层级与遮挡：让地图真正"可玩"

6.1 从无碰撞到复合碰撞体

地形画好了，接下来是碰撞。Tilemap Collider 2D可以自动根据瓦片的Collider Type生成碰撞体，开启之后，所有Collider Type为Grid或Sprite的瓦片都会生成对应的碰撞形状。但有个很现实的性能问题：每个格子的瓦片碰撞体都是独立的Shape，如果地图有一千个墙体格子，就会生成一千多个碰撞体形状，物理计算量扛不住。

解决方案是TilemapCollider2D加Composite Collider 2D的组合。在TilemapCollider2D上勾选Used By Composite，然后给Tilemap物体加一个Composite Collider 2D，所有瓦片碰撞体会被合并成一个复合碰撞体。对静态地形来说，这是最理想的方案，物理引擎只用处理一张大网格。

碰撞方案对比：

如果你的地图有会动的机关、可破坏的墙壁，那就不能把所有东西塞进一个Composite里，复合碰撞体会把它们焊死成一体。这种情况下我的建议是：静态地形用Composite，动态物体单独用碰撞体，两者分层管理。

6.2 Y轴排序：角色走到树后面会被遮挡

2D游戏中"角色被高物遮挡"的效果，在很多新手项目里做不出来。原因在于Sprite Renderer的渲染顺序默认按Sorting Order和层来决定，而不是按世界Y坐标。

要实现遮挡，需要把渲染顺序改为按物体Y坐标排序。在Project Settings > Graphics的Camera Settings里，把Transparency Sort Axis改为(0, 1, 0)，这样Unity会按照物体在世界空间中的Y轴位置来决定谁在前面。角色站在树的下方，也就是Y坐标更小，就被判定为在树的前面；往上走就自然走到树后面被遮住。

但这里有个细节：Tilemap Renderer作为一个整体，只能整体参与排序，不能拆到单个瓦片。如果整张地图都用Tilemap渲染，角色走进树木区域时会整片被遮挡，地面、树、墙一起盖住角色，这显然不对。

我的解决思路是分层。地面、道路这些永远让角色站在上面的，放在一个Tilemap里，排序在角色后面；高物（树木、围墙、柱子）单独拆一个Tilemap，并把角色的Sorting Order设计成可以动态夹在两个Tilemap之间的数值。更进一步的做法是，把高物瓦片对应的区域在运行时转换成独立Sprite对象再参与Y排序，或者用代码动态调整TilemapRenderer的Order in Layer。

如果不想搞得太复杂，可以用一个取巧的办法：给高物Tilemap单独设一个Sorting Layer，让它默认排在角色后面，然后通过代码修改角色的Sorting Order来模拟前后遮挡。只要遮挡精度要求不高，这招足够用。

6.3 地图分层的设计思路

项目稍微复杂一点，地图就得按功能分层，而不是一张Tilemap刷到底。我的习惯是固定三层：

• 底层地面（Tilemap）：草地、泥土、道路等永远不需要遮挡玩家的瓦片；
• 中层物体（Tilemap）：树木、栅栏、高墙等需要遮挡或被遮挡的物体；
• 顶层细节（Tilemap）：装饰物、透明覆盖物，比如阴影、花丛，通常不会参与碰撞。

这三层分别配置Sorting Layer或Order in Layer，再配合Y轴排序规则，大部分2D地图的层级问题都能理顺。每一层还可以单独开关Collider，地面层不开碰撞，墙体层开碰撞，细节层也常关掉碰撞，这样物理计算量更小。

分层不仅为了渲染，也方便逻辑处理。比如寻路算法读取的底层数据只关心地面层是否可通行，碰撞检测只关心中层物体层，两者各司其职。

7. 实测翻车记录：缝隙、序列化与运行时改格子

7.1 瓦片缝隙闪烁的处理方法

平铺地图做出来后，最让人头疼的视觉问题就是瓦片之间的细缝。画面稍微移动，瓦片接缝处会透出背景颜色，出现一条条白线或黑线。

这个问题的成因，是相机移动时浮点计算导致的UV采样偏差，瓦片的边缘像素采样到了相邻的透明区域。尤其是像素风游戏开抗锯齿后，更容易出现。

我的解决路径是这样的：首先关闭场景里的抗锯齿；其次把所有瓦片的Filter Mode改成Point；再次检查相机，如果用Pixel Perfect Camera，把它的Asset Pixels Per Unit调成与瓦片PPU一致；最后实在还漏边，可以给瓦片Sprite的Mesh Type设为Full Rect，并稍微增加瓦片之间的覆盖范围，或者在图片边缘留一圈透明保护带。

最省事的保障是开启Pixel Perfect Camera，它的整像素对齐机制能极大减少边缘闪烁。但要注意，这个组件要求Sprite的PPU设置正确，否则画面会整体模糊。

还有一个复古派的土办法：让瓦片图片自带1像素的收边，也就是把瓦片内部的图案稍微缩小，四周留一圈和瓦片主色相同的填充。这样即使采样偏差，露出来的也是同色像素，视觉上看不到缝隙。这个方法比较粗糙，但确实有效。

7.2 运行时动态修改地图：几行代码的事

很多时候地图不是静态的，比如玩家可以挖方块、放置建筑。Tilemap提供了一套完整的运行时API。

拿到鼠标点击的世界坐标，转成格子坐标，再设置或删除瓦片：

using UnityEngine; using UnityEngine.Tilemaps; public class MapEditor : MonoBehaviour { public Tilemap tilemap; // 地面Tilemap public TileBase grassTile; // 要放置的瓦片 void Update() { if (Input.GetMouseButtonDown(0)) { Vector3 worldPos = Camera.main.ScreenToWorldPoint(Input.mousePosition); worldPos.z = 0; Vector3Int cell = tilemap.WorldToCell(worldPos); tilemap.SetTile(cell, grassTile); } if (Input.GetMouseButtonDown(1)) { Vector3 worldPos = Camera.main.ScreenToWorldPoint(Input.mousePosition); worldPos.z = 0; Vector3Int cell = tilemap.WorldToCell(worldPos); tilemap.SetTile(cell, null); // 擦除 } } }

如果要判断某个格子有没有障碍物，用Tilemap.HasTile或者先GetTile再判空都行。Tilemap还提供了CellToWorld和GetCellCenterWorld，前者拿到格子的左下角世界坐标，后者拿到格子中心坐标，做物体对齐放置很好用。

有个小坑是WorldToCell得到的坐标是基于Grid坐标系的，如果你的Grid有旋转或者缩放，转换关系会复杂一些。常规矩形Grid没有这些问题，直接用即可。

7.3 保存与序列化问题

Tilemap的地图数据默认是序列化进场景文件的。正常的"编辑地图、保存场景"流程没有问题，但如果你在运行时用代码大量SetTile，然后直接保存场景，有可能遇到地图数据没有完整落盘的情况。

解决思路是：运行时动态地图不要依赖场景保存，应该把格子变化导出成自定义数据。我通常的做法是，做一个数据类，把每个格子的坐标和瓦片名称记录下来，保存成JSON或者ScriptableObject。加载关卡时，先读取数据，再循环SetTile重新生成地图。

反过来，对于美术设计的静态地图，我会让关卡策划直接在编辑器里用Tile Palette刷，让Unity自己处理保存，而不是在运行时生成。

7.4 批量地图加载的速度问题

地图规模特别大的时候，运行时逐格SetTile会有明显的卡顿。因为每设置一个瓦片，Tilemap内部都要做一次脏标记、重新计算渲染网格。

优化思路有两个方向。一是把地图数据按区域分块，一次SetTile一块区域的瓦片，减少刷新频率。二是用Tilemap的SetTilesBlock方法批量写入，传入一个矩形范围内的瓦片数组，一次操作写入一整块数据，性能比逐格SetTile高很多。

TileBase[] block = new TileBase[width * height]; for (int x = 0; x < width; x++) { for (int y = 0; y < height; y++) { block[y * width + x] = mapData[x][y]; } } tilemap.SetTilesBlock(new BoundsInt(originX, originY, 0, width, height, 1), block);

实测下来，用SetTilesBlock加载一张100×100的地图，比逐格SetTile快一个数量级不止。如果你正在做类似地下城生成、大地图加载这类功能，强烈建议上来就用批量接口。

7.5 编辑器辅助：Tilemap上显示格子坐标

排查问题时还有一个实用技巧：在Tilemap上可视化格子坐标。写一个小的编辑器脚本，在OnDrawGizmos里把鼠标悬停的格子坐标画出来。这对做寻路调试、地图编辑器开发非常管用。

using UnityEditor; using UnityEngine; using UnityEngine.Tilemaps; [CustomEditor(typeof(Tilemap))] public class TilemapDebugger : Editor { void OnSceneGUI() { Tilemap tilemap = (Tilemap)target; Vector3 mouseWorld = HandleUtility.GUIPointToWorldRay(Event.current.mousePosition).origin; mouseWorld.z = 0; Vector3Int cell = tilemap.WorldToCell(mouseWorld); Handles.Label(mouseWorld + Vector3.up * 0.5f, cell.ToString()); SceneView.RepaintAll(); } }

这个脚本挂在Tilemap组件上就能用。实际项目里，我还会额外显示每个格子的可行走状态和地形类型，方便策划直接在编辑器里看到数据。调试工具这种东西，平时不起眼，出了问题就是救命稻草。

做平铺网格地图这件事，说难不难，说简单也不简单。核心还是理解Grid、Tilemap、瓦片资源这三层关系，然后把纹理导入、调色板、规则瓦片、碰撞分层这些基本功练熟。就我个人这几个项目的体会来说，最值得花时间的反而是前期的素材规范——PPU、锚点、Filter Mode先统一好，后面不管是刷地图还是跑逻辑，都能省掉大量返工的功夫。希望这些踩坑记录能让你少绕几圈。