很多游戏搭建关卡从白盒开始，搭建完白盒，再美化场景。
但是这样的步骤是否存在大量的重复做工？
搭建白盒是为了快速看效果，这可以理解，但是这玩意似乎有很多缺点。比如他毕竟不是最终游戏给到玩家手上的东西，所以他很可能是没有意义的，起码对于玩家来说，玩家都看不到。做少了很可能体现不出游戏效果，做多了又违背了快速看效果的理念，卡在那里不上不下。
最尴尬的是，做完白盒之后，美化关卡往往是需要把白盒全部删除掉，基本没有依赖，一旦后面需要修改一些东西，那要怎么改？去白盒改一次，再在最终场景再修改一次？
其实白盒的作用不仅于此的，还是看各个团队对游戏开发本身的重视度来决定的。
1、白盒对于游戏开发流程的意义
首先是游戏开发流程中为什么需要白盒？这个矛盾出现在两种极端上：
一种人认为的游戏地图是“完美无缺的”，就像很多 3A 大作一样，整个地图是一整张，而 UE 玩命在解决的所谓“超大地图”指的也是这种地图。我们玩过许多的所谓“顶级 3A 游戏”，他们里面的场景和建筑物的重复度是非常低的，除了凑数的一些房屋外，绝大多数尤其是迷宫内，他都是很认真的一个角落一个角落硬怼的，比如《古墓丽影》系列的三部曲，《FarCry》系列等，这不是说他们场景里面的一些小物件 (Doodad) 是不重复的，而是整个关卡（地图）的布局等，都是硬怼的，而不是复用的。用小岛秀夫的话说，就是“欧美人做游戏就是蛮干，硬怼人力”。
在这种认知下，做白盒在整个流程中起到的作用大多是“辅助场景原画”和“交流确认关卡设计”。这怎么理解呢？就是一般我们做游戏的时候，做一个场景，得有场景原画来确定这个场景的美术风格，包括建筑啊、地形啊、色调啊等等元素内容，然后这个场景具体是什么样的，因为设计到打光、小物件摆放、刷怪位置、战斗区域等，还得有个白盒来调整，所以场景原画 + 白盒 = 确定整个场景要做咋样，如果你野蛮的理解这个流程，完全可以理解为“打个草稿”，当然这个“草稿”是非常有必要的，因为没有草稿很难做好，而为什么这个过程会被贬义为“打个草稿”，首先是 3D 原画和模型之间就有着很多冲突，尤其是你原画出的一些细节，做模型又不太好办，但这些细节有十分重要（美术设计意义上的重要）；关卡设计也是如此，很多时候白盒的希望会打破模型的表现，或者对于模型制作有很高的要求，这时候大家通过白盒来互相妥协出一个方案 —— 因此你别小看了这个“打草稿”的重要性，毕竟这种野蛮的、堆人力的事情，参与的人一旦多了，很难在每个细节上统一好方向和标准，所以我们必须打一个草稿，尽可能少的出现失败的制作（主要是会造成时间成本的浪费）。
另一种人认为游戏地图是“元件组合”的，当然这种理解概括的说没错，事实上这也是游戏行业一脉相承的“老办法”，就是你做了很多个比如房屋的模型，然后把它放在地图上的不同地区，转转不同的角度，然后这些房子之类的东西上有一些小细节是可拆卸的，比如这边这座房子上个房间，那边那个房子多个尖顶，都是细微差距，这种情况下，确实直接从从原画到 3D 模型然后再摆放关卡是合适的，正如我们玩很多游戏的地图编辑器，比如《魔法门之英雄无敌系列》、《帝国时代》系列等都是如此。而因为模型很容易量产，或者即便没达到量，因为这种复制思路在，所以我有几个代表性的模型，就直接可以做关卡了，细节再调整。这种情况下，确实白盒的意义不大，整个流程中是不太需要白盒的。
假如单纯的从美术的意义上来说，那么做不做白盒，是否浪费时间，完全是看游戏项目的地图（关卡）的制作思路和调性的，以上两个极端风格和中间融合的做法，其实都是合理的，所以你说做白盒浪费时间，不到具体设计需求是看不出来的。
但是就凭这一点，你要全盘的说白盒工作纯属浪费，是不合适的，因为游戏开发，就说这块地图（关卡）制作上，做美术只是其中的一部分工作，甚至可以被认为是 plus 的工作，最核心的内容还是地图能玩起来，所以你得接着看：
2、白盒是游戏数据中的一部分
我们为什么需要做白盒？有一个十分重要的原因，就是白盒的数据，对于懂得游戏开发的团队来说，可以是一个最终的地图数据，是的，是 Map 数据，但不是完整的 scenario 数据。Map 数据就是地图中的地形等信息。
回到最原始的逻辑中，比如我们现在要做一个标准的 JRPG，那么他的地图数据完全可以是一个二维数组，每一个单元中的数据就是一个单元格的信息。再比如《火纹系列》这种标准的 SLG 游戏，即便他渲染的是 3D，他一个格子内的数据依然需要：
1，它是什么地形：森林、平地还是河流，这和 UI 有直接关系。
2，它的闪避是多少：我们知道火纹里面不同单元格是会带来闪避加成的，这是游戏规则。
3，它回不回血：火纹里面一些单元格上站的角色每回合会恢复生命值。
4，它的 Cost 数组：也就是每一种行动方式的单位走上去会消耗多少移动力。
这些信息组成一个 Struct MapGrid，然后地图信息就是一个 Array<Array<MapGrid>>。为什么需要这样的信息，也是为了处理游戏中角色要在地图上行动。
同理的，任何类型的游戏，都会需要这样一个结构，我们假定这个 3D 游戏做的是一个法环一样的魂类游戏，或者是一个忍龙，再或者是怪物猎人这样的游戏。然后这个游戏中角色能走路、放技能（技能就会带位移）、能跳；作为职业区别，有些职业可以爬墙，但其他职业不能，有些职业踢墙反弹（就如街霸里面春丽跳到版边可以跳回来一样）。所以在我们做角色移动的时候，就需要一系列地图信息。
说到这里可能有新手菜鸟会说，那我们可以用 NavMesh，然后直接用做完的模型作为 Mesh 不就来了吗？那你再仔细想想这些问题能解决吗：
1，如果我游戏中角色都能跳，也有角色可以飞，请问你 NavMesh 如何帮我飞的角色寻路？NavMesh 本质上是把 Mesh 的三角面作为 Grid，把相邻三角面作为 "next" 的 AStar（AStar 通常用于把 Tilebased 格子的规则作为 next，比如我们上面说的火纹系列的地图），但是我角色并没有贴住地面，你如何做 NavMesh？你说投影到地面上，那人走不过的矮墙，我飞还飞不过去吗？
2，墙壁、地板、天花板 —— 这也是动作游戏中最经典的移动问题，首先如何判断是一堵墙壁？与世界坐标系的 (UE 是 XY 平面，Unity 是 XZ 平面）夹角大于等于 x 度（比如 60 度）就可以认定为墙壁吗？60 度的墙壁爬上去没问题，120 度的呢？而很多时候我们为了做细节，实际模型的墙壁还是凹凹凸凸的：
所以实战中，你不可能用这样精致的模型的 Mesh 来作为 NavMesh 的数据。
所以这时候，白模的价值开始出现了，我们完全可以用白模作为地图的数据，至少是阻挡的数据 —— 我们用一个个形状（不限于 Cube，但最好最多只到三角）拼出地图阻挡，然后给这些形状附加一些属性，就是地图需要的属性，无论 Unity 还是 UE 都是可以给他们挂 Component 来做到附加属性的，尽管 UE 和 Unity 的 Component 是有天壤之别的。
3、用白模能逃避楼梯和斜坡两大坑
而这里顺带一提的是，正常的移动，也不会用 NavMesh 来做，而是用形状射线（比如发出胶囊体，最好是上下锥形射线来做碰撞检测）。如果用射线来做碰撞检测，你就会遭遇经典的“斜坡陷阱”和“楼梯问题”
什么是斜坡陷阱？就是正常来说我们遇到一个斜面，假设我们认为这个角色爬坡力是 60 度（每个角色当然可以不一样的），也就是 < 60 度（能不能等于随你）的斜坡他能走上去，但是我们做射线的时候怎么走上去呢？因为也有不能上去的斜面对吧，所以会有下图现象：
我们可以看到，蓝色的为实际运动的路线（故意抬高了点因为…… 画得不好…… 反正就那意思）—— 因为我们通过法线来得出“拐弯”以后上坡的向量，最终虚线半透明的蓝色，就是角色的移动力，也就是这一帧 (UE 里一个 deltaTime，Unity 一个 FixedUpdate) 的移动距离。红色的箭头，代表了如果是平地，也就是顶视角时，角色的“正常移动距离”，所以红色的长度 == 蓝色虚线的长度，因为都是 1 帧移动量。然后我们可以看到 —— 从游戏玩家的角度来说“上坡的速度比正常的移动速度慢了”，为什么？因为在游戏玩家心目中，移动速度仅仅只是横轴的，所以在 XY（XZ）方向上，玩家的期望，是角色依然能走红线这么多，对吧，因此我们需要用数学的方法，补给他这个距离（怎么补我就不好意思说了，在座的学历大多都比我高，我都知道何况你们……）—— 这其实就是游戏研发中经典的“斜坡陷阱”，因此如果他的地形斜坡这里是个圆（肯定是椭圆公式的圆），甚至是球形（无数个这样的三角形），运算压力就会大不少，而最后精致的模型，是很可能出现这样高精度的形状的，但是白模不会 —— 这是用白模作为地图数据的关键。
而楼梯问题，也是因为墙壁所致，我们看下图
每一个小方块都是不高的“小墙壁”，那么角色应该能过去吗？这里是与斜坡冲突的，因为比如我们的爬坡力是 60，这个小墙壁的“墙边”和地面肯定是 90 度，大于 60 度的，移动算法肯定是拒绝上去的，那问题来了，我们直接把角色抬高一个“楼梯高度”妥吗？那如果这里真就这点高度不让走（人不能走，子弹能飞过去）该咋办？或者是这里仅仅是一个小孔，如下图：
是不是就不该过去了？因此楼梯常常是一个十分常见有令人头疼的存在 —— 假如我们用真实世界的眼光去看的话，于是我们怎么做楼梯最妥？很简单，白模是斜面，用角色 IK 和视觉层（也就是覆盖在斜面上的楼梯模型）做碰撞：
黄色的是楼梯的“白盒”也就是地型信息，蓝色的是角色的碰撞（至于为什么 2 锥 1 柱是更好的碰撞，而胶囊体是一个“凑合、还成”的碰撞，那是另一个问题，不在这里进一步讨论），碰撞盒决定了角色可以走上这个斜坡，而注意看角色的脚，是因为模型与模型的碰撞结合 IK 做出来的视觉效果，逻辑和视觉分开运算，产生了我们看起来的这个效果。
4、到此，可以看出白盒的价值了吧？
白盒其实最后是应该被用作游戏地图数据的，不仅仅是是碰撞，并且我们在往上放每一个“盒”的时候就可以给这个“盒”添加属性，比如这个盒子代表了什么（草地还是什么，没准有逻辑作用呢？），再比如这个盒子能不能当地面？能不能当墙壁？能不能当天花板？（这也是另一个细节话题，不在这里展开）。
从项目的开发过程来说，当白盒完成之后，模型美术、地边美术等可以开始做对应的美术资源（UE 称之为“资产”），同时策划可以在这基础上做模型了，而程序做完的功能，也可以直接在这上面运作，最后只要“穿上”美术做来的模型（因为并不是替换白盒，只是白盒不显示了，这个在 Unity 和 UE 都能设置不显示，比如 UE 的 HideInGame 就干这个的）。三路人马一起开工，谁也不依赖于谁，大家都依赖于白盒 —— 项目开发流程解耦了。
所以搭建白盒还浪费时间吗吗？
本文来自微信公众号：千猴马的游戏设计之道 （ID：baima21th），作者：猴与花果山
广告声明：文内含有的对外跳转链接（包括不限于超链接、二维码、口令等形式），用于传递更多信息，节省甄选时间，结果仅供参考，IT之家所有文章均包含本声明。