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

很多游戏从白盒开始建关卡，然后美化场景。

但是这一步是不是有很多重复性的工作。

白盒的建立是为了快速看到效果，这无可厚非，但是这个东西似乎有很多缺点比如他毕竟不是最终游戏给玩家的东西，所以他很可能是没有意义的至少对于玩家来说，是看不到的做的少，很可能就体现不出游戏的效果做多了会违背快速见到效果的想法，不会卡在那里

最尴尬的是，做完白盒后，往往需要删除所有白盒来美化关卡，基本没有依赖性一旦某个东西后期需要修改，怎么改去白盒再改一遍，最后场景再改一遍

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

1.白盒对于游戏开发过程的意义

首先，游戏开发过程中为什么需要白盒。这个矛盾出现在两个极端:

有人认为游戏地图完美，就像很多3A大作一样，整个地图是一个整体，UE拼命解决的所谓超级地图也是指这种地图我们玩过很多所谓的顶级3A游戏，里面场景和建筑的重复度很低除了一些房子，大部分都很严重，尤其是迷宫里，一个角落一个角落，比如古墓丽影系列三部曲，FarCry系列这并不是说他们场景中的一些小物件没有重复，而是整体用小岛秀夫的话来说，就是欧美人傻乎乎地玩游戏，苦于人力

在这种认知下，制作白盒在整个过程中的作用，大多是辅助原场景绘制和设计沟通确认层面这个怎么理解一般我们在玩游戏的时候，在制作场景的时候，都要有原始的场景绘画来确定场景的艺术风格，包括建筑，地形，色彩等等那么，具体场景是什么样的呢因为设计得有个白盒来调节灯光，放置小物件，刷怪位，战斗区域等，所以原场景画+白盒=确定整个场景应该怎么做如果野蛮理解，完全可以理解为打草稿当然，这个草稿是非常必要的，因为没有草稿很难做好为什么这个过程被贬损为打草稿首先，3D原画和模型有很多冲突，尤其是你原画的一些细节做一个模型不容易，但是这些细节很重要，检查点设计也是如此很多时候白盒的希望会打破模型的性能，或者对模型制作有很高的要求这个时候大家会通过白盒互相妥协一个方案——所以不要低估这个起草的重要性毕竟这种野蛮又耗费人力的事情一旦涉及的人太多，很难在每一个细节上统一方向和标准，所以一定要打草稿，把失败降到最低

如果纯粹从艺术意义上来说，做白盒是不是浪费时间，完全取决于游戏项目地图制作的思路和调性以上两种极端的风格，中间融合的做法，其实是有道理的，所以你说做白盒浪费时间，要等你达到具体的设计要求才能说出来

但就这一点，你就要完全说白盒工作是浪费，这是不合适的因为游戏开发，也就是说在制作这个地图的时候，做美术只是工作的一部分，甚至可以认为是plus的工作

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

为什么我们需要制造白盒还有一个很重要的原因，就是白盒的数据对于懂得开发游戏的团队来说，可以成为最终的地图数据没错，是地图数据，但不是完整的场景数据地图数据是地图中的地形等信息

回到最原始的逻辑，比如我们现在要做一个标准的JRPG，那么他的地图数据可以是一个二维数组，每个单元格中的数据就是一个单元格的信息。比如在火纹系列这样的标准SLG游戏中，即使他渲染3D，一个网格中的数据还是需要:

1.是什么地形:森林，平地还是河流，直接关系到UI。

2.它的闪避是什么:我们知道火系模式中不同的细胞会带来闪避加成这是游戏规则

3，它回不了血:站在火纹中某些细胞上的人物每回合都会恢复生命值。

4，它的代价阵:也就是每种行动方式的单位上行时会消耗多少移动力。

这些信息形成一个Struct MapGrid，然后映射信息就是一个ArrayltArrayltMapGridgtgt，为什么需要这样的信息也是为了处理游戏中的角色必须在地图上行动的事实

如图所示，火灾模式中的网格

同样，任何一种游戏都需要这样的结构我们假设这个3D游戏是类似达摩指环这样的灵魂游戏，或者是类似忍者神龙或者怪物猎人这样的游戏那么这个游戏中的人物可以行走，施展技能，跳跃，作为职业差异，有的职业可以爬墙，有的不能有些职业踢到墙后会反弹回来所以当我们移动角色时，我们需要一系列的地图信息

