【CEDEC 24】《薩爾達傳說 王國之淚》打造「可動的規格書」重構開發環境

　　讓開發團隊全員都深入了解遊戲整體，並不論擔任職務都可以提出點子的平行製作手法。為了實現這種理想，所以下定決心重新建構遊戲的開發環境。在日本遊戲開發者會議「CEDEC2024」最後一天，有一場以「了解、創作、連結 在《薩爾達傳說 王國之淚》中重新建構的開發環境與音效製作案例」為題的講座，在其中解說了任天堂開發團隊實際製作的案例。

 

 

 

• 照片自左起為岡村祐一良、日高祥藏、長田潤也

 

 

　　過去在開發遊戲時，因為開發規模都比較小，所以進行決策時的節奏輕快，在溝通交流方面比很順暢，但近年來因為遊戲開發規模不斷在膨脹的關係，技術的分枝數量增加，開發時的分工合作也變得更細膩。

 

　　想要在這種環境下創作遊戲，通常就會採用讓各個部門的領袖人物下去思考遊戲製作方針，再分配工作給各個部下的所謂由上至下的創作手法。

 

　　只不過在《薩爾達傳說 王國之淚》（以下簡稱為《王國之淚》）的開發工作當中，卻是以「團隊所有人都可以構思遊戲開發方向並不斷嘗試的平行式創作手法」為目標。可能會看到美術設計師在考慮到遊戲平衡的前提下去設計新招式這種情況發生，是一種不論擔任什麼職務都可以盡情提出自己創意點子的製作手法。

 

　　雖然團隊當中當然還是會有領袖人物存在，但開發團隊是認為，能夠讓每一個人都像過去那個時代一樣親自參與創作過程，應該是更容易激出發優秀的點子才對。

 

 

　　為了達成這個理想，重點就是必須要讓擔任各種不同職務的成員，都能夠清楚了解到自己正在製作一款什麼樣的遊戲，岡村祐一良表示在達到這個前提之後，才能夠去「創作」。雖然後面還會再次提到，但大家可以注意在這邊主講者並不是用「製作」，而是包含了創造性在內的「創作」字眼，可以從中感受到其重點所在。

 

 

　　想要了解遊戲，可以遊玩正在開發中的版本，請教其他的開發者，又或者是閱讀規格書等等不同的手段存在。只不過光是遊玩，常常會沒有辦法完全把握規格，而想要找人請教，又必須要該部份的負責人剛好有空才可以，就算是去閱讀規格書，也會碰上加入遊戲時採用的規格其實並不一樣的案例。

 

　　想要實現平行式創作手法，由於遊戲在開發過程中會不斷變化的關係，所以讓實現的難度也隨之提昇。在前作《薩爾達傳說 曠野之息》（以下簡稱為《曠野之息》）當中，是採用將遊戲各方面的動作方法和數值等，原本會以規格書說明的部份轉化為資料，以資料驅動式手法進行開發。

 

　　將從資料中讀取到的情報，製作出表格、圓餅圖或者是投影片等視覺化資料，並且同時去遊玩遊戲。透過這種兼併兩者方式的「可動規格書」下去了解遊戲，然後再連結到創作行動上。另外岡村祐一郎特別強調「這並不是指不應該要去製作出規格書」，是表示規格書雖然可以用來整理遊戲開發者腦海當中的想法，但是並不適合用來了解關於遊戲的最新情報。

 

 

　　在現在一般的遊戲開發過程當中，通常是由核心團隊利用共通的框架去製作出各種不同開發工具，打造出整合型開發工具讓大家使用，但是在《曠野之息》當中，其實是採用每一個不同的部份，全都使用不一樣的程式語言和技術去製作的綜合組成方式。

 

　　雖然這是一種比起整合型開發工具來說，較為古老的開發手法，但同時也有柔軟性更高，更容易去應對各式各樣不同遊戲設計的長處。因為只要有構想，不管是誰都可以下去製作開發工具，所以更容易激發出全新的點子，也比較容易採用全新技術來累積不同的經驗，促進開發團隊成員的技能成長，其實有相當多不同的長處。

 

　　比如說在開發《健身環大冒險》時製作出來的記錄用工具，就有轉用到其他遊戲開發工作的成果。

 

　　但是另一方面，綜合組成方式與整合型開發工具相比之下，各個開發工具之間的連結力較弱。有時候想要在某個開發工具裡加入一個方便使用的功能，就必須要去解析另一個不同開發工具的情報才行。而且為了要了解遊戲整體的架構，就必須要同時使用複數不同開發工具，並且去理解各個資料之間的連結才可以。

 

