原文標題：
【CEDEC 24】《薩爾達傳說 王國之淚》餘料建造完成之前「為了準備而做的準備」講座
原文網址：https://gnn.gamer.com.tw/detail.php?sn=273294
任天堂的藤林秀麿與廣瀨賢一在遊戲開發者會議「CEDEC 2024」上，帶來了講座「《薩爾
達傳說 王國之淚》的餘料建造完成之前～為了準備而做的準備～」。
https://p2.bahamut.com.tw/B/2KU/04/6c80593ebd51833515394552b91r9uw5.JPG
《薩爾達傳說 王國之淚》（以下簡稱《王國之淚》）中的一大特徵「餘料建造」，是以
武器等裝備黏上別的素材，用以加強裝備性能的系統。而為了要實裝這項功能，藤林與廣
瀨兩人將在接下來的講座介紹他們進行的各種作業。
https://p2.bahamut.com.tw/B/2KU/05/840750d6bec2320aab4a79fc5d1r9ux5.JPG
藤林秀麿（左）、廣瀨賢一（右）
從 Game Boy Color 時代開始就經手製作《薩爾達傳說》的藤林在本作《王國之淚》既是
總監也是「餘料建造」功能的提案者。
廣瀨則是作為遊戲開發基礎團隊的首席工程師攜手打造本作。所謂的遊戲開發基礎團隊，
是指整頓在開發中會使用的服務（主要以使用網頁瀏覽器的 Web App）的團隊，讓開發過
程能更加便利且有效率地進行工作。
https://p2.bahamut.com.tw/B/2KU/06/d14d66ff9de0b89c3fa1f88dbe1r9uy5.JPG
https://p2.bahamut.com.tw/B/2KU/07/ef02fa9767d01ea48b9cd1676c1r9uz5.JPG
餘料建造的趣味和問題
講座首先由藤林介紹餘料建造的「黏接遊戲」其提案的由來與過程。
該想法原本在前作《薩爾達傳說 曠野之息》（以下略稱，《曠野之息》）開發時就有出
現過。藤林表示在製作「使用長槍越過鐵窗把按鈕打開」的機關時，就曾經想過「如果可
以做到利用兩把長槍黏在一起，觸動位置更遠的按鈕的玩法，感覺會很有趣」。
而藤林也從該作中的「八爪怪氣球」（黏在物品上就能讓該物品飄起來）感受到「把什麼
東西黏在一起玩」的可能性。
之所以會這樣想的理由，就不得不提到由《曠野之息》繼續延伸的薩爾達系列開發主題「
打造能引起趣味的機關」。藤林認為如果能夠在遊戲中製作出讓人勾起興趣的機關，並且
將其結合，就能引發意想不到的事，產生嶄新的體驗。
https://p2.bahamut.com.tw/B/2KU/08/73c7b6eb4beec8a42436c44e291r9v05.JPG
就算只是「起起伏伏的地形」與「圓形石頭」，都能引發玩家產生把石頭推進地洞、推去
撞敵人，甚至是推去嚇人等各式各樣的玩法
為了讓這個主題在《王國之淚》進一步發展而想到的就是「餘料建造」。不過藤林在接著
要介紹這個發想將以什麼方式呈現時，提出了一項接近核心的問題：「薩爾達傳說是一款
什麼樣的遊戲呢？」並訴說自己的回答，也就是「先推理並實踐然後享受結果的遊戲」。
https://p2.bahamut.com.tw/B/2KU/09/07140a1014f923ccd92e897f3a1r9v15.JPG
在《曠野之息》和《王國之淚》，可以做到「如果朝火堆另一邊的木箱射箭，箭矢經過火
堆會燃上火焰並且在射中木箱時會燒起來」、「把樹砍倒會變成圓木，把圓木推入河川就
會浮起來，並踩在圓木順著河流移動」等，藤林認為這正是一種「如果這樣不就可以這麼
做？推理後並利用結果來推進遊戲」的表現手法。而這也就是「薩爾達傳說的玩法」，只
要這個遊戲過程越是豐富，遊戲的構造也就會變得越有趣。
https://p2.bahamut.com.tw/B/2KU/10/3f903870889c3aefd2356e565d1r9v25.JPG
搭配這段說明時，投影片放出了《曠野之息》在開發中為了驗證玩法可行度時的影片
因此，藤林希望也能在《王國之淚》將「推理與實踐」的幅度經由玩家的自由想像去擴大
，而將餘料建造的黏接玩法變得更加完善。
首先就是從武器要黏接什麼的地方開始驗證。在南瓜田揮動長槍的話，長槍尖端會因為接
上南瓜而提高破壞力，同樣用長槍尖端黏接蜂巢的話，在揮動時就會有蜜蜂跑出來攻擊敵
人，或是在盾的左右黏接劍並裝備在背上就能邊走邊割草……等上述都是能在遊戲中做到
，藤林也藉此確信了推理的幅度能如想像中的一樣延展。並且看見了餘料建造的本質。
那就是「外觀表達功能」，必須由外觀直接說明功能。例如像是讓木棒黏接岩石的話，不
管怎麼看都會提高破壞力的感覺。雖然也有黏接東西之後，外觀就會與原物品變成完全不
同的選項，但為了要能促使玩家想像與推理，那就不能是「A+B=C」，而是要「A+B=AB」
的形式才比較好。
https://p2.bahamut.com.tw/B/2KU/11/ef3fc411cb324c01da5b0858911r9v35.JPG
https://p2.bahamut.com.tw/B/2KU/12/b37a1f9fad28e869fc992ece371r9v45.JPG
抓到手感的藤林緊接著想到「那如果再黏接三個或四個物品，會不會變得更好玩」，但想
當然爾，組合的數量會變得過於膨脹，也讓其他開發團員提出疑問。
像工程師就提出了「已經黏接物品的話，那原本武器的功能也會一起發動嗎？」，美術也
提出「要做成什麼外觀呢？如果要一一檢測問題的話，那龐大的數量該怎麼驗證呢？」，
遊戲設計師則是提出「武器的名字種類也會變得相當大量，那該怎麼辦呢？」，諸如此類
的疑問逐漸產生了「不太可能吧？」的低氣壓壟罩在團隊之中。
https://p2.bahamut.com.tw/B/2KU/13/127f14421783b2cc20b9c0665f1r9v55.JPG
藤林也在此時向各位聽眾表示「像這樣的氣氛不是很常在開發過程中碰到嗎？」，並進一
步答道：「這時候必須要冷靜下來才行。」在這個階段時，餘料建造的功能還只是剛驗證
階段而已，開發團員將膨大的組合數量視為問題癥結也是必然的。
這時候進行的就是「分解問題」。為了讓功能變得明確，於是將「如果能做到這樣的話好
像不錯」的部分歸類到理想、希望的「許願清單」，不可或缺的功能則是歸類「計畫清單
」做出這樣的分解。
據說在這時機點的許願清單中，也出現過「把首領波克布林的笛子黏接到劍上並揮動的話
，就可以利用笛音操控波克布林」、「在盾牌上黏接翅膀左納烏裝置就能在天空滑翔」等
項目。另一邊的計畫清單則是顯示「外觀表達功能」、「任何東西都能黏接」、「可以黏
接數個素材」、「可以把素材黏接任意地方」等內容。
https://p2.bahamut.com.tw/B/2KU/15/5c59f2938e89dbd1ebedeb89331r9v75.JPG
由於許願清單並不是必要的條件，大多將其做為保留，並開始著手首要處理計畫清單的項
目，並且針對問題根源「龐大的數量」再進一步分解。
以藤林來說，原本預設「可以黏接數個素材」如果黏接了三、四把長槍就可以從遠處攻擊
，「可以把素材黏接任意地方」則是在黏接素材時會因為角度而產生不同；但是在進行驗
證的時候發現了「長槍如果黏接三到四把的話會很難使用」，或是像「黏接複數種類素材
的話，很難從外觀直覺想像該裝備功能」、「以外觀表示功能來說的話，黏接素材的角度
好像沒什麼意義」等事情，並逐步修正。
https://p2.bahamut.com.tw/B/2KU/16/0a4aa3c05dd25fcde078489e831r9v85.JPG
關於角度的部分，也有固定後比較好理解功能的案例
另一方面，也更加確定「任何東西都能黏接」是玩家實行推理時的手段。另外，也注意到
了在武器取名時「名字也能表達功能」好像更能讓玩家理解，於是將從最初的武器階段開
始就會顯示名字的功能加入計畫清單。
以這個結果為基礎，藤林也決定了「不會做的項目」。具體來說就是「不做『兩個以上的
黏接』」、「不做『黏接任意地方』」、「不做『一個個取獨特的名字』」這三大項。
https://p2.bahamut.com.tw/B/2KU/17/63aa3e2855c64ae493c650340c1r9v95.JPG
https://p2.bahamut.com.tw/B/2KU/18/97a07b42d8254af50be73b7a3c1r9va5.JPG
在計畫清單費盡苦心的階段也會重新回顧許願清單的項目，沒想到幫翼＋盾準備了與當初
設想不同的功能
在更新了計畫清單後，工程師覺得「如果黏接的素材不超過兩個的話，好像可以做到」，
而遊戲設計師也覺得「依照一定的規則取名的話好像可行」，團隊成員的見解便像這樣逐
漸改變。
但話是這麼說，即使是以新的條件構成的組合也有多達十二萬筆資料，尤其對美術來說要
實行外觀與名稱的檢查可想而知是一大負擔。
https://p2.bahamut.com.tw/B/2KU/19/4d97b13f6536371ff47cb5f3891r9vb5.JPG
「十二萬筆資料」的問題解決
在藤林講解的部分告一段落後，接著換廣瀨主持，向聽眾介紹他們為了要解決「十二萬筆
資料」的問題，遊戲開發基礎團隊進行的作業。
由餘料建造產生的武器其檢測項目，主要就是外觀與名稱。如以下圖片顯示，當劍與岩石
黏接的時候，並不是岩石放在劍的上面，而是必須要做成劍插進岩石的形式。
還有，取名方向也如前述所說要依照一定的規則設計，如果沒有確實做到這點，那就可能
會讓武器的外觀與名字發生不符合的情況。
https://p2.bahamut.com.tw/B/2KU/20/962b67c70bc1a0fa9feb4160511r9vc5.JPG
https://p2.bahamut.com.tw/B/2KU/21/a1722ae32dec2ef91bef59e0fb1r9vd5.JPG
像這樣的部分就需要由美術和測試人員等檢測成員親眼確認才行。且也不是檢查完一次就
結束，而是在專案重要的時期進行全體的檢測，如果這期間更換了武器或素材的話，更需
要再次檢測進行餘料建造後的狀況。換言之，檢測的次數不只十二萬次。
這麼一來自然就會想減少組合的數量，但廣瀨斷言「如果因此妥協而減少的話，遊戲就會
變得不好玩了」。但是他也提到，檢測的成本如果變高，遊戲就可能面臨無法進步且躊躇
不前的情況，因此，減輕檢測人員的負擔也是非常重要的事。
像這樣實行檢測的時候，通常的流程都是在開發專用機器上啟動遊戲並且在遊戲內進行餘
料建造，同時轉動鏡頭確認外觀，最後再打開林克的裝備欄確認名稱。但是當檢測資料高
達十二萬筆時，不論是誰都看的出來這項作業有多麼花時間與人力。
廣瀨在這時便想到了一個辦法，那就是把餘料建造後的外觀拍成圖片，並且透過網路瀏覽
器確認。如此一來就不用啟動遊戲也能隨時檢測。
https://p2.bahamut.com.tw/B/2KU/22/5288ece6c35ade19b9914849381r9ve5.JPG
多面展開圖與裝備欄畫面等，匯集整個物品相關的複數圖片可以隨時確認
當然，如果只是把圖片並排在一起也很難檢測，於是利用了「圖片布告欄」整理圖片。能
透過各種條件篩選資料，從一覽畫面點擊圖片就會展開詳細畫面，如果發現有問題的部分
，也能直接發布修正要求。另外，如果有想要在遊戲內親自確認的情況，廣瀨也準備了從
圖片布告欄一鍵點擊直接在遊戲中生成的功能。
https://p2.bahamut.com.tw/B/2KU/23/bc1c389514b6b5bd85001824d21r9vf5.JPG
https://p2.bahamut.com.tw/B/2KU/24/1c323359910605eb9701e3cd1b1r9vg5.JPG
也多虧了在拍攝圖片時會在履歷留下日期的關係，當發現問題時也能立刻知道「是什麼時
候發生的？」。由於調查問題是何時發生對開發來說也是一大負擔，恰巧這麼做時能順帶
解決這些調查作業也是一大功成。
這個圖片布告欄確實將檢測作業的負荷降低到可承受的範圍。於是在專案內獲得廣泛好評
，於確認防具或風向搖擺的動作等項目時也很常活用這個圖片布告欄。
為了準備而做的準備是建立團隊文化
講座接著再換藤林主持。接續方才講到為了做出餘料建造的功能而必要的準備作業中，還
需要「建立團隊文化」，換言之就是「為了準備的準備」，而遊戲開發基礎團隊製作的布
告欄功能可以確實派上用場。
藤林表示為了實現餘料建造的想法，團隊成員的目標不僅需要確實共識，也要一起追究並
認識規範中的是與非，甚至製作共通的辭典都是必要的。而這就是團隊文化。
https://p2.bahamut.com.tw/B/2KU/25/f93d3feadbc428c1cde2ea84671r9vh5.JPG
布告欄的成功幫助了團隊文化的形成，但在進行這部份的說明前藤林先展示了《王國之淚
》的製作流程圖，也就是以下畫面。
https://p2.bahamut.com.tw/B/2KU/26/987c17e738ec2932c6298bf2e51r9vi5.JPG
對嶄新的功能與系統向成員進行內容說明，成員理解後在遊戲內實際做出雛形，在流程的
每一階段大家都要玩過一遍，接著整理大家提出的情報，由主要成員精細檢查後將改善的
版本展示給成員……就是不斷重複這樣的過程。
於是為了能順利轉動開發循環「建立團隊文化」不可或缺，尤其在「階段遊玩」、「彙整
資訊」、「精細檢查」要收集龐大的資料並且整理，更需要追求效率化。
針對這部分便是使用了布告欄的系統。成員在階段遊玩中能夠即時把遊戲感想寫下來的地
方，就是將原本的布告欄獨自客製化而成的。
https://p2.bahamut.com.tw/B/2KU/27/882baa74a1008e8d1a142e153c1r9vj5.JPG
布告欄中的投稿，除了編號與投稿者名字還有「很好／很在意」的印象欄、能書寫具體內
容的留言欄、除了投稿者以外的成員對該篇內容表達同意時可按的「對耶！」按鈕，還有
設置上級們能書寫對內容精細檢查結果的方針欄位等。因為「對耶！」的數量是以《薩爾
達傳說》世界中使用的貨幣「盧比」顯示，於是也將該布告欄稱為「盧比布告欄」。
https://p2.bahamut.com.tw/B/2KU/28/c104e8801141abd873f8d7b4971r9vk5.JPG
在確立這個布告欄之後減少了成員們重複提出消息的頻率，成員全體也能直接掌握遊戲項
目在經過何種討論而得到結果，內容更具透明和說服力，於是讓開發循環變得更加圓滑。
不過，只有在書寫留言的布告欄中，若是使用方法錯誤仍會產生問題，甚至有阻礙開發進
度的危險性。因此，在使用布告欄時也定下了以下規則。
不是寫下意見而是寫下資訊
具藤林表示，這是最重要的規則。例如「被針戳到就死了，很不合理。」是意見，改寫成
「被針戳到就死了感覺不合常理。從右邊看的時候明明有注意到針刺，但是從左邊看因為
沒看到針刺而被偷襲」便會成為資訊。也就是在訊息中是否含有關於改善的提示。
https://p2.bahamut.com.tw/B/2KU/29/c6fd60500c13545367f4b2550a1r9vl5.JPG
對其觀感改變的話記得備註
「雖然一開始覺得很難，但是玩久了就變得很好玩」像這樣的遊戲體驗對玩家來說都不陌
生吧。在遊玩過程中對遊戲逐漸改變印象的事並不少見，玩著玩著印象也逐漸改變的狀況
很常見，但如果在最初階段寫下的資訊就這樣一直原封不動的話，資訊的準確度就可能會
變低，所以需要更新。另外，根據備註也能略知投稿者的思考變化，因此讓遊戲設計師在
調整難度時也非常有效。
https://p2.bahamut.com.tw/B/2KU/30/44a85f18dd630e280aee676ba61r9vm5.JPG
不進行議論
雖然布告欄備有對他人投稿進行留言的功能，但是不在此處進行議論，而是如果針對同一
現象有別種感受那就另外投稿。藤林表示，並不是禁止大家議論，而是認為作為新的資訊
投稿的方式比較能促進團隊文化的建立。
https://p2.bahamut.com.tw/B/2KU/31/a5ad7638bbeb8bd9bacea2bb291r9vn5.JPG
盧比布告欄便是遵循這三條規則運營，促進成員之間的共識使團隊文化的建立更進一步，
並讓開發循環變得更好運作。
https://p2.bahamut.com.tw/B/2KU/32/bcd6052f44cf5711b5ad313e761r9vo5.JPG
在盧比布告欄也因為有「餘料建造的必要步驟太多很難使用」這樣的投稿，讓負責人積極
地減少發動功能的步驟
開發基礎團隊也是有備而來
就連廣瀨的遊戲開發基礎團隊，也都是有備而來。具體來說，就是支撐以圖片布告欄為首
的各種服務的基底。
在遊戲開發中煩惱與想要做的新點子很常發生，身為遊戲開發基礎團隊就是要回應這些需
求，雖然想以更加便利的方式將其效率化，但要想直接解決似乎還是會被限制住的樣子。
於是，就像《王國之淚》一樣，製作了一個開發者能夠自由發明的功能。
https://p2.bahamut.com.tw/B/2KU/33/42e301bffbea59c63c4314af191r9vp5.JPG
其中之一，就是「數據資料收集分析」的系統。這原本是工程師提出商量「想要分析 BUG
內容」而準備的東西，只要從開發專用機器匯出錯誤資訊並投稿，就可以一覽時常發生
的 BUG 等，將錯誤狀況變成可視化。
https://p2.bahamut.com.tw/B/2KU/34/9c637a64f03bd6bbbd74786e321r9vq5.JPG
但是該功能本身並不限於用在錯誤資訊，所以開始活用在各式各樣的地方。例如負責管理
時程的負責人可以輸入需求的進度資訊，用以進行專案的進度狀況分析以及預測需求完成
的時間；負責優化的負責人則是在輸入海拉魯各地的負荷數據資料，做出熱點圖。像這樣
，因應每個項目的負責人都能誕生出嶄新的使用方式，利用幅度變得相當廣泛。
https://p2.bahamut.com.tw/B/2KU/35/f69f0a0ff6af60d0be8fdcf5241r9vr5.JPG
https://p2.bahamut.com.tw/B/2KU/36/fb96188f977a19a1437b0935321r9vs5.JPG
https://p2.bahamut.com.tw/B/2KU/37/3c180c13ddad7c58618da18d291r9vt5.JPG
像這樣的網路服務最重要的就是安穩運作的環境，就算停止數台伺服器也能正常運作，
即便增加成員數量讓負荷變大的話，也備有自動增加伺服器數量的功能
廣瀨認為要打造出能幫上專案的工具，實在是一項非常困難的任務。工具的方向性和功能
容易變得沒有考慮到實際需求，所以盡早將開發工具投入現場，在獲得回饋的同時製作是
最有效的方式。
在這樣環境中成長的服務便是「開發專用機器雲端」。這是一項事先預備好的開發專用機
器中，確保能夠馬上使用所需數量的系統，也會同時準備控制開發專用機器的環境。
https://p2.bahamut.com.tw/B/2KU/38/37e8b57db27ffda7e43a4029e91r9vu5.JPG
在以前如果有「必須要有開發專用機器」的需求，那不只是開發專用機器，也需要準備一
台能夠控制環境的電腦，並從配線到初期設定……像這樣繁複的步驟，但是「開發專用機
器雲端」只要一想到就能從網路瀏覽器進行使用手續。
https://p2.bahamut.com.tw/B/2KU/39/85e37654663a6169f68686421a1r9vv5.JPG
如前述所說，圖片布告欄不只用在餘料建造，也用在各式各樣的開發活動上，這便是開發
專用機器雲端的功勞。
在《王國之淚》以外的專案團隊也有利用這個功能，開發專用機器只要一個按鈕就能順利
進行「交接」。如果實際布置了開發專用機的環境，在歸還機器時也是一項大工程，但現
在也免去了這個手續，被閒置的開發專用機也減少了。
https://p2.bahamut.com.tw/B/2KU/40/0ff6fe17d2539e84f788890b881r9vw5.JPG
在講座的最後由藤林再次主持，不僅重新體認到餘料建造團隊與遊戲開發基礎團隊雙方都
是「有備而來」，並且總結「今天的話題，雖然還沒把開發餘料建造過程的所有內容全部
說完，但是能發揮效果的手法與基礎的概念，還有運用手法等，應該可以讓各位聽眾應用
。」
《薩爾達傳說 王國之淚》官方網站：
https://gnn.gamer.com.tw/counter.php?sn=283525

