设置
  • 日夜间
    随系统
    浅色
    深色
  • 主题色

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

千猴马的游戏设计之道 2022/12/1 17:04:13 责编:远生

很多游戏搭建关卡从白盒开始,搭建完白盒,再美化场景。

但是这样的步骤是否存在大量的重复做工?

搭建白盒是为了快速看效果,这可以理解,但是这玩意似乎有很多缺点。比如他毕竟不是最终游戏给到玩家手上的东西,所以他很可能是没有意义的,起码对于玩家来说,玩家都看不到。做少了很可能体现不出游戏效果,做多了又违背了快速看效果的理念,卡在那里不上不下。

最尴尬的是,做完白盒之后,美化关卡往往是需要把白盒全部删除掉,基本没有依赖,一旦后面需要修改一些东西,那要怎么改?去白盒改一次,再在最终场景再修改一次?

其实白盒的作用不仅于此的,还是看各个团队对游戏开发本身的重视度来决定的。

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 度的呢?而很多时候我们为了做细节,实际模型的墙壁还是凹凹凸凸的:

这座小房子的模型不错吧,至少还看得过去,请问,墙上两条缝该不该能爬?如果按照 navMesh,这条缝的底部可是 180 度于平面的,都可以算屋顶了是吧

所以实战中,你不可能用这样精致的模型的 Mesh 来作为 NavMesh 的数据。

所以这时候,白模的价值开始出现了,我们完全可以用白模作为地图的数据,至少是阻挡的数据 —— 我们用一个个形状(不限于 Cube,但最好最多只到三角)拼出地图阻挡,然后给这些形状附加一些属性,就是地图需要的属性,无论 Unity 还是 UE 都是可以给他们挂 Component 来做到附加属性的,尽管 UE 和 Unity 的 Component 是有天壤之别的。

3、用白模能逃避楼梯和斜坡两大坑

而这里顺带一提的是,正常的移动,也不会用 NavMesh 来做,而是用形状射线(比如发出胶囊体,最好是上下锥形射线来做碰撞检测)。如果用射线来做碰撞检测,你就会遭遇经典的“斜坡陷阱”和“楼梯问题”

什么是斜坡陷阱?就是正常来说我们遇到一个斜面,假设我们认为这个角色爬坡力是 60 度(每个角色当然可以不一样的),也就是 < 60 度(能不能等于随你)的斜坡他能走上去,但是我们做射线的时候怎么走上去呢?因为也有不能上去的斜面对吧,所以会有下图现象:

这里我们就做 2d 的切面了

我们可以看到,蓝色的为实际运动的路线(故意抬高了点因为…… 画得不好…… 反正就那意思)—— 因为我们通过法线来得出“拐弯”以后上坡的向量,最终虚线半透明的蓝色,就是角色的移动力,也就是这一帧 (UE 里一个 deltaTime,Unity 一个 FixedUpdate) 的移动距离。红色的箭头,代表了如果是平地,也就是顶视角时,角色的“正常移动距离”,所以红色的长度 == 蓝色虚线的长度,因为都是 1 帧移动量。然后我们可以看到 —— 从游戏玩家的角度来说“上坡的速度比正常的移动速度慢了”,为什么?因为在游戏玩家心目中,移动速度仅仅只是横轴的,所以在 XY(XZ)方向上,玩家的期望,是角色依然能走红线这么多,对吧,因此我们需要用数学的方法,补给他这个距离(怎么补我就不好意思说了,在座的学历大多都比我高,我都知道何况你们……)—— 这其实就是游戏研发中经典的“斜坡陷阱”,因此如果他的地形斜坡这里是个圆(肯定是椭圆公式的圆),甚至是球形(无数个这样的三角形),运算压力就会大不少,而最后精致的模型,是很可能出现这样高精度的形状的,但是白模不会 —— 这是用白模作为地图数据的关键。

而楼梯问题,也是因为墙壁所致,我们看下图

同样也是横截面

每一个小方块都是不高的“小墙壁”,那么角色应该能过去吗?这里是与斜坡冲突的,因为比如我们的爬坡力是 60,这个小墙壁的“墙边”和地面肯定是 90 度,大于 60 度的,移动算法肯定是拒绝上去的,那问题来了,我们直接把角色抬高一个“楼梯高度”妥吗?那如果这里真就这点高度不让走(人不能走,子弹能飞过去)该咋办?或者是这里仅仅是一个小孔,如下图:

是不是就不该过去了?因此楼梯常常是一个十分常见有令人头疼的存在 —— 假如我们用真实世界的眼光去看的话,于是我们怎么做楼梯最妥?很简单,白模是斜面,用角色 IK 和视觉层(也就是覆盖在斜面上的楼梯模型)做碰撞:

激战 2 种角色和她的小宠物(玩具小车)站在楼梯上

黄色的是楼梯的“白盒”也就是地型信息,蓝色的是角色的碰撞(至于为什么 2 锥 1 柱是更好的碰撞,而胶囊体是一个“凑合、还成”的碰撞,那是另一个问题,不在这里进一步讨论),碰撞盒决定了角色可以走上这个斜坡,而注意看角色的脚,是因为模型与模型的碰撞结合 IK 做出来的视觉效果,逻辑和视觉分开运算,产生了我们看起来的这个效果。

4、到此,可以看出白盒的价值了吧?

白盒其实最后是应该被用作游戏地图数据的,不仅仅是是碰撞,并且我们在往上放每一个“盒”的时候就可以给这个“盒”添加属性,比如这个盒子代表了什么(草地还是什么,没准有逻辑作用呢?),再比如这个盒子能不能当地面?能不能当墙壁?能不能当天花板?(这也是另一个细节话题,不在这里展开)。

从项目的开发过程来说,当白盒完成之后,模型美术、地边美术等可以开始做对应的美术资源(UE 称之为“资产”),同时策划可以在这基础上做模型了,而程序做完的功能,也可以直接在这上面运作,最后只要“穿上”美术做来的模型(因为并不是替换白盒,只是白盒不显示了,这个在 Unity 和 UE 都能设置不显示,比如 UE 的 HideInGame 就干这个的)。三路人马一起开工,谁也不依赖于谁,大家都依赖于白盒 —— 项目开发流程解耦了。

所以搭建白盒还浪费时间吗吗?

本文来自微信公众号:千猴马的游戏设计之道 (ID:baima21th),作者:猴与花果山

广告声明:文内含有的对外跳转链接(包括不限于超链接、二维码、口令等形式),用于传递更多信息,节省甄选时间,结果仅供参考,IT之家所有文章均包含本声明。

相关文章

关键词:游戏设计

软媒旗下网站: IT之家 辣品 - 超值导购,优惠券 最会买 - 返利返现优惠券 iPhone之家 Win7之家 Win10之家 Win11之家

软媒旗下软件: 魔方 云日历 酷点桌面 Win7优化大师 Win10优化大师 软媒手机APP应用