游戏关卡搭建白盒是否是一个浪费时间的行为？

游戏关卡搭建白盒是否是一个浪费时间的行为？许多游戏关卡都是以白框开始的。搭建完白盒子后，场景就美化了。

但这样的步骤是否涉及大量重复工作？

搭建一个白盒快速看到效果也无可厚非，但这东西似乎有很多缺点。比如说，毕竟它不是在最终游戏中给予玩家的东西，所以它可能没有任何意义，至少对于看不到它的玩家来说。如果做得太少，游戏效果可能无法体现。如果做得太多，就违背了快速看到效果的理念，就会卡在那里。

最尴尬的是，完成白盒后，美化关卡往往需要删除所有白盒。基本上没有依赖关系。一旦以后需要修改的话，应该如何修改呢？到白框那里修改一次，然后在最终的场景中再修改一次？

其实白盒的作用不仅限于此，还取决于各个团队对游戏开发本身的重视程度。

一、白盒对于游戏开发过程的意义

首先，为什么游戏开发过程中需要白盒？这种矛盾表现在两个极端：

一个人认为游戏地图是“完美”的，就像很多AAA大作一样，整张地图都是一张，而UE正在努力解决的所谓“超大地图”也指的就是这种地图。我们玩过很多所谓的“顶级3A游戏”。其中场景和建筑的重复率很低。除了少数房屋外，大部分都是非常严重的死角，尤其是迷宫里。一角难敌，如《古墓丽影》系列三部曲、《孤岛惊魂》系列等。这并不是说它们场景中的一些小物体（Doodad）不重复，而是整个关卡（地图）布局等都是死板的，不可复用。用小岛秀夫的话说，“欧美人在游戏上、在争夺人力资源上都是鲁莽的”。

在这样的理解下，白盒在整个流程中的作用大多是为了“辅助场景原画”和“关卡设计的沟通和确认”。这怎么理解呢？一般来说，我们在制作游戏、创建场景时，必须要有原场景画，才能确定场景的美术风格，包括建筑、地形、色调等元素。那么场景到底是什么样的呢，因为设计Lighting、小物体摆放、怪物产卵位置、战斗区域等等都需要用白盒来调整，所以原来的场景画+白盒=决定了整个场景将会是。如果你野蛮地理解了这个过程，你就可以做到。理解为“打草稿”，当然这个“草稿”是非常有必要的，因为没有草稿就很难做好，而为什么这个过程会被贬称为“打草稿”呢？首先，3D原画和模型之间存在差距。有很多冲突，特别是你原来画的一些细节，在做模型的时候不好处理，但是这些细节很重要（美术设计意义上的重要）；关卡设计也是如此。很多时候，白盒的希望会打破模型。性能，或者对模型制作要求非常高，这时候大家通过白盒相互妥协，拿出一个方案—— 所以，不要低估这个“起草”的重要性，毕竟这种野蛮、人力重一旦涉及的人员太多，每个细节上就很难统一方向和标准，所以必须打草稿，尽量减少制作失败的次数（主要是造成时间和成本的浪费）。

另一种人认为游戏地图是“组合组件”。当然，这种认识大体上是正确的。事实上，这也是游戏行业延续的“老方法”。就是你做很多房子的模型，然后把它放在地图上不同的区域，旋转不同的角度，然后这些房子上面有一些可拆卸的小细节之类的，比如这个上面有一个房间这里的房子，那边的房子有多个尖顶，它们都是细微的差别。这种情况下，直接从原画到3D模型，然后放置关卡，确实是合适的，就像我们在很多游戏中玩的地图编辑器一样，比如《魔法门之英雄无敌系列》和《世纪之战》。 《帝国》系列等。而且因为模型很容易量产，或者说即使量没有达到，因为这种抄袭的想法，我就有了几个有代表性的模型，可以直接做关卡，调整细节。这种情况下，白盒的意义确实不大，整个流程也很少需要白盒。

如果纯粹从艺术的角度来看，做不做白盒子都是浪费时间。这一切都取决于游戏项目的地图（关卡）的制作思路和调性。上面两种极端的风格和中间融合的做法，其实都是有道理的，所以你说做白盒是浪费时间，但是没有具体的设计要求是看不出来的。

