關卡原型製做思路

虛幻4本次示例中，有一個關於關卡製做規範的例子LevelDesign_workflow：

第一步：搭基本的、可玩的場景關卡，虛幻提供了很是強大的BSP編輯功能（Convex功能），能夠用來進行關卡原型的製做。這個關卡只要可玩就好，通常由編關策劃搭出來，基本都是些Box這樣的基本物體，知足關卡的可玩性便可。

第二步：替換一些主體模型，主體模型通常應該基於已經固化的玩法關卡來製做，不該改變玩法關卡的主體結構。

第三部，打光、賦予主題場景的材質，把場景的大效果給弄出來。

第四步：添加細節物體和細節表現。

這個就是在國外比較成熟的關卡原型思路，是一種很是好的思路，筆者私覺得這種方法對國內的遊戲開發遇到的一系列問題也有很大的參考意義，結合筆者獲得的資訊和我的的理解，展開一下，供諸位戰友參考。

 

過去咱們有些團隊作關卡，美術得等把關卡總體都搭個差很少後纔會交付策劃，而後策劃開始佈置怪物、觸發器、腳本，這種方法顯而易見的具備下述問題：

策劃一開始必須考慮徹底整個關卡的樣子和流程，不然美術一旦開始，資源堆上來後，再去調整就是巨大的工做量和士氣損失，對團隊團結也是很是不利的。可是，平心而論，這對非山寨的創意性項目基本是不可能的，創意期的策劃調整自己就是客觀規律，對遊戲將來也是有好處的，日本的製做人和策劃已經足夠牛逼了，還會"對不起，我要修改部分規格"，況且中國策劃呢？

還有就是協做的問題，通常來講，美術正在改場景的時候，策劃是須要停工的，固然好的引擎能夠經過層或者其餘什麼方式來解決這些問題，可是根本上這個整合的工做量是客觀存在的。美術提交給策劃的美術資源是否能夠認爲是最終資源？這個基本是不可能的。提交給策劃後，策劃一方面要在裏面佈置觸發器、怪物，另外一方面要去通知美術修改地圖和資源，這中間在整合上須要耗費大筆的工做量。

工做時間的無心義浪費：美術搭建整個關卡的時間通常是須要以月來計，在這個過程當中策劃只能撂荒，固然，團隊中總有事情須要去作，策劃也通常不會說沒事可作，可是若是一個策劃的業務重點是負責這個關卡，卻老是不能把精力和時間花在這個關卡上，這不是很奇怪嗎？另一點來講，當策劃開工的時候，美術基本上也撂荒了。至少在關卡製做的初期，這基本上是一個單線程的工做，同時只能有一條線在執行這個工做，另外一條線只能乾等着。等着等着，黃花菜就這麼涼了。

最後談一個引擎部門可能會比較敏感的話題：關卡出來先後，有三種選擇：出來前程序進駐觀測性能和內存問題，出來後觀測，以及策劃作完後觀測。不幸的是通常的團隊都會選擇後兩種方案，而後……我相信這個時候引擎的戰友們通常的第一感受都是"我勒個去，美術又暴走了"！

上面這些若是您的項目全都很好地解決了，壕，友乎？筆者真的很想去大家的項目工做，由於大家創造了能夠載入人類史的奇蹟。

若是沒有，不用擔憂，筆者所知的項目多數都跟大家同樣，這個意義上大家並不是沒有競爭力，可是接下來纔是最好玩的事情：

程序通知美術說，大家爆了內存的菊花，這個不行，限期整改。

美術說，這個咱們作不了主，得問策劃。

策劃說：這個不是咱們的問題，美術本身的事情，另外，咱們的需求就是這樣，一個場景必須得四種不一樣的美術風格。

最後鬧到製做人那裏。

程序一句話：大家怎麼決定我無論，XP下Win32內存就2GB，Large Address到3GB得玩家本身會搞，如今內存爆了，微軟來它也解決不了，大家本身看着辦吧。

製做人：啊，這麼嚴重？都給我推倒重來！

幾個月的工做白費，美術和策劃跟引擎的樑子就是這麼結下來的。

 

把問題回到開頭，咱們發現這個中間有個最核心的問題：

策劃是否真的須要一個場景的美術資源徹底出來？

