很多游戲搭建關(guān)卡從白盒開始，搭建完白盒，再美化場景。

但是這樣的步驟是否存在大量的重復做工？

搭建白盒是為了快速看效果，這可以理解，但是這玩意似乎有很多缺點。比如他畢竟不是最終游戲給到玩家手上的東西，所以他很可能是沒有意義的，起碼對于玩家來說，玩家都看不到。做少了很可能體現(xiàn)不出游戲效果，做多了又違背了快速看效果的理念，卡在那里不上不下。

最尷尬的是，做完白盒之后，美化關(guān)卡往往是需要把白盒全部刪除掉，基本沒有依賴，一旦后面需要修改一些東西，那要怎么改？去白盒改一次，再在最終場景再修改一次？

其實白盒的作用不僅于此的，還是看各個團隊對游戲開發(fā)本身的重視度來決定的。

1、白盒對于游戲開發(fā)流程的意義

首先是游戲開發(fā)流程中為什么需要白盒？這個矛盾出現(xiàn)在兩種極端上：

一種人認為的游戲地圖是“完美無缺的”，就像很多 3A 大作一樣，整個地圖是一整張，而 UE 玩命在解決的所謂“超大地圖”指的也是這種地圖。我們玩過許多的所謂“頂級 3A 游戲”，他們里面的場景和建筑物的重復度是非常低的，除了湊數(shù)的一些房屋外，絕大多數(shù)尤其是迷宮內(nèi)，他都是很認真的一個角落一個角落硬懟的，比如《古墓麗影》系列的三部曲，《FarCry》系列等，這不是說他們場景里面的一些小物件 (Doodad) 是不重復的，而是整個關(guān)卡（地圖）的布局等，都是硬懟的，而不是復用的。用小島秀夫的話說，就是“歐美人做游戲就是蠻干，硬懟人力”。

在這種認知下，做白盒在整個流程中起到的作用大多是“輔助場景原畫”和“交流確認關(guān)卡設計”。這怎么理解呢？就是一般我們做游戲的時候，做一個場景，得有場景原畫來確定這個場景的美術(shù)風格，包括建筑啊、地形啊、色調(diào)啊等等元素內(nèi)容，然后這個場景具體是什么樣的，因為設計到打光、小物件擺放、刷怪位置、戰(zhàn)斗區(qū)域等，還得有個白盒來調(diào)整，所以場景原畫 + 白盒 = 確定整個場景要做咋樣，如果你野蠻的理解這個流程，完全可以理解為“打個草稿”，當然這個“草稿”是非常有必要的，因為沒有草稿很難做好，而為什么這個過程會被貶義為“打個草稿”，首先是 3D 原畫和模型之間就有著很多沖突，尤其是你原畫出的一些細節(jié)，做模型又不太好辦，但這些細節(jié)有十分重要（美術(shù)設計意義上的重要）；關(guān)卡設計也是如此，很多時候白盒的希望會打破模型的表現(xiàn)，或者對于模型制作有很高的要求，這時候大家通過白盒來互相妥協(xié)出一個方案 —— 因此你別小看了這個“打草稿”的重要性，畢竟這種野蠻的、堆人力的事情，參與的人一旦多了，很難在每個細節(jié)上統(tǒng)一好方向和標準，所以我們必須打一個草稿，盡可能少的出現(xiàn)失敗的制作（主要是會造成時間成本的浪費）。

另一種人認為游戲地圖是“元件組合”的，當然這種理解概括的說沒錯，事實上這也是游戲行業(yè)一脈相承的“老辦法”，就是你做了很多個比如房屋的模型，然后把它放在地圖上的不同地區(qū)，轉(zhuǎn)轉(zhuǎn)不同的角度，然后這些房子之類的東西上有一些小細節(jié)是可拆卸的，比如這邊這座房子上個房間，那邊那個房子多個尖頂，都是細微差距，這種情況下，確實直接從從原畫到 3D 模型然后再擺放關(guān)卡是合適的，正如我們玩很多游戲的地圖編輯器，比如《魔法門之英雄無敵系列》、《帝國時代》系列等都是如此。而因為模型很容易量產(chǎn)，或者即便沒達到量，因為這種復制思路在，所以我有幾個代表性的模型，就直接可以做關(guān)卡了，細節(jié)再調(diào)整。這種情況下，確實白盒的意義不大，整個流程中是不太需要白盒的。

假如單純的從美術(shù)的意義上來說，那么做不做白盒，是否浪費時間，完全是看游戲項目的地圖（關(guān)卡）的制作思路和調(diào)性的，以上兩個極端風格和中間融合的做法，其實都是合理的，所以你說做白盒浪費時間，不到具體設計需求是看不出來的。