這次CEDEC講座王淚有4場，每一場分享的都很誇張

厲害的是感覺他們還有很多東西可以講XD

放棄2以上餘料有點可惜但能理解

好長...但是內容真有趣12萬筆資料光想就可怕

十二萬種的排列組合全部都測試。 太扯==

看下來這專案管理超強的

為了準備的準備，好有日本人開會討論開會的感覺用大廠的成熟製程，去實現如獨立遊戲般天馬行空的創意，任天堂真的好屌

12萬筆.... 還真的去DEBUG也是一種厲害

老任真正最強的真的是專案管理，而且就算分享了也很難抄，因為首先要有任天堂的那個企業文化才有辦法搞

餘料建造到最後也是數值而已，就最強的武器配攻擊力最大的怪物材料，這麼做還不如我提議過的武器效果疊加

能待在老任團隊裡的一個一個都是怪物啊...

其他廠一定會覺得這什麼瘋子idea直接打槍

12萬種全部測過，難怪搞的出這鬼

真心覺得王淚沒有再拿一次goty有夠可惜

十二萬種真的很屌

推

老任教你debug

老任好猛

看來下一代就會開始導入AI輔助review了

老任的團隊真的很屌

推

可惜王淚惜敗BG3，即便亞軍仍是不容質疑的強大