　　而且《曠野之息》的開發工具，因為將加入速度擺在第一優先的關係，有些工具其實沒有什麼擴充的空間可言。再加上《王國之淚》的遊戲內容與前作相比之下更加複雜，內容量自然也變得更為龐大。

 

　　於是包含岡村祐一郎在內的開發團隊成員，就決定要從頭打造一個全新的開發環境。開始製作設置在各個開發者電腦裡的「本地資料庫（LocalDB）」、用來管理資料版本的「公用資料庫（GlobalDB）」，以及讓各資料之間連結視覺化的「專案入口（Project Portal）」等等開發工具程式。

 

 

 

　　「本地資料庫」是為了解決舊有開發環境的問題之一，也就是各開發工具之間連結力較弱這個問題的工具。基本構想是先準備作為所有開發工具共用基礎來使用的資料庫，讓開發工具透過資料庫去讀取各種檔案。只不過單純只是準備一個資料庫，開發第一線人員也不會去使用。於是就採用了能夠利用在各種不同程式上面的 SQL 工具，讓不管是使用什麼開發工具，都可以直接讀取到資料庫裡面的檔案。

 

　　另外關於要在資料庫裡寫入各種情報的時候，基本上是讓有最了解該檔案的人會下去執行這個動作。比如說如果是遊戲的 3D 模型，那就是由 3D 模型工具的開發者下去將資料登錄到資料庫裡面。

 

　　雖然這樣的確會增加特定開發者的工作量，但是因為資料庫成為可以共用的基礎部份，所以即使會有複數開發工具都需要使用到 3D 模型，也就不用再分開來一一去應對，因此反而能夠降低整體的負擔。

 

 

　　只不過話雖如此，但即使是對該項檔案最了解的人，實際上也很難去預測其他不同開發工具，會需要哪一些項目的資料。而且如果採用有人提出需求，就一一去對應該項目的方式，那反而又會增加負擔，並不現實。

 

　　於是就決定在製作「本地資料庫」的時候，採用加入「盡可能多種不同的資料」這種方針。舉例來說像是 3D 模型的檔案，就會記載包含頂點數量、骨架的名稱以及原型骨架、材質名稱和使用著色器……等等，資料庫裡面記載的項目越多，就越方便其他開發者嘗試各種不同的方案。

 

　　雖然在構思不同點子的時候，很難事前去預測會讓人想要對哪些項目動手調整，但只要事先記載好盡可能多樣化的資料，那就能夠立刻對應突如其來的發想。

 

　　而且會記載在資料庫裡面的資料，包含 3D 模式、材質、關卡、事件、演員、特效、動畫、數值以及背景音樂等等構成遊戲的檔案，還有用來製作這些檔案的 Maya 的 .ma 檔案、 Photoshop 的 .psd 檔案，以及各項程式的源代碼等等，有各種不同種類的資料，可說是包羅萬象（只不過像是頂點串流（Vertex stream）之類巨大的資料就會被視為例外）。

 

 

　　不過就在這樣建構資料庫的過程當中，有人提出了「那資料庫應該要設置在哪裡」這個問題。一般來說通常會把資料庫設置在伺服器上面，讓每人個使用自己的電腦去讀取資料庫。只不過在開發過程中進行各種作業需要使用的檔案，基本上是放在每個人自己的電腦裡面，而且還會因為開發遊戲時出現的不同構想持續加入變動。

 

　　這也就是說就算是同一份檔案，也會因為每一個人作業進度不同而產生差異，這樣子自然就會讓每個人依照自己想法加入的變更，與伺服器上的檔案版本發生衝突，產生「同一份檔案卻有複數不同版本，那到底是誰的版本才正確？」，這個在遊戲開發過程中大家都很熟悉的問題。

 

　　於是日高祥藏就表示，這時候就必須要換一個想法。既然每一個人在開發過程中都需要進行不同的作業，那麼就讓每一個人都有專屬於自己的資料庫不就好了嗎……在這個想法當作前提之下，最後就採用了在每一個人的電腦裡面，都設置一個存在於本地的資料庫這種做法。而因為是存在本地的資料庫，所以就命名為「本地資料庫」。

 

 

　　但雖然說是存在本地，可是每一個人的資料庫都還是有互相連結。而且各種開發工具，也會透過資料庫互相連結。比如說有人使用 Maya 編輯某個角色模型並且更改了骨架的名稱，那有用到這個骨架名稱的其他工具，也會更新資料將這個全新的名稱覆寫上去。

 

　　而且其他開發者只要有變更檔案內容，並且使用版本管理系統的話，這些變更也會反應到自己的檔案裡面。這樣就不用去判斷到底誰的版本才正確，而是最新的變更會持續反應到所有人持有的檔案當中。

 