但是就憑這一點，你要全盤的說白盒工作純屬浪費，是不合適的，因為游戲開發(fā)，就說這塊地圖（關(guān)卡）制作上，做美術(shù)只是其中的一部分工作，甚至可以被認為是 plus 的工作，最核心的內(nèi)容還是地圖能玩起來，所以你得接著看：

2、白盒是游戲數(shù)據(jù)中的一部分

我們?yōu)槭裁葱枰霭缀校坑幸粋€十分重要的原因，就是白盒的數(shù)據(jù)，對于懂得游戲開發(fā)的團隊來說，可以是一個最終的地圖數(shù)據(jù)，是的，是 Map 數(shù)據(jù)，但不是完整的 scenario 數(shù)據(jù)。Map 數(shù)據(jù)就是地圖中的地形等信息。

回到最原始的邏輯中，比如我們現(xiàn)在要做一個標準的 JRPG，那么他的地圖數(shù)據(jù)完全可以是一個二維數(shù)組，每一個單元中的數(shù)據(jù)就是一個單元格的信息。再比如《火紋系列》這種標準的 SLG 游戲，即便他渲染的是 3D，他一個格子內(nèi)的數(shù)據(jù)依然需要：

1，它是什么地形：森林、平地還是河流，這和 UI 有直接關(guān)系。

2，它的閃避是多少：我們知道火紋里面不同單元格是會帶來閃避加成的，這是游戲規(guī)則。

3，它回不回血：火紋里面一些單元格上站的角色每回合會恢復生命值。

4，它的 Cost 數(shù)組：也就是每一種行動方式的單位走上去會消耗多少移動力。

這些信息組成一個 Struct MapGrid，然后地圖信息就是一個 Array<Array<MapGrid>>。為什么需要這樣的信息，也是為了處理游戲中角色要在地圖上行動。

同理的，任何類型的游戲，都會需要這樣一個結(jié)構(gòu)，我們假定這個 3D 游戲做的是一個法環(huán)一樣的魂類游戲，或者是一個忍龍，再或者是怪物獵人這樣的游戲。然后這個游戲中角色能走路、放技能（技能就會帶位移）、能跳；作為職業(yè)區(qū)別，有些職業(yè)可以爬墻，但其他職業(yè)不能，有些職業(yè)踢墻反彈（就如街霸里面春麗跳到版邊可以跳回來一樣）。所以在我們做角色移動的時候，就需要一系列地圖信息。

說到這里可能有新手菜鳥會說，那我們可以用 NavMesh，然后直接用做完的模型作為 Mesh 不就來了嗎？那你再仔細想想這些問題能解決嗎：

1，如果我游戲中角色都能跳，也有角色可以飛，請問你 NavMesh 如何幫我飛的角色尋路？NavMesh 本質(zhì)上是把 Mesh 的三角面作為 Grid，把相鄰三角面作為 "next" 的 AStar（AStar 通常用于把 Tilebased 格子的規(guī)則作為 next，比如我們上面說的火紋系列的地圖），但是我角色并沒有貼住地面，你如何做 NavMesh？你說投影到地面上，那人走不過的矮墻，我飛還飛不過去嗎？

2，墻壁、地板、天花板 —— 這也是動作游戲中最經(jīng)典的移動問題，首先如何判斷是一堵墻壁？與世界坐標系的 (UE 是 XY 平面，Unity 是 XZ 平面）夾角大于等于 x 度（比如 60 度）就可以認定為墻壁嗎？60 度的墻壁爬上去沒問題，120 度的呢？而很多時候我們?yōu)榱俗黾毠?jié)，實際模型的墻壁還是凹凹凸凸的：

所以實戰(zhàn)中，你不可能用這樣精致的模型的 Mesh 來作為 NavMesh 的數(shù)據(jù)。

所以這時候，白模的價值開始出現(xiàn)了，我們完全可以用白模作為地圖的數(shù)據(jù)，至少是阻擋的數(shù)據(jù) —— 我們用一個個形狀（不限于 Cube，但最好最多只到三角）拼出地圖阻擋，然后給這些形狀附加一些屬性，就是地圖需要的屬性，無論 Unity 還是 UE 都是可以給他們掛 Component 來做到附加屬性的，盡管 UE 和 Unity 的 Component 是有天壤之別的。

3、用白模能逃避樓梯和斜坡兩大坑

而這里順帶一提的是，正常的移動，也不會用 NavMesh 來做，而是用形狀射線（比如發(fā)出膠囊體，最好是上下錐形射線來做碰撞檢測）。如果用射線來做碰撞檢測，你就會遭遇經(jīng)典的“斜坡陷阱”和“樓梯問題”