好扯....這麼長一篇結果連餘料都沒辦法說明完

全力任 真的好強

王淚沒拿GOTY的原因是曠野出了後大家對王淚的標準不是100分 是200分

餘料建造怎麼會只有數值？武器有屬性、粉碎、切割，盾有反彈、攻擊，還有搧風發光以及左納烏裝置的應用

太猛了

史萊姆戰術

夢幻般的專案管理系統。

約束之律者

貨真價實的強，難怪會感覺像未來遊戲

粉碎切割？？你是說看是用來砍樹還是砍礦？？那不是拿專門工具，就是用次階的材料來用，打怪的一樣挑數值最高的

扯到爆說餘料最後只有數值的是多雲. ..最常用的餘料武器之一大砲槍你覺得會是因為數值才一堆人用嗎

鬼

玩家玩得很開心 製作人員很地獄 難怪沒出DLC

薩爾達的魅力之一就是神奇的構思與付諸實行的毅力....當然還有極強的專案管理才有可能達成

餘料建造確實挺可惜的，多達300以上種的合成選項，但效果種類卻只有幾種，大部份都是攻擊力的差異。

推資訊

先推

王國之淚真的好玩 那種 欸 我是不是可以這樣 嘗試之後成功的反饋很爽

任：我甚至還沒有發揮全部實力

推

如果只把餘料武器用來打怪，那無雙那種素材融合機制再改一下就夠了，但顯然不是老任想要的

推 這對這些經驗對專案管理業務都是可貴的經驗分享老任連開發用的配套都自己造 這就是老牌企業的底蘊嗎？

任天堂到底是做遊戲,還是做研究阿一口一

覺得數值的肯定是沒什麼創意的，至今為止X與B還有各種新花樣任天堂就是他媽的世界的主宰！

看來組織管理也是一絕

真的厲害開發與測試人員都要有耐心和實力，不使用既有的市面上的debug平台，而是像盧比佈告欄和之前曠野的地圖看板，很好的契合了他們遊戲開發的方式，又能做到團隊人員之間的平行溝通，好屌

任天堂是真的強啊，會去開發那些超級複雜又沒人開發過的遊戲體驗

超過12萬筆資料要對，老牌企業輕描淡寫的教你怎麼處理。