说到这里，有些新手可能会说，那我们可以用NavMesh，然后直接用成品模型做网格对不对

1.如果我的游戏里所有的角色都会跳，有些角色会飞，你NavMesh怎么帮助我的会飞的角色找到路本质上NavMesh是把网格的三角面作为网格，把相邻的三角面作为下一个的星，但我的角色并不贴地NavMesh怎么做你说是投影在地上，但是那个人走不过矮墙我不能飞过它吗

2.墙，地板，天花板——这也是动作游戏中最经典的移动问题首先，怎么辨别是不是墙与世界坐标系的夹角大于等于X度可以认为是墙吗爬60度的墙没问题120度的墙呢

这个小房子的模型不错，至少可以接受请问墙上的两个裂缝应该往上爬吗根据navMesh的说法，这个缝的底部在平面上是180度，可以算是屋顶吧

所以在实战中，你不能用这么精致的模型的网格作为NavMesh的数据。

于是，这个时候，白霉的价值就开始显现了我们完全可以用白霉作为地图的数据，至少是块的数据——我们用形状一个个拼出地图块，然后在这些形状上附加一些属性，这些属性就是地图需要的属性不管是Unity还是UE，都可以附加组件实现附加属性，虽然UE和Unity的组件有天壤之别

3.用白色模具可以避免楼梯和斜坡两个大坑。

顺便说一下，正常的运动不会用NavMesh来完成，而是用shape rays来完成。如果使用光线进行碰撞检测，将会遇到经典的斜坡陷阱和楼梯问题

什么是斜坡陷阱通常情况下，我们会遇到一个斜面假设我们认为角色的攀爬力是60度，是lt，他可以上60度的坡，但是我们做射线怎么上

让我们在这里做一个2d部分。

我们可以看到蓝色是实际的移动路线——因为我们通过法线转弯后得到的是上坡的矢量，最后虚线半透明的蓝色是角色的移动力，也就是这一帧的移动距离红色箭头代表的是角色如果是平的，也就是在俯视图中的正常移动距离，所以红色的长度就是蓝色虚线的长度，因为都是1帧移动量那么我们可以看到——从游戏玩家的角度来看，上坡速度比正常移动速度慢为什么在游戏玩家眼中，移动速度只是横轴，那么在XY方向上，玩家的期望就是角色还能走那么多红线吧所以我们需要用数学的方法来补偿他这个距离——这其实就是游戏研发中经典的斜坡陷阱所以，如果他这里的地形坡度是一个圆，甚至是一个球体，计算压力会大很多，最终的精致模型很可能会有这么高精度的形状，而白色模型不会——这是使用白色模型作为地图数据的关键

楼梯问题也是墙造成的我们来看下图

也是横截面。

每一个小方块都是一堵低矮的小墙，那么人物应该能过得去吧这和坡度是冲突的，因为，比如我们的爬坡力是60这个小墙和地面的墙边一定是90度，大于60度移动算法肯定不肯上那么问题来了我们直接把角色抬高一个楼梯高度合适吗如果这是这里唯一的高度怎么办

我们不应该去那里吗所以，楼梯往往是一个很常见也很麻烦的存在——如果从现实世界的角度来看，我们最好的做法是什么很简单

两个角色激烈打斗，带着她的小宠物站在楼梯上。

黄色是楼梯的白盒，也就是地形的信息，蓝色是人物的碰撞碰撞盒决定了人物可以在这个斜坡上行走，而注意人物的脚是因为模型之间的碰撞结合了IK做出的视觉效果，逻辑和视觉分开计算，造成了我们看起来这个样子的效果

4.在这里，你能看到白盒的价值吗。

其实白盒最终还是要作为游戏地图数据的，不仅仅是为了碰撞，而且我们在把每个盒子放上去的时候也可以给这个盒子添加属性，比如这个盒子代表什么，这个盒子是否可以作为地面可以是墙吗可以是天花板吗

从项目的开发过程来看，白盒完成的时候，模型美术，边疆美术等可以开始制作相应的美术资源，策划可以在此基础上制作模型，程序的成品功能也可以直接在上面操作最后只要穿上art做的模型(因为不是白盒的替代品，只是白盒不显示，在Unity和UE中可以设置不显示例如，隐藏UE的名称就是这样做的三个人一起工作，谁也不依赖谁，所有人都依赖白盒——项目开发过程是解耦的

那么造一个白盒还是浪费时间吗。