創造開放世界——《看火人》場景設計

Firewatch是屢獲大獎的冒險遊戲，有類似於開放世界的畫面表現。

本講座要點：

• 多人編輯同一個大場景
• 非常清晰的闡述了他們採用的大場景的手工流式載入方案（影片中額外介紹了基礎原理，這裡沒摘錄）
• 樹的LOD和風、場景製作的懸崖等個別細節
• 非常好的展示如何從概念設計製作地圖，設計穿行過程。
  

影片：https://www.youtube.com/watch?v=hTqmk1Zs_1I

多人編輯


工程中，有強烈的多人編輯同一場景的需要。他們使用一個Unity外掛：Sectr Complete，對場景、配置進行拆分和合並，每個人編輯自己的區塊。最終拆分非常細，見下圖：



Steaming流式載入

漫遊時，區塊載入規則是手工編輯的。地圖分為多個區域，連線點是固定的，綠色門是解除安裝，紫色門是載入，如下圖：



18:30開始有一段3分鐘的影片，演示了漫遊過程，同時提示各種資料的載入和解除安裝。其中要點：

• 手工設定各個路口對應的載入。注意到看火人是受限的漫遊，由於路點有限，透過設計和人工編輯，對地塊的可見性做了最最佳化的控制。
• 人工最最佳化的例子：例如上圖中湖泊（Lakeside）的U型彎，由於玩家看到湖之後會迅速轉彎，所以接近湖的時候，直接同時載入了U型轉彎後的地圖（CanyonLake）。
• 一般只有3塊左右的真實地塊同時存在
• 平時有假的遠景塊，以及低模版的地形
• 還可以做非常細緻的載入。有一段，角色在山上，遠景在山崖下。離山崖中距離的情況下，看不見山下的地形，只顯示樹木，等到接近（可能只有30米的距離）的情況下才顯示其地形。而當主角爬下山崖後，立即就直接解除安裝了整個山上，因為不再看得見。
• 一條長的峽谷，切分成了4段載入
  

同時，可以用這個技術來載入不同劇情版本的地塊。例如主角的瞭望塔，有5個不同的版本，從第一天剛上班最乾淨的版本，到多天後最後放了很多東西亂糟糟的版本。

地形使用商城的Stitcher外掛來確保拼接，但是總的來說，要靠放各種石頭等來遮掩接縫。

植被和地形

樹木在遊戲的大部分時候都佔據了一半左右的畫面面積，所以很重要。

在Unity4的Tree Creator是Speed Tree的嚴重縮水版，功能很弱，到Unity5才支援Speed Tree。本作基於Unity4，樹是直接做的模型。




製作時，注意樹的下部較為細緻，上部簡單一些。LOD1和2最大的差別在於關閉大多數部件不再投影。從影片來看，這些樹LOD切換時，幾乎完全看不出來（除了LOD2->LOD3差別略大）。本遊戲不使用使用平滑LOD切換，該演算法在切換時渲染量會翻倍，所以做出高質量、能直接切換的LOD同時能保證效能和畫面效果。

LOD沒有使用Simplygon這樣的工具，手工編輯。因為資源量少，手工編輯完全可行，同時也不用進行新工具的學習。但是對於資源規模大的工程這種中介軟體是有價值的。

使用自定義的shader修改半透明裁剪引數，遠處的樹使用更低的裁剪，這樣遠處的樹看起來更鼓一些。


使用頂點著色器動畫來實現風（之前在Brutal Legend使用過的技術），由美術對節點進行顏色標註。

• 紅色是縱向的搖動。樹的頂部基本上都是縱向
• 綠色表示樹枝幹的搖動
• 藍色表示葉子的擺動
  

有影片，35:20。（按：和Unity中speed tree的區別大概是不含風向？speed tree似乎是物理模擬，每隔一段時間進行一次推力驅動）

地形

使用Unity地形。簡單雕刻之後就有效果。



Unity的地形貼圖預設是從頂檢視垂直對映的，所以懸崖上有嚴重的拉伸現象。如果使用Box對映的話可以解決這個問題，但是取樣會翻倍。所以他們將模型貼到地形上。但是這個做法的工作量巨大。



此外，由於Unity的地形細分演算法不會在斜坡上自適應，所以需要較高的細分等級才能有合適的細節。為了提高渲染效能，關閉了Terrain的自陰影，而使用簡化的地形模型來產生陰影。這個也是純體力活，工作量比較大。認為如果重來的話，可能會對地形做進一步的最佳化，應該是改用mesh的方案。

關卡設計：地圖和概念設定

地圖的關卡設計是雙重的：

• 一方面要適合劇情
• 另一方面要擬真，同時有探索樂趣
  

地圖設計包括設定區域和區域的情節性設定。整個地圖是在紙上進行的，並且早期在紙上對地區劃分進行了很多位置調整。

如果你不能在紙上設計出來的話，你就不可能在3d下把他做出來。


早期會產生多類概念設計。第一類是場景概念設計，並不對應任何特定的故事。