　　只不過在這個系統裡，為了要提昇反應速度，所以刻意排除了不需要的檔案。所以因為對自己擔任職務沒有必要性，因此沒有存在本地資料庫裡的檔案，就沒有辦法下去更改。

 

　　然而就算是這樣說，有時也是會需要用到這些檔案，於是就決定要在「本地資料庫」的系統中，準備一個設置在伺服器上面的共用型資料庫，也就是「公用資料庫」來管理各種不同檔案的版本資料。所以在想要使用自己手頭上沒有的檔案時，就可以連進「公用資料庫」裡面去讀取這些檔案。

 

 

　　以「本地資料庫」和「公用資料庫」，解決了開發工具之間連結力較弱的問題。

 

　　那現在就要開始處理另外一個問題，也就是「無法理解遊戲構造」。因為遊戲十分複雜，會記錄在「本地資料庫」裡的情報量十分龐大的關係，很難只看這些情報就去了解到整體遊戲的構造。

 

　　但既然如此就應該要去適當處理分類這些情報，所以就開始構想出一個可以選擇資料的種類，並且盡可能縮限要讀取的情報範圍，讓使用者可以去追查資料與資料之間關聯的開發工具，而這就是讓資料關聯視覺化的「專案入口」。

 

 

　　在「專案入口」可以篩選想要尋找的資料種類，並且靠資料名稱以及加在各個資料上的標籤來進行搜尋。

 

　　比如說以「大師之劍（マスターソード）」當關鍵字進行搜尋，除了大師之劍本身以外，還會看到劍鞘以及台座等關聯項目也列在搜尋結果的清單裡，如果是想要找會被雷劈到的武器，那就可以使用「金屬製」這個標籤來篩選要搜尋的範圍。

 

　　而且因為標籤本身也可以加入各式各樣的條件來進行篩選，所以就準備了相當龐大數量的標籤。就和前面提到的「本地資料庫」裡要刊載的檔案種類一樣，加入的標籤數量越多，就越能夠靈活對應每個人發揮出來的創意構想。

 

　　在加入的標籤當中，還有「前作就存在的武器」、「會從寶箱掉出來的武器」、「拿弓箭的敵人」、「會遇見敵人的 NPC 角色」以及「會出現在神殿的設置物件」等等，可以看出開發團隊為了要打造一個讓人可以進行「創作」的環境，付出了多少努力。

 

　　只不過正因為標籤十分詳細而且又多樣化，所以要靠人手去加入標籤就有極限存在。於是在「專案入口」這個開發工具當中，就會把演員（在這裡指會出現在遊戲中的物件）的數值也全部都當作是標籤來處理。

 

　　由於演員的性質會在資料內以數值化的方式來記載（比如說像是可以燃燒的演員，就會設定一個可以燃燒的數值），所以只要將這些數值當作標籤對 SQL 送出請求就好。

 

　　這個在「專案入口」的設定中被稱為「請求標籤」，和一般的標籤一起搭配運用，就可以使用十分複雜的條件來進行篩選。

 

　　應該可以說是參考自己想要使用的條件數值，直接去產生一個可以在當下使用的標籤吧。也因為有這個設計，所以關於會使用數值來記載的性質，就不需要以人力來主動去加上標籤了。

 

 

　　然後為了要把握遊戲的構造，還製作出可以直接看到資料之間連結（參考關係）的功能。參考關係的箭頭在依照事件→演員→模型設定……這樣順向來表現時，直接使用一般的樹狀圖就可以，但是要顯示出逆向樹狀圖的時候，就會發生可能會顯示出重複資料的問題，於是就採用在顯示逆向關係的時候，改用清單方式的手法。

 

 

　　而就演員和物理設定以及 3D 模型這種沒有直接關聯（離散程度較高）的資料來說，則是提供了可以查詢各自資料的連結，取得必要情報後顯示成一覽表的功能。

 

　　比如說寶箱的配置情報，與放在裡面的演員，還有演員的賣價，這些原本應該是寫在不同檔案裡面的情報，就會加工為一覽表，並且加上可以直接跳到情報所在位置的按鈕。

 

　　另外就波克布林（ボコブリン）來說，在演員表格裡面會有名稱和內容標籤，而在 3D 模型表格裡會有名稱和邊界框架，在物理設定表格裡則是會記載質量，在這種情況下只要使用 SQL 就可以製造出將名稱、產生出的縮圖與邊界框架、質量一覽表，以及除錯產生用的按鈕都一字排開的一覽表。

 

　　本來應該要自己去參考每一個不同的資料，從中去理解資料之間的連結，但是透過「專案入口」就可以加工成一覽表，提供讓人可以馬上就參考所有關聯資料的按鈕。

 