我想，答案應該是否認的，雖然我不是策劃，可是我實在想不出來爲何會有這個需求：策劃這個工種的重點就應該是玩法、調度、整合，不管哪一個，跟場景最後的顯示效果有什麼根本性的關係嗎？

固然，你能夠說一些小關係，好比一個破敗的小村裏不能作金碧輝煌的建築，但這個你只要提了這個需求我想美術也不會二到偏要在一個教堂里布置一套舊館的設備。

建議咱們的製做人均可以問問策劃是否有這種需求，讓他們解釋清楚必需要等待美術所有資源的理由。

事實上我本身接觸到的策劃都表示："咱們其實只須要這裏是個概念上的村子就行，你種倆房子就能夠了，不須要種上十幾套房子"，這樣。真正去摳"村子就得有十幾棟房子"這樣的人反而是美術……

 

這個根本問題一旦解決，接下來其實就好辦了：

1. 策劃但願這個場景怎麼玩，本身是最瞭解的，用編輯器已有的工具搭建一套原型出來，擺位置、設屬性、刷高度這種操做還學不會的話就不是技術問題，而是智商問題了。實在真不行，配一個兼職美術，就一個，兼職幫他作就好。
2. 作完後，本身往裏面布怪、布任務、布邏輯、布腳本。
3. 而後本身進去測測怎麼回事，這個過程當中發現的問題，直接調整原型關卡便可。
4. 最後，把這個關卡拿給其餘成員審批，你們都以爲ok後，再提交美術開工。
5. 美術一開始先把大結構、框架性資源放進去，好比房子、城牆、柱子這之類的。
6. 裝完後，提交引擎查看一版資源佔用，性能和內存是否Ok。
7. 若是不Ok，就得好好考慮考慮地圖的大小和分區問題了。
8. 若是Ok，開始往裏面放細節物體。
9. 每放一段時間，就讓引擎審批一次，或者製做一個自動化工具來查資源。一旦超了就開始玩加減遊戲——減一件，加一件，減10MB，加10MB。

這樣製做出來的場景要仍是有內存和性能問題，那基本是引擎業務不過關。

 

並且，作加法老是給人但願，辛辛苦苦作了三個月的東西引擎一句話全都推翻了，這樣的隊伍就算目標再明確，遲早也會分崩離析的。

 

並且在這個過程當中，很有一些Tricks能夠發掘：

測量和標尺：

兩個石柱子，A能跳過去，B就跳不過去，結果我這裏要搭個機關，正巧是要能跳過去的，可是還以爲B好看，咋整？無法整。

如今，策劃本身在製做的時候，就須要把標尺打清楚，後面美術製做資源的時候，跟這種關卡玩法有關的資源必須嚴格按照標尺執行，說是1.3米就是1.3米，多一分少一分都不行，這纔是專業作遊戲的思路。好傢伙一個城市巴不得全部的建築都不同的標尺，拼一塊兒都費勁，哪一個老師是這麼教你作遊戲的？ 您仍是去作CG和影視吧，遊戲太屈才了。

 

物理碰撞和Navigation面的簡化：

基本上不須要再作了，由於關卡最一開始策劃作出來的原型，直接拿這個轉化成物理碰撞和Navigation就八九不離十。

UE4有另一個示例：ShooterGame，展現了這一點。

默認加載的場景：這裏麪粉色的線條和我正在選中的線，是Blocking Volume，專門用來作阻擋的。這些基本都是一開始搭建場景原型的BSP，直接用Convert轉化成的。

細節能夠很複雜，可是碰撞很是簡單，同一視角下的純碰撞：

國內開發比較多的時候會就接細節物體的細節碰撞問題——太細了致使各類不可控的問題發生，你要按照這種方式作怎麼可能會出問題呢？

模型能夠很高貴，可是不影響碰撞和Navigation能夠很簡單。

 

另外一個場景徹底就是原型，剛剛開始製做：

可供你們參考。

 

建議你們瞭解一下，上海那邊作主機遊戲的戰友們應該對這些標準比較熟悉，適不適用於網絡遊戲？我不清楚，可是若是按照過去的那種作法遇到如此多的問題，爲何不嘗試一下新的思路，您說呢？