在2017年8月31日舉行的CEDEC 2017活動上，任天堂為我們帶來了「《薩爾達傳說：荒野之息》項目運營~從demo到成品無縫銜接！」的演講。
這次演講中，任天堂的員工回顧了同年3月推出的《薩爾達傳說：荒野之息》（簡稱BotW）的開發過程，並從工程師和藝術家的角度講解了開放世界項目管理的秘訣。
300人團隊，4年時間，3次疊代，任天堂詳細介紹他們如何去管理「開放世界」這樣的大規模項目，對我國遊戲公司製作開放世界有很大啟發。
這段演講的價值極高，不過可惜的是這麼多年來，網上一直沒有相應的中文翻譯，以至於國人對這個演講不甚了解。
這次筆者不才，想挑戰翻譯一下，並對演講內容增加筆者的解讀和分析。由於筆者經驗有限，翻譯難免有疏漏，希望大家不吝賜教，未來筆者也會繼續翻譯並分析其他尚未有中文版本的演講。
演講者介紹
首先我們介紹下登台演講者。
>
岡村祐一郎
2005年加入任天堂前負責圖形·聲音資料庫製作工作，加入任天堂後負責遊戲開發、資料庫製作、工具製作等工作，BotW系統架構師。
程式設計師岡村祐一郎擔任「BotW」中的系統架構師，負責整體架構設計、製作工具和環境開發等工作，以確保遊戲開發的順暢進行，本次演講中岡村將從工程師的角度介紹開放世界項目管理運營的方法。
>
尾山佳之
1999年東京藝術大學大學院美術研究科碩士畢業，同年加入任天堂。曾擔任薩爾達傳說系列的角色設計師，為BotW資深設計師。
尾山佳之曾參與薩爾達傳說系列中許多角色設計，「BotW」中他負責管理角色模型。
岡村先生負責系統和工作流程的設計，而尾山先生則負責管理現場設計師的工作。
在具體內容介紹之前，介紹了一個名為「Zelda Editor」的《薩爾達傳說：荒野之息》專用開發工具。
該工具可以編輯管理遊戲中的所有數據，是《薩爾達傳說：荒野之息》項目的核心開發工具，本次演講將以這個名為「Zelda Editor」的工具為前提，介紹任天堂的開發流程。
工具的詳細介紹，留待以後的文章分析講解。
堆疊開發VS框架開發
在介紹具體案例之前，先從理念層面上解釋一下兩種開發思路。
根據岡村先生的說法，遊戲製作流程大致可以分為「堆疊開發」和「框架開發」兩種，他以五重塔的建築為例解釋了這兩種方式。
堆疊開發」是指先把第一層完全做好，然後根據這一層的樣式逐層開發的開發模式。（如下圖所示）
用便於國人理解的方式來說就是，《原神》先把蒙德做出來，再去做璃月、稻妻這樣的形式。
而「框架開發」則是先想像整個塔大致的樣子，制訂開發指南，然後組建塔的骨架，接著加上牆壁和屋頂，最後完善裝飾的開發方式。（如下圖所示）
這種開發方式的代表自然是《薩爾達傳說：荒野之息》，在同期的其他任天堂演講中，任天堂員工介紹了在正式開始製作之前，先製作了一個2D版本的原形來測試玩法的可行性，這種先做原形的流程，其實就是框架開發的體現。
這兩種開發方式並沒有好壞之分，而是要根據開發的遊戲類型來選擇。那麼對於本次的《薩爾達傳說：荒野之息》，哪一種方式更為適合呢？
根據曾經參與製作過多款薩爾達作品的尾山先生表示，《風之笛》等遊戲基本上都採用了「堆疊開發」。團隊會先製作出一個作為模板的關卡，然後再通過調整設計的方式製作出其餘的關卡。
比如《薩爾達傳說：時之笛》以大型迷宮的設計著稱，森林神殿、火之神殿、水之神殿、暗之神殿、魂之神殿等迷宮，都是以一個迷宮模板為基礎，不斷修改完善，以堆疊開發的形式製作出來。
能這樣開發的原因在於，《時之笛》的迷宮有明確的限定區域和階段，國內遊戲人可以理解為《時之笛》的迷宮為必須按照順序遊玩的副本。
但是尾山也表示，在充滿各種怪物、素材、地下城等元素相互關聯的開放世界《薩爾達傳說：荒野之息》中，並不存在明確區分限定區域的關卡或階段之類的東西。因此，必須一開始就做好整個世界，這就不可避免地導致了採用「框架開發」。
堆疊開發和框架開發的主要區別在於原型製作階段。
堆疊開發的原型是一個關卡或者一個任務，用於驗證遊戲的遊戲性，而框架開發的原型是整個玩法框架，問題在於如何構建項目路線圖。
對於堆疊開發，如果確定整體需要5個階段，那麼每個階段就會有一個里程碑。
然而，像開發開放世界這樣的框架開發並沒有一開始就存在這樣的里程碑。
因此，《荒野之息》在從框架階段的原型到素材量產，以及它們的修補完善的過程中逐步設立了里程碑。
具體來說，在原型階段，素材是沒有多餘細節描繪的粗糙模型（比如下圖最左邊的方塊野豬）。然後，這些素材會逐漸完善，與最終版本越來越接近。
重要的是，構成玩法的元素從初始階段就被包含在內，隨著開發的進行逐漸被展現出來。在這次演講中被稱為「無縫製作流程」。
框架開發的優勢，與混合開發
這裡筆者為大家講解一下，其實從前面的「五重塔」圖片對比（一個歪歪扭扭，一個方方正正）就可以看出，任天堂開發團隊比較偏好「框架開發」。
這種偏好的一個主要原因是：任天堂在開發《薩爾達傳說：風之杖》等遊戲採用堆疊開發，就遇到了後期內容不足頭重腳輕的爛尾問題，這個問題是任天堂極力要避免的。
當然，服務型的網遊（含手遊）與買斷制的單機遊戲不同，堆疊開發與持續運營、不斷更新的網遊的確比較契合，對此筆者的看法是：整個遊戲的底層玩法還是要堅持框架開發，但是在大世界的製作上可以採用堆疊開發，也就是混合開發。
主要分為以下階段：
①
首先，在正式開發前，就先通過討論、試做原型等形式決定底層玩法，把遊戲框架確定下來。
比如《原神》最開始是計劃做類似薩爾達的深度環境互動，但後來點到為止，其實這些底層玩法的設計，如果能在早期就確定是能減少工作量和返工的。
②
其次，確定好框架後，按堆疊開發的形式去做開放世界，然後結合劇情分階段開放。
比如在《荒野之息》中，存在大量限制玩家行動的「牆壁」，由這些牆壁分割的地區可以採用堆疊開發，並通過更新和大型任務分批次提供給玩家。
這裡結合筆者的《
論《薩爾達傳說：荒野之息》在開放世界限制玩家行動的手段
》一文拋磚引玉說明：《荒野之息》中水神獸所在的佐拉地區因持續大雨岩壁濕滑，玩家無法通過攀岩的形式越過山峰，這樣就形成了天然的區域界限。
（下圖紅線為因大雨造成的區域界限）
那麼在製作開放世界服務型網遊時，可以這樣設計：持續大雨的山谷，山谷外是未開發的開放世界，階段性的世界任務是打敗造成持續大雨的BOSS。在山谷外的開放世界做好後開放擊敗BOSS的任務，BOSS死後雨停，玩家就可以翻越山峰探索外部的開放世界。
以上的設計就不會給人很強的「沒做完」感覺，而是通過劇情將因堆疊開發造成的「不完整的開放世界」合理化。
不過，目前國內公司以「堆疊開發」為主的原因在於：部分領導通常希望快速看到成品產出，誤以為前期長時間的分析、研究、討論和試做是「磨洋工」，很難接受「框架開發」理念，但這樣也導致很容易出現「返工」。
三個開發階段
接下來，將根據具體的里程碑來說明岡村先生的《荒野之息》的開發流程。
相比堆疊開發，框架開發一開始就準備好了所有的元素，在此基礎上不斷去修補完善。
因此里程碑設計了三個階段，是像賽車比賽一樣設定了第一圈、第二圈、第三圈等，也就是本文開頭提到的三次疊代。
《荒野之息》將遊戲的開發流程分成三個階段分別進行，為了避免在每個階段出現不必要的工作，禁止了一些工作內容。
比如，第一階段中，除了實現遊戲的核心樂趣之外的所有工作都是禁止的；第二階段，只允許製作角色和環境素材，不允許美化和完善。
其流程的代表就是前面圖片的這三頭豬，第一階段只准做這種方塊豬來驗證玩法的可行性，第二階段做出豬的大致模型，完善其他動物，第三階段才是對這頭豬進行細化調整。
以下將詳細說明每一階段的工作。
耗時最長的第一階段
第一階段是最長的一個階段，《荒野之息》開發的四年來，超過一半的時間都是花在這第一階段上，耗時一年半時間。
第一階段注重於遊戲的本質，即玩家與海拉爾世界諸多元素（環境、元素、物理、敵人、生物等）互動產生的玩法。
當然，這是對《荒野之息》是這樣，其他開放世界遊戲不一定是這樣，例如《艾爾登法環》則是魂Like的戰鬥。
因此，為了降低不必要的工作量和提高效率，所有角色等都需要重複使用以前作品的模型或者臨時模型。
下圖是一張開發示意圖，藍色的「過」代表過去的模型，「仮」代表臨時模型，先用這些模型把遊戲的玩法、劇情做出來。
成品中的格魯德公主，在第一階段使用了以前作品《風之杖》的大小姐模型，其他怪物等也通過不同顏色的哥布林來區分。
總之，從這個階段開始，就準備好包含製作人員名單的所有遊戲內容，便於確認遊戲的玩家體驗是否良好。在此階段進行驗證，可以儘早地對不合適的方向進行修正。
這裡給大家舉個例子，《電馭叛客2077》在早期demo演示時有螳螂刀爬牆玩法和地鐵系統，但是後來都刪掉了，其實就是早期沒驗證玩法和系統的可能性。
另一方面，在重複利用以往模型資源和使用臨時資源的過程中，那些負責製作實際模型的藝術家們在做什麼呢？
其實在這一階段，他們並沒有直接參與實際的遊戲開發，看起來似乎「什麼也沒做」。
但筆者重申，他們並不是在摸魚，其實這一階段還沒有到他們出場進行實際工作的階段。
實際上，他們在構思遊戲的美術風格和遊戲氣氛，並參加培訓學習如何使用新技術輔助開發（作者註：這裡應該是指Zelda Editor）。
此外，他們還研究了如何表現出偏卡通的美術風格（作者註：指瀧澤智演講中提到便於「欺騙」玩家的風格）和金屬感，並研究了量產資產所需的工作流程，以及種族設定等世界觀的內容。
工作流程可見下面的圖片，有點兒模糊，筆者嘗試分析一下，不一定準確，但總比沒有好，大家覺得我說錯的也可以留言提出來。
上面從左第一張圖片，應該是林克在不同地形下的錯誤（NG）姿勢；中間那張圖應該是林克建模的碰撞模型或建模，用於製作不同姿勢時的碰撞模型或建模；最右邊是符合要求的遊戲資源與NG遊戲資源的對比；右下則是為了保持風格統一的圖標、元素的基礎設定。
使用任務管理工具填充框架
在第二階段中，主要任務是把臨時模型素材替換為正式模型。
示意圖如下，注意之前的字都變成了「正」。
實際替換後的遊戲畫面非常接近最終成品，但紋理和NPC動畫仍存在一些粗糙之處。如何打磨這些內容變得非常重要，而關鍵則是任務管理。
下圖為演講時的宣傳圖，筆者猜測這裡可能是影片，展示NPC紋理和動作還沒有做好。
任務管理在遊戲開發以及項目管理中都非常重要，任務簡單地說就是要求完成的工作，通常使用專門的工具進行管理。
具體來說，是發布一系列包含任務內容、需求發起者、開發者和預估工作量等資訊的任務。
然而，傳統的任務管理工具存在一些「問題任務」的問題，例如任務執行對象不明確、找不到要修正的數據位置、或者任務說明含糊等問題。通常情況下，為避免這些問題的產生，每個發起者都需要注意任務書寫格式，或者讓項目經理對任務進行審查和盤點。
任天堂採取的解決方案則更為大膽，他們為Zelda Editor添加了專用的任務管理功能，將任務管理工具與開發工具結合在一起。
與通常的任務管理工具不同，這個任務管理工具將所有任務像「便簽」一樣貼在數據上。例如，如果哥布林模型有問題，就將任務貼在該模型的數據上，寫著「請修復模型」。可以將其想像為在遊戲內的所有數據上直接貼上「便簽」並指示工作的感覺。
下圖是任務管理工具的圖示，在遊戲中場景上做出氣泡提示，看內容應該是需求方希望在敵人據點附近加入「蜂巢」的需求。
結果是，開發人員可以直接訪問要處理的數據，消除了不確定性，並且任務的顆粒度也更細緻。
此外，每個數據中都包含製作者的歷史記錄，因此也能自動確定下一流程的開發者。這種類似「便簽」的任務可以貼在模型、著色器、AI、遊戲內場景坐標等所有地方。
使用任務管理工具進行素材批量生產和錯誤修復
接下來講講設計師如何利用這個任務管理工具進行素材量產。
如先前所述，在《荒野之息》開發的早期階段，遊戲內的資源是使用舊作品資源或臨時資源。
在這個階段，設計師為10種武器製作了臨時的劍資源，並僅更改顏色以做區分。
然後，然後，他們會將「Sword_1是劍，Sword_2是棍棒，Sword_3是斧頭」等任務附加到「請製作士兵的劍模型」的數據上。
這樣，使用任務管理工具就可以機械地批量下達任務。同時，通過將任務與數據相關聯，通過匯總任務可以實現精確且簡便的進度管理。
岡村展示了一張進度管理表格，左側是各種武器，右側看不太清，筆者猜測分為這樣四欄：
概念圖下屬的狀態和天數，狀態都是已確認，天數是0。
模型製作的狀態和天數，狀態有新任務、製作中和完成，給的排期是4天。
完善細節（增加光澤和質感）的狀態和天數，狀態跟模型一樣，排期三天。
最終成品的狀態和天數，排期總共是7天。
通過這樣的任務管理，項目在不偏離預期太多的時間下完成了，下面是開發日程管理圖，橫軸為日期，縱軸應該是需要製作的模型數，左側的縱坐標大幅提升可能是基礎泛用模型製作後延伸出的細分模型。
比如先做出單手劍等基礎泛用模型，再去做寒冰劍和火焰劍，這樣圖表上的工作量才會大幅提升。
實際上，通過任務管理工具的數據可以看出，任務數量呈現出一個漂亮的下降曲線，並且從這裡也可以對整個項目的進度進行估算。
由於任務與數據相關聯，因此不會出現重複任務或模糊任務。
當所有模型都已確定後，遊戲正式開始製作模型，前期經過實際製作預估出必要的工作時間，以此推測最終完成所有任務需要的時間。
第二階段開發了預計1年多一點兒，最終只比計劃多15天時間，可以看出「時間管理大師」任天堂的強大。
完善品質和修復BUG的第三階段
在最後的第三階段中，所有資源都需要達到成品的質量。
具體來說，主要是為了提升品質尋找並修復BUG，修復也使用了上述的任務管理工具。
比如下圖這樣，對BUG進行分級，並顯示進度。
而且，不僅可以從Zelda Editor中添加BUG報告，還可以在測試玩遊戲時，從遊戲內添加BUG報告。例如，如果存在比例感不正確的蘑菇，則可以選擇該蘑菇並將BUG報告作為便簽附在上面。
此外，由於任務管理工具支持遊戲運行的腳本引擎，因此可以直接在BUG報告欄中編寫腳本，以便立即使用修改後的腳本執行，這樣修改BUG和測試可以無縫切換。
另一方面，設計師在第三階段的目標是儘可能檢查資源，並進行美化工作以提高質量。
與第二階段一樣，確認工作也由領導者進行統一下達指令，例如模型或紋理大小等在工作表中進行檢查，而其他模型的諸如燃燒、浮力、水流等則在測試機上進行檢查。
設計師在任務管理工具中進行模型確認和美化工作，因為訪問數據更容易且資訊集中在一起，所以效率會大大提高。結果是他們能夠將更多精力放在創造性的工作上。
大規模開發也始終將遊戲視為一體
以上是實現《薩爾達傳說：荒野之息》多樣化角色和場景的三個階段。
其中，第一階段持續了一年半，而第二和第三階段則在一年左右。由於任天堂一開始並沒有開放世界的技術知識，所以一開始的階段花費了最長的時間，但是量產階段的進度則相對比較穩定。
雖然開發流程應該儘可能地與遊戲系列風格相匹配（作者註：指系列過去按照堆疊開發），但像本次召集大量員工，基於框架製作獨立的編輯器和任務管理工具的開發模式，也是一次非常有趣的嘗試。
下圖展示的是其中一個模塊的開發流程：
由於沒有相關新聞沒有解釋，筆者分析認為這幅圖的內容可能是：主角在前期遇見的第一個敵人「波克布林」，其包括「敵人模型」、「敵人AI」的數據，對此進行任務管理和開發。
在「敵人模型」、「敵人AI」的基礎上，生成「波克布林」的角色和動作，把它放到demo場景中測試，最終放到遊戲裡由程式設計師編寫腳本。
結語
本編輯器每5分鐘會自動創建一次開發版ROM以進行遊戲測試，這表明任天堂非常注重遊戲遊玩和遊戲開發的循環。
儘管開放世界遊戲開發並不罕見，任天堂也並非在開放世界開發上積累了很多經驗，但這種工業化的開發流程仍有很大的學習空間。