但基于这一点，你说白盒工作纯粹是浪费是不合适的，因为在游戏开发中，比如说这个地图（关卡）制作，美术只是工作的一部分，甚至可以考虑plus的工作核心就是地图可以玩，所以你得继续往下看：

2.白盒是游戏数据的一部分

为什么我们需要做白盒？还有一个很重要的原因，就是对于一个懂游戏开发的团队来说，白盒数据可以成为最终的地图数据。是的，它是地图数据，但它不是完整的场景数据。地图数据是地图中的地形和其他信息。

回到最原始的逻辑，比如我们现在要做一个标准的JRPG，那么它的地图数据可以是一个二维数组，每个cell中的数据就是一个cell的信息。另一个例子是像《火焰之纹章系列》这样的标准SLG游戏。即使以3D方式渲染，一个网格中的数据仍然需要：

1. 是什么样的地形：森林、平地还是河流？这与UI直接相关。

2.它的闪避是什么：我们知道火纹中不同的格子会带来闪避加成。这就是游戏规则。

3、不恢复生命值：站在火纹中部分格子上的角色每轮都会恢复生命值。

4、其Cost数组：即每种动作模式的单位向上走时消耗多少移动力。

这些信息组成了一个StructMapGrid，然后地图信息就是一个Array。为什么需要这样的信息也是为了处理游戏中地图上角色的动作。

如图所示，火焰之纹章中的“网格”是一样的。任何类型的游戏都需要这样的结构。我们假设这个3D游戏是魔戒之类的魂类游戏，或者是忍者龙之类的游戏，或者是怪物猎人之类的游戏。然后这个游戏中的角色可以行走、使用技能（技能会带来位移）、跳跃；作为职业之间的区别，有的职业可以爬墙，有的职业则不能，有的职业可以踢墙反弹（比如街霸里春丽的跳跃可以跳回页面边缘）。所以当我们移动角色的时候，我们需要一系列的地图信息。

说到这里，有的新手可能会说，那我们可以用NavMesh，然后直接把做好的模型当成Mesh吧？那么仔细想想，这些问题是不是可以解决：

1. 如果我的游戏中的角色可以跳跃，有些可以飞行，NavMesh 如何帮助我的飞行角色找到路径？ NavMesh本质上是使用Mesh的三角面作为Grid，将相邻的三角面作为‘下一个’AStar（AStar通常使用Tilebased网格的规则作为下一个，比如《火焰纹章》系列的地图我们上面提到过），但是我的角色没有接触地面，你怎么做NavMesh？你说如果投影在地面上，我就无法飞越那堵没人能走过去的矮墙？

2.墙壁、地板、天花板—— 这也是动作游戏中最经典的运动问题。首先，如何判断是否是墙？与世界坐标系（UE为XY平面，Unity为XZ平面）的夹角大于等于x度（例如60度）是否可以认为是墙？爬60度的墙没问题，但是爬120度的墙呢？很多时候，为了制作细节，实际模型的墙壁还是凹凸不平的：

这个小房子的模型还不错，至少还过得去。我想问一下，我能从墙上的两条裂缝里爬过去吗？根据navMesh，这条接缝的底部与平面成180度，可以认为是屋顶，对吗？所以在实战中，你不能使用如此精致模型的Mesh作为NavMesh的数据。

所以这个时候，白款的价值就开始显现了。我们完全可以用白色模型作为地图数据，至少分块数据——。我们一一使用形状（不限于立方体，但最好最多只达到三角形）来拼出地图。块，然后给这些形状附加一些属性，这些属性就是地图需要的属性。 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称之为“资产”）。同时规划可以在此基础上做模型。程序完成的功能也可以直接在其上进行操作。最后只需要将art制作的模型“穿上”即可（因为不是替换白盒，而是白盒不显示。这个可以在Unity和UE中设置不显示，这样正如UE 的HideInGame 所做的那样）。三组人开始齐心协力，互不依赖。大家都依赖白盒——项目开发流程，是解耦的。

那么构建白盒是浪费时间吗？

本文来自微信公众号：千猴马的游戏设计（ID：baima21th），作者：猴子与花果山