另一類是具體的故事概念設計圖。

在Firewatch團隊，紙上地圖、故事概念設定、場景概念概念設計放到一起，交替出推進方案，迅速迴圈演進，產生了很不錯的效果。

白盒vs實物Demo

傳統遊戲會搭出白盒模型。但是對於這個遊戲來說，白盒圖方式是不合適。它不能回答最關鍵的體驗問題，比如“主角需要多久從A走到B？”“這個區域探索有沒有意思啊？”


例如上圖的白盒模型。我們從A走到B，真走一次的話，你只會感覺從A走到B非常無聊，因為什麼都沒有。這是很糟的。


最終完全做了Day1，接近可上市水平的美術資源，包括專業的配音，所有所需的玩法系統，所有玩法系統所需要的支援工具，來評判整個工作是否可用。這Day1相當於10%的遊戲內容，花了15個月。整個開發時間是24個月。

剩下的內容是9個月完成的。這個15個月版本是15年GDC版本。

Day1的效果證明了所有方面達到預期：

• 我們的移動和聊天非常有趣
• 可以做到有趣的世界探索
• 玩家喜歡在地標間移動，他們是按地標來理解遊戲的。（按：看影片可以體會到，這裡的地標不是我們生活中一般說的地標，而是記憶點。例如一個箱子，一個懸崖上的圓木，一個拱門）
• 地標如果承載了遊戲故事內容的話更棒
  

概念設計、Demo和最終版

下面我們來看看，從概念設計到Demo版，最後到正式遊戲的演進過程。按：這裡希望大家體會一下：概念的核心元素，在Demo中是如何傳達的，Demo如何以較低成本抓到氛圍感。


第一個例子，遊戲第二天的瀑布地標。按劇情，玩家會在這裡看到樹上掛著紅色的撕裂的布，引起警覺。


Demo中小溪是直接畫在地板上的，注意布片的視覺效果。


再對比最終版。


例2，玩家穿過岩石拱，看見炊煙。


例3，在岩石拱的後面發現帳篷。demo中帳篷就用了一個橙色立方體。很有趣的是，遠看起來和最終版差不多。

評：做到這一點，應當與demo製作者的美術水準是分不開的。雖然用的是臨時資源，雖然直接放了Cube，但是必須清楚，這個demo並不爛造，他仍然是美術性的。無論是例1的破布，還是本例的帳篷，要讓玩家在畫面中自然地意識到它，這是受益於優秀的佈景和設色的。

移動的設計


在地圖上，根據概念設計，同時增加可發現物。

這裡有一段綜合演示影片，為玩家的實際遊覽過程。設計師控制玩家，每20秒左右有一個新的發現物。50:45演示了這個穿越過程，並在影片上文字提示相關發現物。

我這裡掐了一下秒，依次為：

• 開始
• 9''：隘谷左右岔路
• 23''~53''：看見儲物箱。箱子裡面有密碼鎖、雜件、對話、發現地圖以及尋人告示。這裡觸發的對話及後續觸發對話（見下方）可以持續到100''
• 56''：發現新種類的樹
• 67'':觸發對話結束，可以回覆對話，有3個分支。選一個分支可以持續30秒對話。持續到100''
• 71'':場景中有夕陽穿過樹的美景
• 90'':發現小溪
• 107''場景觸發可選對話，評價場景，中間有選項，持續到141''
• 118''岔路
• 134''有特殊結構的隆起地貌
• 150''發現有人遺落啤酒罐
• 160''發現瀑布
• 170''發現瀑布邊，樹上掛著鮮紅的撕裂的布料，觸發劇情
• 179''發現拱的石門
• 187''穿過石門
• 190''看見炊煙
• 195''發現野營人的營地
  

按：可以看到整個3分鐘的遊戲過程，內容非常密集。同時動輒半分鐘的對話，可以維持玩家體驗很長時間。

研發結語


遊戲開發是非常困難的。尤其在後期。就算你很有經驗，只做了一個新的東西。

事情總是這樣的，你覺得沒有任何東西工作正常，突然到某個神奇的一天，所有東西都正常了。

團隊只有11~12個人，做開放世界簡直是一個瘋狂的主意。為什麼做呢？全員都是10年經驗以上，做過一系列知名遊戲。對於開放世界，問到每個具體問題，大家都說“能做到”，並沒有人反對，所以就這麼神奇的推進了。大家顯然從心裡知道，整個專案不會那麼簡單，但是總的來說感覺是有機會的，另外大不了專案沒成仍然不至於沒工作嘛。（按：總的來說還是需要勇氣的）

問答，預算限制：

• 本遊戲故意不做NPC，因為太貴了
• 動物也很少，因為做得話不是直接放進去就行了，肯定需要處理各種bug
• 鳥是10美元從商城買的，用它做了整個鳥群（表示這隻鳥簡直太划得來了，應該漲價到50）
  

來源：GDC2016
知乎專欄：https://zhuanlan.zhihu.com/p/35367856