什么是斜坡陷阱？就是正常來說我們遇到一個斜面，假設我們認為這個角色爬坡力是 60 度（每個角色當然可以不一樣的），也就是 < 60 度（能不能等于隨你）的斜坡他能走上去，但是我們做射線的時候怎么走上去呢？因為也有不能上去的斜面對吧，所以會有下圖現(xiàn)象：

我們可以看到，藍色的為實際運動的路線（故意抬高了點因為…… 畫得不好…… 反正就那意思）—— 因為我們通過法線來得出“拐彎”以后上坡的向量，最終虛線半透明的藍色，就是角色的移動力，也就是這一幀 (UE 里一個 deltaTime，Unity 一個 FixedUpdate) 的移動距離。紅色的箭頭，代表了如果是平地，也就是頂視角時，角色的“正常移動距離”，所以紅色的長度 == 藍色虛線的長度，因為都是 1 幀移動量。然后我們可以看到 —— 從游戲玩家的角度來說“上坡的速度比正常的移動速度慢了”，為什么？因為在游戲玩家心目中，移動速度僅僅只是橫軸的，所以在 XY（XZ）方向上，玩家的期望，是角色依然能走紅線這么多，對吧，因此我們需要用數(shù)學的方法，補給他這個距離（怎么補我就不好意思說了，在座的學歷大多都比我高，我都知道何況你們……）—— 這其實就是游戲研發(fā)中經(jīng)典的“斜坡陷阱”，因此如果他的地形斜坡這里是個圓（肯定是橢圓公式的圓），甚至是球形（無數(shù)個這樣的三角形），運算壓力就會大不少，而最后精致的模型，是很可能出現(xiàn)這樣高精度的形狀的，但是白模不會 —— 這是用白模作為地圖數(shù)據(jù)的關(guān)鍵。

而樓梯問題，也是因為墻壁所致，我們看下圖

每一個小方塊都是不高的“小墻壁”，那么角色應該能過去嗎？這里是與斜坡沖突的，因為比如我們的爬坡力是 60，這個小墻壁的“墻邊”和地面肯定是 90 度，大于 60 度的，移動算法肯定是拒絕上去的，那問題來了，我們直接把角色抬高一個“樓梯高度”妥嗎？那如果這里真就這點高度不讓走（人不能走，子彈能飛過去）該咋辦？或者是這里僅僅是一個小孔，如下圖：

是不是就不該過去了？因此樓梯常常是一個十分常見有令人頭疼的存在 —— 假如我們用真實世界的眼光去看的話，于是我們怎么做樓梯最妥？很簡單，白模是斜面，用角色 IK 和視覺層（也就是覆蓋在斜面上的樓梯模型）做碰撞：

黃色的是樓梯的“白盒”也就是地型信息，藍色的是角色的碰撞（至于為什么 2 錐 1 柱是更好的碰撞，而膠囊體是一個“湊合、還成”的碰撞，那是另一個問題，不在這里進一步討論），碰撞盒決定了角色可以走上這個斜坡，而注意看角色的腳，是因為模型與模型的碰撞結(jié)合 IK 做出來的視覺效果，邏輯和視覺分開運算，產(chǎn)生了我們看起來的這個效果。

4、到此，可以看出白盒的價值了吧？

白盒其實最后是應該被用作游戲地圖數(shù)據(jù)的，不僅僅是是碰撞，并且我們在往上放每一個“盒”的時候就可以給這個“盒”添加屬性，比如這個盒子代表了什么（草地還是什么，沒準有邏輯作用呢？），再比如這個盒子能不能當?shù)孛妫磕懿荒墚攭Ρ?？能不能當天花板？（這也是另一個細節(jié)話題，不在這里展開）。

從項目的開發(fā)過程來說，當白盒完成之后，模型美術(shù)、地邊美術(shù)等可以開始做對應的美術(shù)資源（UE 稱之為“資產(chǎn)”），同時策劃可以在這基礎上做模型了，而程序做完的功能，也可以直接在這上面運作，最后只要“穿上”美術(shù)做來的模型（因為并不是替換白盒，只是白盒不顯示了，這個在 Unity 和 UE 都能設置不顯示，比如 UE 的 HideInGame 就干這個的）。三路人馬一起開工，誰也不依賴于誰，大家都依賴于白盒 —— 項目開發(fā)流程解耦了。

所以搭建白盒還浪費時間嗎嗎？

本文來自微信公眾號：千猴馬的游戲設計之道 （ID：baima21th），作者：猴與花果山

廣告聲明：文內(nèi)含有的對外跳轉(zhuǎn)鏈接（包括不限于超鏈接、二維碼、口令等形式），用于傳遞更多信息，節(jié)省甄選時間，結(jié)果僅供參考，IT之家所有文章均包含本聲明。