关于游戏开发中瓷砖贴图的过渡（tile）

作者：Dalton2016-10-31

引言

瓷砖在游戏开发中的作用可以说非常巨大，哪怕在现在的2016年，依旧有非常多的游戏地表都是用有限的瓷砖拼起来的，除了id的mega texture以外，这里面的原因恐怕是不言自明的，因此我这段时间主要研究了一下这里面的一些技术问题，当然该问题跟美术相关性也比较大。

最早的瓷砖游戏

早期在红白机的几乎所有游戏都是瓷砖的，但是其中印象最深的或者最low的应该是dq1代，他的画面是这样的。

从这个游戏的画面可以明显的看到人为的瓷砖拼接痕迹，应该说瓷砖完全就是按类型划分的，中间完全没有过渡。同样的位置，在sfc时间，已经变成了这样。

我们只看地形的话，特别是水与草地的连接区块，已经明显看到了有过渡，当然这种过渡本质上是美术做了第二个草地瓷砖导致的。顺便说一句，dq1代是1986年出的，sfc版本在1993年同2代一起推出。

对于美国人来说，同样的图像进化印象最深的应该在Ultima IV到Ultima V的跨越，具体可见这个地址。

瓷砖存在的问题

使用瓷砖的首个问题恐怕跟现实中的一样，就是很明显的人造物体，而在游戏中，由于大量需要拟自然的草地，河流等，现在瓷砖首先需要处理的问题就是防止看起来像人造草地，人造河流。其次是平滑的过渡，自然界的绝大部分地表与地表之间是有合理过渡的，比如草地与沙地，森林与草地等，而不会出现生硬的分割，比如dq1的fc版本。最后一个问题是美术制作上的，如何生成一个可无限平铺的瓷砖，这个在技术上有一些手段，当然主要的处理还是在美术上。

瓷砖过渡

最简单的瓷砖过渡自然是人肉的方式，比如设计师在设计关卡的时候，根据周围的瓷砖选择应该选择的瓷砖，而美术在制作的时候就会制作一些过渡瓷砖，比如dq1 sfc版中主角的与水相邻的草地，就有明显的水花，这也与现实生活的观感一致，设计师在设计大地图的时候选中这块瓷砖即可。

但是关卡设计师如果每次想做个草地都要进行类似的判断，明显是一件愚蠢的行为，因为采用哪个瓷砖完全可以程序化，简单的说这个逻辑相当简单，完全可以用程序解决，而关卡设计师只要用填充工具填充一个草地即可，不需要关心用哪个过渡草地贴图。

如何处理瓷砖过渡

简单的计算下瓷砖过渡所需的块数。

首先是最基本的一个类型一个瓷砖，那么块数显然是1。

下图是我们预期达到的效果：

看上去有点复杂，怎么计算需要多少块草瓷砖与水的过渡呢，以上图中三面环水的瓷砖举例，可以看如下的抽象图

1 0 0

0 # 0

1 1 1

#即那个瓷砖块，由这这个简易的抽象图可以明白，实际上采用那个瓷砖块由周围的8个格子决定，所以排列组合有2^8个，即256种组合，而这仅仅是草与水的组合，如果草与沙、泥土等那不得是天文数字。

所以下一步就是如何优化这个组合数量，可以看到这种组合排列方式有是以地形类型在图形中间为准的，即我们的思维方式是草，另外可以看到刚才抽象图中左上角的1对#号并没有相互影响的关系，也就是说，组合排列方式未必是相乘关系（当然想做的更好还是可以做不一样的，这两个草地相挨比较近，按道理中间应该有浅滩）。

现在来说一些详细的对策，对策一就是将4个边缘及4个对角的图片拆开处理，在程序中在动态合并起来，这样的话就只需要2^4 + 2^4 = 32个图片即可解决此问题，这种办法可以参见此文。

对策二就是去除一些在游戏中不会出现或者不需要处理的过渡区块，比如刚才的草地对角（刚才也解释了，在这种情况下，实际上有会更好），对角外墙的衔接，这种处理往往在墙这种材质中比较常出现，适合泰格瑞亚这类游戏，具体可以参考此文中的Blob模式（仅需要47块），应该来说非常适合做此类游戏。

对策三是最常使用的招数，绝大部分游戏都使用此处理方式，那就是将瓷砖类型信息放在对角进行考虑，这样2^8 就直接变成了2^4即16个瓷砖组合。

当然这种方式也有几个问题，因为整体瓷砖有偏移，所以地表需要做偏移量，否则与人物等上层图层会有偏移。另外一块瓷砖就不仅仅是一个类型信息了，而是有四个类型信息，也就是占用内存会更多点。

在游戏应用上还有一种瓷砖过渡方式与此方式完全不同，过渡块实际上是一个单独的图片，程序会在游戏运行时动态用过渡块混合原始图片，这样美工的工作量很少很多，而且过渡块可以通用于很多资源，下图说明一切。

原理图

效果图

当然这种通用出来的过渡模板不可能通用一切类型，一般需要多个类型之间做几种，比如这个是我从帝国时代中截图得到的不同过渡块模板。

瓷砖类型间的过渡

刚才讨论的仅仅是两种瓷砖间的过渡，我们成功将256种可能缩减到了几十个，而如果有其他类型相互组合又如何处理呢，比如水与沙地，是否要重新制作几十个过渡块？

这个解决方法也有许多，比如在真实世界中，水一般不太可能跟砖块，铁等相互衔接，所以一般制作上不会按n*m的方式制作所有过渡块，只会在需要的时候制作即可，待会我们介绍Tiled编辑器的时候可以看到他是如何记录多个类型之间的过渡的。

