很多游戲搭建關(guān)卡從白盒開始，搭建完白盒，再美化場景。
但是這樣的步驟是否存在大量的重復(fù)做工？
搭建白盒是為了快速看效果，這可以理解，但是這玩意似乎有很多缺點(diǎn)。比如他畢竟不是最終游戲給到玩家手上的東西，所以他很可能是沒有意義的，起碼對(duì)于玩家來說，玩家都看不到。做少了很可能體現(xiàn)不出游戲效果，做多了又違背了快速看效果的理念，卡在那里不上不下。
最尷尬的是，做完白盒之后，美化關(guān)卡往往是需要把白盒全部刪除掉，基本沒有依賴，一旦后面需要修改一些東西，那要怎么改？去白盒改一次，再在最終場景再修改一次？
其實(shí)白盒的作用不僅于此的，還是看各個(gè)團(tuán)隊(duì)對(duì)游戲開發(fā)本身的重視度來決定的。
1、白盒對(duì)于游戲開發(fā)流程的意義
首先是游戲開發(fā)流程中為什么需要白盒？這個(gè)矛盾出現(xiàn)在兩種極端上：
一種人認(rèn)為的游戲地圖是“完美無缺的”，就像很多 3A 大作一樣，整個(gè)地圖是一整張，而 UE 玩命在解決的所謂“超大地圖”指的也是這種地圖。我們玩過許多的所謂“頂級(jí) 3A 游戲”，他們里面的場景和建筑物的重復(fù)度是非常低的，除了湊數(shù)的一些房屋外，絕大多數(shù)尤其是迷宮內(nèi)，他都是很認(rèn)真的一個(gè)角落一個(gè)角落硬懟的，比如《古墓麗影》系列的三部曲，《FarCry》系列等，這不是說他們場景里面的一些小物件 (Doodad) 是不重復(fù)的，而是整個(gè)關(guān)卡（地圖）的布局等，都是硬懟的，而不是復(fù)用的。用小島秀夫的話說，就是“歐美人做游戲就是蠻干，硬懟人力”。
在這種認(rèn)知下，做白盒在整個(gè)流程中起到的作用大多是“輔助場景原畫”和“交流確認(rèn)關(guān)卡設(shè)計(jì)”。這怎么理解呢？就是一般我們做游戲的時(shí)候，做一個(gè)場景，得有場景原畫來確定這個(gè)場景的美術(shù)風(fēng)格，包括建筑啊、地形啊、色調(diào)啊等等元素內(nèi)容，然后這個(gè)場景具體是什么樣的，因?yàn)樵O(shè)計(jì)到打光、小物件擺放、刷怪位置、戰(zhàn)斗區(qū)域等，還得有個(gè)白盒來調(diào)整，所以場景原畫 + 白盒 = 確定整個(gè)場景要做咋樣，如果你野蠻的理解這個(gè)流程，完全可以理解為“打個(gè)草稿”，當(dāng)然這個(gè)“草稿”是非常有必要的，因?yàn)闆]有草稿很難做好，而為什么這個(gè)過程會(huì)被貶義為“打個(gè)草稿”，首先是 3D 原畫和模型之間就有著很多沖突，尤其是你原畫出的一些細(xì)節(jié)，做模型又不太好辦，但這些細(xì)節(jié)有十分重要（美術(shù)設(shè)計(jì)意義上的重要）；關(guān)卡設(shè)計(jì)也是如此，很多時(shí)候白盒的希望會(huì)打破模型的表現(xiàn)，或者對(duì)于模型制作有很高的要求，這時(shí)候大家通過白盒來互相妥協(xié)出一個(gè)方案 —— 因此你別小看了這個(gè)“打草稿”的重要性，畢竟這種野蠻的、堆人力的事情，參與的人一旦多了，很難在每個(gè)細(xì)節(jié)上統(tǒng)一好方向和標(biāo)準(zhǔn)，所以我們必須打一個(gè)草稿，盡可能少的出現(xiàn)失敗的制作（主要是會(huì)造成時(shí)間成本的浪費(fèi)）。
另一種人認(rèn)為游戲地圖是“元件組合”的，當(dāng)然這種理解概括的說沒錯(cuò)，事實(shí)上這也是游戲行業(yè)一脈相承的“老辦法”，就是你做了很多個(gè)比如房屋的模型，然后把它放在地圖上的不同地區(qū)，轉(zhuǎn)轉(zhuǎn)不同的角度，然后這些房子之類的東西上有一些小細(xì)節(jié)是可拆卸的，比如這邊這座房子上個(gè)房間，那邊那個(gè)房子多個(gè)尖頂，都是細(xì)微差距，這種情況下，確實(shí)直接從從原畫到 3D 模型然后再擺放關(guān)卡是合適的，正如我們玩很多游戲的地圖編輯器，比如《魔法門之英雄無敵系列》、《帝國時(shí)代》系列等都是如此。而因?yàn)槟Ｐ秃苋菀琢慨a(chǎn)，或者即便沒達(dá)到量，因?yàn)檫@種復(fù)制思路在，所以我有幾個(gè)代表性的模型，就直接可以做關(guān)卡了，細(xì)節(jié)再調(diào)整。這種情況下，確實(shí)白盒的意義不大，整個(gè)流程中是不太需要白盒的。
假如單純的從美術(shù)的意義上來說，那么做不做白盒，是否浪費(fèi)時(shí)間，完全是看游戲項(xiàng)目的地圖（關(guān)卡）的制作思路和調(diào)性的，以上兩個(gè)極端風(fēng)格和中間融合的做法，其實(shí)都是合理的，所以你說做白盒浪費(fèi)時(shí)間，不到具體設(shè)計(jì)需求是看不出來的。
但是就憑這一點(diǎn)，你要全盤的說白盒工作純屬浪費(fèi)，是不合適的，因?yàn)橛螒蜷_發(fā)，就說這塊地圖（關(guān)卡）制作上，做美術(shù)只是其中的一部分工作，甚至可以被認(rèn)為是 plus 的工作，最核心的內(nèi)容還是地圖能玩起來，所以你得接著看：
2、白盒是游戲數(shù)據(jù)中的一部分
我們?yōu)槭裁葱枰霭缀?？有一個(gè)十分重要的原因，就是白盒的數(shù)據(jù)，對(duì)于懂得游戲開發(fā)的團(tuán)隊(duì)來說，可以是一個(gè)最終的地圖數(shù)據(jù)，是的，是 Map 數(shù)據(jù)，但不是完整的 scenario 數(shù)據(jù)。Map 數(shù)據(jù)就是地圖中的地形等信息。
回到最原始的邏輯中，比如我們現(xiàn)在要做一個(gè)標(biāo)準(zhǔn)的 JRPG，那么他的地圖數(shù)據(jù)完全可以是一個(gè)二維數(shù)組，每一個(gè)單元中的數(shù)據(jù)就是一個(gè)單元格的信息。再比如《火紋系列》這種標(biāo)準(zhǔn)的 SLG 游戲，即便他渲染的是 3D，他一個(gè)格子內(nèi)的數(shù)據(jù)依然需要：
1，它是什么地形：森林、平地還是河流，這和 UI 有直接關(guān)系。
2，它的閃避是多少：我們知道火紋里面不同單元格是會(huì)帶來閃避加成的，這是游戲規(guī)則。
3，它回不回血：火紋里面一些單元格上站的角色每回合會(huì)恢復(fù)生命值。
4，它的 Cost 數(shù)組：也就是每一種行動(dòng)方式的單位走上去會(huì)消耗多少移動(dòng)力。
這些信息組成一個(gè) Struct MapGrid，然后地圖信息就是一個(gè) Array<Array<MapGrid>>。為什么需要這樣的信息，也是為了處理游戲中角色要在地圖上行動(dòng)。
同理的，任何類型的游戲，都會(huì)需要這樣一個(gè)結(jié)構(gòu)，我們假定這個(gè) 3D 游戲做的是一個(gè)法環(huán)一樣的魂類游戲，或者是一個(gè)忍龍，再或者是怪物獵人這樣的游戲。然后這個(gè)游戲中角色能走路、放技能（技能就會(huì)帶位移）、能跳；作為職業(yè)區(qū)別，有些職業(yè)可以爬墻，但其他職業(yè)不能，有些職業(yè)踢墻反彈（就如街霸里面春麗跳到版邊可以跳回來一樣）。所以在我們做角色移動(dòng)的時(shí)候，就需要一系列地圖信息。
說到這里可能有新手菜鳥會(huì)說，那我們可以用 NavMesh，然后直接用做完的模型作為 Mesh 不就來了嗎？那你再仔細(xì)想想這些問題能解決嗎：
1，如果我游戲中角色都能跳，也有角色可以飛，請(qǐng)問你 NavMesh 如何幫我飛的角色尋路？NavMesh 本質(zhì)上是把 Mesh 的三角面作為 Grid，把相鄰三角面作為 "next" 的 AStar（AStar 通常用于把 Tilebased 格子的規(guī)則作為 next，比如我們上面說的火紋系列的地圖），但是我角色并沒有貼住地面，你如何做 NavMesh？你說投影到地面上，那人走不過的矮墻，我飛還飛不過去嗎？
2，墻壁、地板、天花板 —— 這也是動(dòng)作游戲中最經(jīng)典的移動(dòng)問題，首先如何判斷是一堵墻壁？與世界坐標(biāo)系的 (UE 是 XY 平面，Unity 是 XZ 平面）夾角大于等于 x 度（比如 60 度）就可以認(rèn)定為墻壁嗎？60 度的墻壁爬上去沒問題，120 度的呢？而很多時(shí)候我們?yōu)榱俗黾?xì)節(jié)，實(shí)際模型的墻壁還是凹凹凸凸的：
所以實(shí)戰(zhàn)中，你不可能用這樣精致的模型的 Mesh 來作為 NavMesh 的數(shù)據(jù)。
所以這時(shí)候，白模的價(jià)值開始出現(xiàn)了，我們完全可以用白模作為地圖的數(shù)據(jù)，至少是阻擋的數(shù)據(jù) —— 我們用一個(gè)個(gè)形狀（不限于 Cube，但最好最多只到三角）拼出地圖阻擋，然后給這些形狀附加一些屬性，就是地圖需要的屬性，無論 Unity 還是 UE 都是可以給他們掛 Component 來做到附加屬性的，盡管 UE 和 Unity 的 Component 是有天壤之別的。
3、用白模能逃避樓梯和斜坡兩大坑
而這里順帶一提的是，正常的移動(dòng)，也不會(huì)用 NavMesh 來做，而是用形狀射線（比如發(fā)出膠囊體，最好是上下錐形射線來做碰撞檢測）。如果用射線來做碰撞檢測，你就會(huì)遭遇經(jīng)典的“斜坡陷阱”和“樓梯問題”
什么是斜坡陷阱？就是正常來說我們遇到一個(gè)斜面，假設(shè)我們認(rèn)為這個(gè)角色爬坡力是 60 度（每個(gè)角色當(dāng)然可以不一樣的），也就是 < 60 度（能不能等于隨你）的斜坡他能走上去，但是我們做射線的時(shí)候怎么走上去呢？因?yàn)橐灿胁荒苌先サ男泵鎸?duì)吧，所以會(huì)有下圖現(xiàn)象：
我們可以看到，藍(lán)色的為實(shí)際運(yùn)動(dòng)的路線（故意抬高了點(diǎn)因?yàn)椤?畫得不好…… 反正就那意思）—— 因?yàn)槲覀兺ㄟ^法線來得出“拐彎”以后上坡的向量，最終虛線半透明的藍(lán)色，就是角色的移動(dòng)力，也就是這一幀 (UE 里一個(gè) deltaTime，Unity 一個(gè) FixedUpdate) 的移動(dòng)距離。紅色的箭頭，代表了如果是平地，也就是頂視角時(shí)，角色的“正常移動(dòng)距離”，所以紅色的長度 == 藍(lán)色虛線的長度，因?yàn)槎际?1 幀移動(dòng)量。然后我們可以看到 —— 從游戲玩家的角度來說“上坡的速度比正常的移動(dòng)速度慢了”，為什么？因?yàn)樵谟螒蛲婕倚哪恐?，移?dòng)速度僅僅只是橫軸的，所以在 XY（XZ）方向上，玩家的期望，是角色依然能走紅線這么多，對(duì)吧，因此我們需要用數(shù)學(xué)的方法，補(bǔ)給他這個(gè)距離（怎么補(bǔ)我就不好意思說了，在座的學(xué)歷大多都比我高，我都知道何況你們……）—— 這其實(shí)就是游戲研發(fā)中經(jīng)典的“斜坡陷阱”，因此如果他的地形斜坡這里是個(gè)圓（肯定是橢圓公式的圓），甚至是球形（無數(shù)個(gè)這樣的三角形），運(yùn)算壓力就會(huì)大不少，而最后精致的模型，是很可能出現(xiàn)這樣高精度的形狀的，但是白模不會(huì) —— 這是用白模作為地圖數(shù)據(jù)的關(guān)鍵。
而樓梯問題，也是因?yàn)閴Ρ谒?，我們看下圖
每一個(gè)小方塊都是不高的“小墻壁”，那么角色應(yīng)該能過去嗎？這里是與斜坡沖突的，因?yàn)楸热缥覀兊呐榔铝κ?60，這個(gè)小墻壁的“墻邊”和地面肯定是 90 度，大于 60 度的，移動(dòng)算法肯定是拒絕上去的，那問題來了，我們直接把角色抬高一個(gè)“樓梯高度”妥嗎？那如果這里真就這點(diǎn)高度不讓走（人不能走，子彈能飛過去）該咋辦？或者是這里僅僅是一個(gè)小孔，如下圖：
是不是就不該過去了？因此樓梯常常是一個(gè)十分常見有令人頭疼的存在 —— 假如我們用真實(shí)世界的眼光去看的話，于是我們?cè)趺醋鰳翘葑钔?？很簡單，白模是斜面，用角?IK 和視覺層（也就是覆蓋在斜面上的樓梯模型）做碰撞：
黃色的是樓梯的“白盒”也就是地型信息，藍(lán)色的是角色的碰撞（至于為什么 2 錐 1 柱是更好的碰撞，而膠囊體是一個(gè)“湊合、還成”的碰撞，那是另一個(gè)問題，不在這里進(jìn)一步討論），碰撞盒決定了角色可以走上這個(gè)斜坡，而注意看角色的腳，是因?yàn)槟Ｐ团c模型的碰撞結(jié)合 IK 做出來的視覺效果，邏輯和視覺分開運(yùn)算，產(chǎn)生了我們看起來的這個(gè)效果。
4、到此，可以看出白盒的價(jià)值了吧？
白盒其實(shí)最后是應(yīng)該被用作游戲地圖數(shù)據(jù)的，不僅僅是是碰撞，并且我們?cè)谕戏琶恳粋€(gè)“盒”的時(shí)候就可以給這個(gè)“盒”添加屬性，比如這個(gè)盒子代表了什么（草地還是什么，沒準(zhǔn)有邏輯作用呢？），再比如這個(gè)盒子能不能當(dāng)?shù)孛妫磕懿荒墚?dāng)墻壁？能不能當(dāng)天花板？（這也是另一個(gè)細(xì)節(jié)話題，不在這里展開）。
從項(xiàng)目的開發(fā)過程來說，當(dāng)白盒完成之后，模型美術(shù)、地邊美術(shù)等可以開始做對(duì)應(yīng)的美術(shù)資源（UE 稱之為“資產(chǎn)”），同時(shí)策劃可以在這基礎(chǔ)上做模型了，而程序做完的功能，也可以直接在這上面運(yùn)作，最后只要“穿上”美術(shù)做來的模型（因?yàn)椴⒉皇翘鎿Q白盒，只是白盒不顯示了，這個(gè)在 Unity 和 UE 都能設(shè)置不顯示，比如 UE 的 HideInGame 就干這個(gè)的）。三路人馬一起開工，誰也不依賴于誰，大家都依賴于白盒 —— 項(xiàng)目開發(fā)流程解耦了。
所以搭建白盒還浪費(fèi)時(shí)間嗎嗎？
本文來自微信公眾號(hào)：千猴馬的游戲設(shè)計(jì)之道 （ID：baima21th），作者：猴與花果山
廣告聲明：文內(nèi)含有的對(duì)外跳轉(zhuǎn)鏈接（包括不限于超鏈接、二維碼、口令等形式），用于傳遞更多信息，節(jié)省甄選時(shí)間，結(jié)果僅供參考，IT之家所有文章均包含本聲明。