　　這樣子就可以量產出 SQL 或者是加工方法，於是就把這個功能稱為「資源表格」。當然像這類試算表也可以直接用人手製作，但是自動化生產一定比較少會出現失誤。

 

 

 

　　接下來登台的長田潤也，則是以音效團隊的角度，舉出實例來解說活用「本地資料庫」和「專案入口」的範例。

 

　　由於音效團隊工作性質之故，通常都是在遊戲開發後期才開始動工，但團隊一直都有希望可以在早期就開始主動參與遊戲製作的想法。只要有「本地資料庫」和「專案入口」這兩個開發工具，就可以在播放動畫片段的同時加入音效，又或者是介接到用來編輯動畫資料的開發工具上。

 

　　而且還有加入在其他開發者變更動畫資料的時候，就會自動通知關聯音效製作者的設計，讓整體作業效率有明顯提昇。

 

 

　　而且在格魯德小鎮（ゲルドの街）防衛戰這個遊戲事件中，還能夠讓音效演出變得更加緊密。由於這在遊戲故事上也是一個十分重要的場面，所以就有人提出希望可以加入依照戰鬥當下狀況，讓音效出現變化的演出這種提案。

 

　　於是就在利用「專案入口」仔細把握這個事件的規格之後，成功加入了在適當的時機去切換戰鬥背景音樂，以及每一次破壞吉波得（ギブド）巢穴時樂曲都會發生變化等等，更具有互動性的演出手法。

 

　　而在本作中玩家使用的武器，可以透過「餘料建造（スクラビルド）」黏貼上不同素材甚至是其他的武器，每次黏貼後音效都會出現變化，設計可說是十分複雜，而在這方面「專案入口」也是幫上很大的忙。

 

　　雖然只調查餘料建造的數值，也很難去了解比如說是用什麼方式黏貼上哪一種道具，也就是整體產生了什麼樣的變化，但只要利用在「專案入口」當中，為了方便遊戲設計師調整數值而加入的預覽，就可以完全理解當下使用的武器規格。

 

　　雖然說有的時候，在使用餘料建造黏貼上素材前後，音效也不會出現變化，但只要透過「專案入口」調查，就可以馬上了解到這是刻意為之的設定，還是單純設定時出現失誤。

 

　　長田潤也表示，「專案入口」可以說是一個可信度極高的情報收集基礎建設工具，讓團隊能夠放心打造遊戲細節到最後一刻，給這項開發工具相當高的評價。

 

 

　　讓參與開發的所有開發者，不論其職務都可以提出點子，透過從不同視角出發的創意發想讓遊戲變得更加完善……這應該是遊戲開發工作的理想狀態之一。然而當專案規模越變越龐大，距離這種理想也就越來越遠。可以說在《王國之淚》的開發工作當中，就是透過打造出各種不同的開發工具，盡最大努力去維持這種理想的狀態。

 

　　在近年來所謂 3A 大作當道，因為大規模遊戲作品成為主流，讓開發工作越來越高度分工的時代裡，負責遊戲末端工程的開發者，真的是很難去把握遊戲的全貌，實際上也有人指出這種狀況，甚至會影響到開發者投入開發遊戲的動力，本次講座中講解的這些工具，從筆者個人角度來看，也明確感受到是一種能夠去解決這種問題的手法。

 

　　雖然這只是筆者個人的感想，但是岡村祐一郎在這場講座當中，會特別強調「創作」這個用字，而不是單純使用「製作」，應該就是想要強調大家不應該只把遊戲開發當作一種工作，只是機械性地去投入製作，而是要在其中加入創意發想去完成一場創作才對。

 

　　從不同職務角度出發能看到的事情不同，所以能夠催生出的點子也不一樣。如果能夠透過自己本身職務特有的觀點和創造性，去參與遊戲開發工作的話，想當然是一定可以大幅提昇開發第一線人員的士氣才對吧。

 

　　正如同岡村祐一郎本人指出的一樣，就算是採用讓領導人物決定一切的由上至下方式，還是可以順利完成遊戲開發。而且即使費盡苦心開發出一大堆開發工具，也不能保證一定可以完成比由上至下方式還要出色的遊戲。只不過《王國之淚》即使是如此，依然選擇了這條要克服許多難關的道路。

 

　　本作之所以能夠在全世界各個國家，讓各個不同年齡層的玩家都給予極高評價，應該就是因為費的這些苦功，的確有開花結果獲得成效的關係才對吧。當然這絕對不是一種能夠馬上就讓所有遊戲開發現場模彷的手法，但是就在必須要在截止期限之前完成遊戲的現實考驗當中，還能夠堅持要去追求理想，的確是件讓人感覺到十分精彩感動的事情。