另外一种处理方式比较讨巧，就是定好多个类型之间的层级关系，比如草地一定是在水上方，而岩石一定是在草地上方，而图片原型含有透明度，游戏运行是按层级做透明混合即可（war3即是这样的处理方式）。

2D游戏中的瓷砖过渡

下面我想举一些游戏中的例子，来说明下以上的做法。

编辑器Tiled

目前Tiled应该是2d瓷砖编辑器的王者，基本上包含了一个直接可用的瓷砖编辑器，另外他在0.9的版本新增了地形元素，包含了瓷砖过渡的功能。

可以看到沙地与鹅卵石、普通路面间均有过渡，另外操作上也很直观，采用的是方案三，即4斜角判断类型的方式，所以仅需16块瓷砖（实际上只需要15块，没有全是0的可能）即可自身瓷砖做任意平铺。不需要对角衔接的情况还可以去除两块。具体的操作可以查看Tiled文档尝试一下。

泰格瑞亚

泰格瑞亚的采用比较极端，在Reddit上有泰格瑞亚美术的回答，他们使用的是256个过渡块，这个美术同学满是吐槽，我扒了下电脑上泰格瑞亚的游戏，还真是。

这个美术同学说，如果重新设计的话，他比较希望采用47块的那种方式，当然这种方式会导致对角块没有衔接，但是问题不大。

Starbound

Starbound是泰格瑞亚团队成员重新创立的一个科幻版的类泰格瑞亚，我没有仔细玩过，不过我特地研究过了一下他的tile拼接方式，发现他的格子是这样的。

瓷砖非常小。另外外部的衔接块只有4px，中间的块则是8px，我第一眼的直觉就是，这个应该还是类似方案三的过渡方式，上面的8×8的应该是对角衔接。于是我用ps重新做了下透明像素填充，为了能在Tiled中直接使用，于是这个泥土块变成了这样。

由此来看，泰格瑞亚的瓷砖过渡块是非常不人道的。顺便说下，starbound和饥荒的关卡编辑都是用Tiled制作的，虽然他们都包含了绝大部分程序化的世界生成，但是有非常多的套路关卡直接用Tiled设计了。

RPG Maker VX

这个是做RPG游戏非常有名的编辑器，出名的游戏我就不列举了，而这个编辑器给我最大的印象就是我在08年用js做一个rpg引擎时，一直苦恼于如何程序化衔接每个类型的瓷砖，而这个编辑器打开用，我很惊艳于他直接可用的过渡瓷砖，但是当时因为时间有限，并没有去深入研究他的实现，现在因为本篇文章的整理，基本上明白了他的实现原理就是我的类似方案三的实现，只不过他的地表应该是自带偏移了。他的砖块集如下，为了更明确的明白他的实现，我特地在一个可衔接砖块上标注了1到6。

不过我的标注应该是错误的，他实际上应该是13块的实现，即没有对角过渡。

3D游戏中的瓷砖过渡

3d游戏中普遍还是瓷砖地图，只不过绝大部分可能用了纹理混合达到细微调整。

魔兽争霸3

war3实际上在上面已经提到了，他使用15块过渡瓷砖做的地表，另外明确多个地表类型之间的层级关系，不过由于是3d游戏，有光照和阴影对场景的影响，所以导致看上去纹理并没有明显的重复。

下图是我用Tiled设定的war3草地图

与上面不同的是，war3有对角衔接图。

Dota2

Dota2的平面地表是可以做多材质，多纹理的混合的，而且混合效果非常好，衔接区块是不需要制作的，完全是用程序混合生成。具体的可参考这个还有这个。

Wang Tiles

除了边角处理以外，中间都相交的区块重复度还是很高，所以一般游戏基本上都会做多套随机使用，比如war3的图片，明显是有非常多的中间区块用来随机使用的，有没有更好的办法将这种重复感觉进一步弱化呢，答案是Wang Tiles。

本质上就是将随机选取中间块变成了根据更加多元化的边界及样式将人造感弱化。

文章已经有点长了，所以不太希望把这个话题再铺开，google下可以搜索得到很多相关文章，比如这个，这个。

流亡黯道

流亡黯道的处理方式跟上文的瓷砖过渡没有太大关系，主要是使用了wang tiles的做法，做了一个比较不错的应用，我把他放在这里，官方这个教程很不错，主要是美术同学如何制作可以用来做wang tile的教程。

其他方案

上文的瓷砖过渡方案主要都是美术制作的，而目前市面上3d游戏另外一部分制作是通过程序混合的，类似地形高度图的使用，应该是生成了专门的笔刷图或者顶点属性，在地图加载的时候动态混合出来使用的。这样的话，美术可以直接在地图编辑器里作画，可以节省更多的美术资源，不过效果如何还是要看美术的功力。

比如在Dota2 Workshop中的这里文章中可以看到应该是在顶点中存了同个材质不同纹理在顶点的所占比重达到了混合效果，从dota2实际效果看，混合得挺不错的。

游戏样例分析

饥荒

饥荒的地表明显是Blob模式，即47块，每块为136像素比较特别的是，饥荒的地表跟Blob模式是反向的，即实际操作中对应Blob模式的实物居然是空地，我在简单实现中发现，饥荒应该在设计阶段用的是1，0等简单的标示地表类型，而通过程序动态算出使用的区块的，因为如果是地表编辑的时候使用此方式，那么笔刷很难操作。

帝国时代