[閒聊] 薩爾達傳說 王國之淚 打造可動的規格書 重構開發環境
作者: dogluckyno1 2024-09-10 01:10:34
原文標題：【CEDEC 24】《薩爾達傳說 王國之淚》打造「可動的規格書」重構開發環境
原文網址：https://gnn.gamer.com.tw/detail.php?sn=273545
讓開發團隊全員都深入了解遊戲整體，並不論擔任職務都可以提出點子的平行製作手法。
為了實現這種理想，所以下定決心重新建構遊戲的開發環境。在日本遊戲開發者會議「
CEDEC2024」最後一天，有一場以「了解、創作、連結 在《薩爾達傳說 王國之淚》中重
新建構的開發環境與音效製作案例」為題的講座，在其中解說了任天堂開發團隊實際製作
的案例。
https://p2.bahamut.com.tw/B/2KU/45/e43a4b0df6c593f30f434dd7e11rdld5.JPG
登台主講
岡村祐一郎（任天堂 企畫製作部 首席程式設計師）
長田潤也（任天堂 企畫製作部 音效程式設計負責人）
日高祥藏（任天堂 企畫製作部 遊戲製作工具開發負責人）
https://p2.bahamut.com.tw/B/2KU/46/c16c7d18d53da7bfc7bb0c2d361rdle5.JPG
為了實現平行式創作手法，決定完全翻新開發環境
過去在開發遊戲時，因為開發規模都比較小，所以進行決策時的節奏輕快，在溝通交流方
面比很順暢，但近年來因為遊戲開發規模不斷在膨脹的關係，技術的分枝數量增加，開發
時的分工合作也變得更細膩。
想要在這種環境下創作遊戲，通常就會採用讓各個部門的領袖人物下去思考遊戲製作方針
，再分配工作給各個部下的所謂由上至下的創作手法。
只不過在《薩爾達傳說 王國之淚》（以下簡稱為《王國之淚》）的開發工作當中，卻是
以「團隊所有人都可以構思遊戲開發方向並不斷嘗試的平行式創作手法」為目標。可能會
看到美術設計師在考慮到遊戲平衡的前提下去設計新招式這種情況發生，是一種不論擔任
什麼職務都可以盡情提出自己創意點子的製作手法。
雖然團隊當中當然還是會有領袖人物存在，但開發團隊是認為，能夠讓每一個人都像過去
那個時代一樣親自參與創作過程，應該是更容易激出發優秀的點子才對。
https://p2.bahamut.com.tw/B/2KU/48/536c946014f558c40c1f2251931rdlg5.JPG
https://p2.bahamut.com.tw/B/2KU/49/6934aee546b36f3b21077535f81rdlh5.JPG
https://p2.bahamut.com.tw/B/2KU/50/8645b5e56cc20f26a2838156141rdli5.JPG
https://p2.bahamut.com.tw/B/2KU/51/555979c8714687e94f1f18e1511rdlj5.JPG
為了達成這個理想，重點就是必須要讓擔任各種不同職務的成員，都能夠清楚了解到自己
正在製作一款什麼樣的遊戲，岡村祐一良表示在達到這個前提之後，才能夠去「創作」。
雖然後面還會再次提到，但大家可以注意在這邊主講者並不是用「製作」，而是包含了創
造性在內的「創作」字眼，可以從中感受到其重點所在。
https://p2.bahamut.com.tw/B/2KU/52/2587329de780b1b480b22131ee1rdlk5.JPG
想要了解遊戲，可以遊玩正在開發中的版本，請教其他的開發者，又或者是閱讀規格書等
等不同的手段存在。只不過光是遊玩，常常會沒有辦法完全把握規格，而想要找人請教，
又必須要該部份的負責人剛好有空才可以，就算是去閱讀規格書，也會碰上加入遊戲時採
用的規格其實並不一樣的案例。
想要實現平行式創作手法，由於遊戲在開發過程中會不斷變化的關係，所以讓實現的難度
也隨之提昇。在前作《薩爾達傳說 曠野之息》（以下簡稱為《曠野之息》）當中，是採
用將遊戲各方面的動作方法和數值等，原本會以規格書說明的部份轉化為資料，以資料驅
動式手法進行開發。
將從資料中讀取到的情報，製作出表格、圓餅圖或者是投影片等視覺化資料，並且同時去
遊玩遊戲。透過這種兼併兩者方式的「可動規格書」下去了解遊戲，然後再連結到創作行
動上。另外岡村祐一郎特別強調「這並不是指不應該要去製作出規格書」，是表示規格書
雖然可以用來整理遊戲開發者腦海當中的想法，但是並不適合用來了解關於遊戲的最新情
報。
https://p2.bahamut.com.tw/B/2KU/53/6e67984d5e3c5133988e4e6ce51rdll5.JPG
https://p2.bahamut.com.tw/B/2KU/54/9943daeaf151d0a2c05af4d2621rdlm5.JPG
https://p2.bahamut.com.tw/B/2KU/55/a63c486d58f3c4775e616725b31rdln5.JPG
https://p2.bahamut.com.tw/B/2KU/56/9ec380f7680faf376e1fbea6621rdlo5.JPG
在現在一般的遊戲開發過程當中，通常是由核心團隊利用共通的框架去製作出各種不同開
發工具，打造出整合型開發工具讓大家使用，但是在《曠野之息》當中，其實是採用每一
個不同的部份，全都使用不一樣的程式語言和技術去製作的綜合組成方式。
雖然這是一種比起整合型開發工具來說，較為古老的開發手法，但同時也有柔軟性更高，
更容易去應對各式各樣不同遊戲設計的長處。因為只要有構想，不管是誰都可以下去製作
開發工具，所以更容易激發出全新的點子，也比較容易採用全新技術來累積不同的經驗，
促進開發團隊成員的技能成長，其實有相當多不同的長處。
比如說在開發《健身環大冒險》時製作出來的記錄用工具，就有轉用到其他遊戲開發工作
的成果。
但是另一方面，綜合組成方式與整合型開發工具相比之下，各個開發工具之間的連結力較
弱。有時候想要在某個開發工具裡加入一個方便使用的功能，就必須要去解析另一個不同
開發工具的情報才行。而且為了要了解遊戲整體的架構，就必須要同時使用複數不同開發
工具，並且去理解各個資料之間的連結才可以。
而且《曠野之息》的開發工具，因為將加入速度擺在第一優先的關係，有些工具其實沒有
什麼擴充的空間可言。再加上《王國之淚》的遊戲內容與前作相比之下更加複雜，內容量
自然也變得更為龐大。
於是包含岡村祐一郎在內的開發團隊成員，就決定要從頭打造一個全新的開發環境。開始
製作設置在各個開發者電腦裡的「本地資料庫（LocalDB）」、用來管理資料版本的「公
用資料庫（GlobalDB）」，以及讓各資料之間連結視覺化的「專案入口（Project Portal
）」等等開發工具程式。
https://p2.bahamut.com.tw/B/2KU/57/a936383f8cc94a388cffc04c9c1rdlp5.JPG
https://p2.bahamut.com.tw/B/2KU/58/8b55e35bdfaee1c0b4f6f87b941rdlq5.JPG
https://p2.bahamut.com.tw/B/2KU/59/9a74771cd047127d1b5183cd391rdlr5.JPG
https://p2.bahamut.com.tw/B/2KU/61/55f6fde2b1a321e37915672da41rdlt5.JPG
使用資料庫來連結不同的開發工具以及每個人的作業進度
「本地資料庫」是為了解決舊有開發環境的問題之一，也就是各開發工具之間連結力較弱
這個問題的工具。基本構想是先準備作為所有開發工具共用基礎來使用的資料庫，讓開發
工具透過資料庫去讀取各種檔案。只不過單純只是準備一個資料庫，開發第一線人員也不
會去使用。於是就採用了能夠利用在各種不同程式上面的 SQL 工具，讓不管是使用什麼
開發工具，都可以直接讀取到資料庫裡面的檔案。
另外關於要在資料庫裡寫入各種情報的時候，基本上是讓有最了解該檔案的人會下去執行
這個動作。比如說如果是遊戲的 3D 模型，那就是由 3D 模型工具的開發者下去將資料登
錄到資料庫裡面。
雖然這樣的確會增加特定開發者的工作量，但是因為資料庫成為可以共用的基礎部份，所
以即使會有複數開發工具都需要使用到 3D 模型，也就不用再分開來一一去應對，因此反
而能夠降低整體的負擔。
https://p2.bahamut.com.tw/B/2KU/62/4d440d737afa8876a4615d28b31rdlu5.JPG
https://p2.bahamut.com.tw/B/2KU/64/903ce7af843ee34b3c74d179101rdlw5.JPG
https://p2.bahamut.com.tw/B/2KU/65/46b87db46654392e9b91daac721rdlx5.JPG
只不過話雖如此，但即使是對該項檔案最了解的人，實際上也很難去預測其他不同開發工
具，會需要哪一些項目的資料。而且如果採用有人提出需求，就一一去對應該項目的方式
，那反而又會增加負擔，並不現實。
於是就決定在製作「本地資料庫」的時候，採用加入「盡可能多種不同的資料」這種方針
。舉例來說像是 3D 模型的檔案，就會記載包含頂點數量、骨架的名稱以及原型骨架、材
質名稱和使用著色器……等等，資料庫裡面記載的項目越多，就越方便其他開發者嘗試各
種不同的方案。
雖然在構思不同點子的時候，很難事前去預測會讓人想要對哪些項目動手調整，但只要事
先記載好盡可能多樣化的資料，那就能夠立刻對應突如其來的發想。
而且會記載在資料庫裡面的資料，包含 3D 模式、材質、關卡、事件、演員、特效、動畫
、數值以及背景音樂等等構成遊戲的檔案，還有用來製作這些檔案的 Maya 的 .ma 檔案
、 Photoshop 的 .psd 檔案，以及各項程式的源代碼等等，有各種不同種類的資料，可
說是包羅萬象（只不過像是頂點串流（Vertex stream）之類巨大的資料就會被視為例外
）。
https://p2.bahamut.com.tw/B/2KU/67/a9ce0a10e64ad5b16e73e353691rdlz5.JPG
不過就在這樣建構資料庫的過程當中，有人提出了「那資料庫應該要設置在哪裡」這個問
題。一般來說通常會把資料庫設置在伺服器上面，讓每人個使用自己的電腦去讀取資料庫
。只不過在開發過程中進行各種作業需要使用的檔案，基本上是放在每個人自己的電腦裡
面，而且還會因為開發遊戲時出現的不同構想持續加入變動。
這也就是說就算是同一份檔案，也會因為每一個人作業進度不同而產生差異，這樣子自然
就會讓每個人依照自己想法加入的變更，與伺服器上的檔案版本發生衝突，產生「同一份
檔案卻有複數不同版本，那到底是誰的版本才正確？」，這個在遊戲開發過程中大家都很
熟悉的問題。
於是日高祥藏就表示，這時候就必須要換一個想法。既然每一個人在開發過程中都需要進
行不同的作業，那麼就讓每一個人都有專屬於自己的資料庫不就好了嗎……在這個想法當
作前提之下，最後就採用了在每一個人的電腦裡面，都設置一個存在於本地的資料庫這種
做法。而因為是存在本地的資料庫，所以就命名為「本地資料庫」。
https://p2.bahamut.com.tw/B/2KU/68/f5498b47691f120224e258af011rdm05.JPG
https://p2.bahamut.com.tw/B/2KU/69/7cc5f99f5e178e1e0a4c29eb3a1rdm15.JPG
https://p2.bahamut.com.tw/B/2KU/70/0661c17a8fa0ba8f45dd8007e11rdm25.JPG
但雖然說是存在本地，可是每一個人的資料庫都還是有互相連結。而且各種開發工具，也
會透過資料庫互相連結。比如說有人使用 Maya 編輯某個角色模型並且更改了骨架的名稱
，那有用到這個骨架名稱的其他工具，也會更新資料將這個全新的名稱覆寫上去。
而且其他開發者只要有變更檔案內容，並且使用版本管理系統的話，這些變更也會反應到
自己的檔案裡面。這樣就不用去判斷到底誰的版本才正確，而是最新的變更會持續反應到
所有人持有的檔案當中。
只不過在這個系統裡，為了要提昇反應速度，所以刻意排除了不需要的檔案。所以因為對
自己擔任職務沒有必要性，因此沒有存在本地資料庫裡的檔案，就沒有辦法下去更改。
然而就算是這樣說，有時也是會需要用到這些檔案，於是就決定要在「本地資料庫」的系
統中，準備一個設置在伺服器上面的共用型資料庫，也就是「公用資料庫」來管理各種不
同檔案的版本資料。所以在想要使用自己手頭上沒有的檔案時，就可以連進「公用資料庫
」裡面去讀取這些檔案。
https://p2.bahamut.com.tw/B/2KU/71/19920e60ddefff44f7352381381rdm35.JPG
https://p2.bahamut.com.tw/B/2KU/72/8714c5f14b3465b6343e0c4d1c1rdm45.JPG
https://p2.bahamut.com.tw/B/2KU/73/728db2a3cf0e1545bdf26ce2f61rdm55.JPG
https://p2.bahamut.com.tw/B/2KU/74/acce08486d2b893b5052de829f1rdm65.JPG
以「本地資料庫」和「公用資料庫」，解決了開發工具之間連結力較弱的問題。
那現在就要開始處理另外一個問題，也就是「無法理解遊戲構造」。因為遊戲十分複雜，
會記錄在「本地資料庫」裡的情報量十分龐大的關係，很難只看這些情報就去了解到整體
遊戲的構造。
但既然如此就應該要去適當處理分類這些情報，所以就開始構想出一個可以選擇資料的種
類，並且盡可能縮限要讀取的情報範圍，讓使用者可以去追查資料與資料之間關聯的開發
工具，而這就是讓資料關聯視覺化的「專案入口」。
https://p2.bahamut.com.tw/B/2KU/75/c38bb69e4d9bbad9a5e21070451rdm75.JPG
在「專案入口」可以篩選想要尋找的資料種類，並且靠資料名稱以及加在各個資料上的標
籤來進行搜尋。
比如說以「大師之劍（マスターソード）」當關鍵字進行搜尋，除了大師之劍本身以外，
還會看到劍鞘以及台座等關聯項目也列在搜尋結果的清單裡，如果是想要找會被雷劈到的
武器，那就可以使用「金屬製」這個標籤來篩選要搜尋的範圍。
而且因為標籤本身也可以加入各式各樣的條件來進行篩選，所以就準備了相當龐大數量的
標籤。就和前面提到的「本地資料庫」裡要刊載的檔案種類一樣，加入的標籤數量越多，
就越能夠靈活對應每個人發揮出來的創意構想。
在加入的標籤當中，還有「前作就存在的武器」、「會從寶箱掉出來的武器」、「拿弓箭
的敵人」、「會遇見敵人的 NPC 角色」以及「會出現在神殿的設置物件」等等，可以看
出開發團隊為了要打造一個讓人可以進行「創作」的環境，付出了多少努力。
只不過正因為標籤十分詳細而且又多樣化，所以要靠人手去加入標籤就有極限存在。於是
在「專案入口」這個開發工具當中，就會把演員（在這裡指會出現在遊戲中的物件）的數
值也全部都當作是標籤來處理。
由於演員的性質會在資料內以數值化的方式來記載（比如說像是可以燃燒的演員，就會設
定一個可以燃燒的數值），所以只要將這些數值當作標籤對 SQL 送出請求就好。
這個在「專案入口」的設定中被稱為「請求標籤」，和一般的標籤一起搭配運用，就可以
使用十分複雜的條件來進行篩選。
應該可以說是參考自己想要使用的條件數值，直接去產生一個可以在當下使用的標籤吧。
也因為有這個設計，所以關於會使用數值來記載的性質，就不需要以人力來主動去加上標
籤了。
https://p2.bahamut.com.tw/B/2KU/76/10abc7d5cf39d4ba43f2b828d01rdm85.JPG
https://p2.bahamut.com.tw/B/2KU/77/59e6078c31630535a45086b8581rdm95.JPG
https://p2.bahamut.com.tw/B/2KU/78/5a03bdbcb65921e10b34ca901d1rdma5.JPG
https://p2.bahamut.com.tw/B/2KU/80/e5f6a71536f3e4650386d503751rdmc5.JPG
然後為了要把握遊戲的構造，還製作出可以直接看到資料之間連結（參考關係）的功能。
參考關係的箭頭在依照事件→演員→模型設定……這樣順向來表現時，直接使用一般的樹
狀圖就可以，但是要顯示出逆向樹狀圖的時候，就會發生可能會顯示出重複資料的問題，
於是就採用在顯示逆向關係的時候，改用清單方式的手法。
https://p2.bahamut.com.tw/B/2KU/81/4ea5f59e556a915f60035580281rdmd5.JPG
https://p2.bahamut.com.tw/B/2KU/83/2edc26746709d1229ac38ad1971rdmf5.JPG
而就演員和物理設定以及 3D 模型這種沒有直接關聯（離散程度較高）的資料來說，則是
提供了可以查詢各自資料的連結，取得必要情報後顯示成一覽表的功能。
比如說寶箱的配置情報，與放在裡面的演員，還有演員的賣價，這些原本應該是寫在不同
檔案裡面的情報，就會加工為一覽表，並且加上可以直接跳到情報所在位置的按鈕。
另外就波克布林（ボコブリン）來說，在演員表格裡面會有名稱和內容標籤，而在 3D 模
型表格裡會有名稱和邊界框架，在物理設定表格裡則是會記載質量，在這種情況下只要使
用 SQL 就可以製造出將名稱、產生出的縮圖與邊界框架、質量一覽表，以及除錯產生用
的按鈕都一字排開的一覽表。
本來應該要自己去參考每一個不同的資料，從中去理解資料之間的連結，但是透過「專案
入口」就可以加工成一覽表，提供讓人可以馬上就參考所有關聯資料的按鈕。
這樣子就可以量產出 SQL 或者是加工方法，於是就把這個功能稱為「資源表格」。當然
像這類試算表也可以直接用人手製作，但是自動化生產一定比較少會出現失誤。
https://p2.bahamut.com.tw/B/2KU/84/f98eda06597cee8f9498974bbb1rdmg5.JPG
https://p2.bahamut.com.tw/B/2KU/86/1b60c9f856200fdb2c9b0ab65f1rdmi5.JPG
https://p2.bahamut.com.tw/B/2KU/87/6617171cb1f46c81147a9780a91rdmj5.JPG
利用「本地資料庫」和「專案入口」，製作音效演出細節
接下來登台的長田潤也，則是以音效團隊的角度，舉出實例來解說活用「本地資料庫」和
「專案入口」的範例。
由於音效團隊工作性質之故，通常都是在遊戲開發後期才開始動工，但團隊一直都有希望
可以在早期就開始主動參與遊戲製作的想法。只要有「本地資料庫」和「專案入口」這兩
個開發工具，就可以在播放動畫片段的同時加入音效，又或者是介接到用來編輯動畫資料
的開發工具上。
而且還有加入在其他開發者變更動畫資料的時候，就會自動通知關聯音效製作者的設計，
讓整體作業效率有明顯提昇。
https://p2.bahamut.com.tw/B/2KU/88/598293de6f43ffb114ebd6f7531rdmk5.JPG
https://p2.bahamut.com.tw/B/2KU/89/a24ff0e624a0affe8aada446321rdml5.JPG
而且在格魯德小鎮（ゲルドの街）防衛戰這個遊戲事件中，還能夠讓音效演出變得更加緊
密。由於這在遊戲故事上也是一個十分重要的場面，所以就有人提出希望可以加入依照戰
鬥當下狀況，讓音效出現變化的演出這種提案。
於是就在利用「專案入口」仔細把握這個事件的規格之後，成功加入了在適當的時機去切
換戰鬥背景音樂，以及每一次破壞吉波得（ギブド）巢穴時樂曲都會發生變化等等，更具
有互動性的演出手法。
而在本作中玩家使用的武器，可以透過「餘料建造（スクラビルド）」黏貼上不同素材甚
至是其他的武器，每次黏貼後音效都會出現變化，設計可說是十分複雜，而在這方面「專
案入口」也是幫上很大的忙。
雖然只調查餘料建造的數值，也很難去了解比如說是用什麼方式黏貼上哪一種道具，也就
是整體產生了什麼樣的變化，但只要利用在「專案入口」當中，為了方便遊戲設計師調整
數值而加入的預覽，就可以完全理解當下使用的武器規格。
雖然說有的時候，在使用餘料建造黏貼上素材前後，音效也不會出現變化，但只要透過「
專案入口」調查，就可以馬上了解到這是刻意為之的設定，還是單純設定時出現失誤。
長田潤也表示，「專案入口」可以說是一個可信度極高的情報收集基礎建設工具，讓團隊
能夠放心打造遊戲細節到最後一刻，給這項開發工具相當高的評價。
https://p2.bahamut.com.tw/B/2KU/90/0f75556b05c0b4be9a4ba5c4b21rdmm5.JPG
https://p2.bahamut.com.tw/B/2KU/91/c5f6b7f8af839d20c4bd524fb41rdmn5.JPG
https://p2.bahamut.com.tw/B/2KU/92/96cf0638a05cc28c2e4a019fda1rdmo5.JPG
https://p2.bahamut.com.tw/B/2KU/93/8b20ab7b5a706cccd8dd1ca9dc1rdmp5.JPG
讓參與開發的所有開發者，不論其職務都可以提出點子，透過從不同視角出發的創意發想
讓遊戲變得更加完善……這應該是遊戲開發工作的理想狀態之一。然而當專案規模越變越
龐大，距離這種理想也就越來越遠。可以說在《王國之淚》的開發工作當中，就是透過打
造出各種不同的開發工具，盡最大努力去維持這種理想的狀態。
在近年來所謂 3A 大作當道，因為大規模遊戲作品成為主流，讓開發工作越來越高度分工
的時代裡，負責遊戲末端工程的開發者，真的是很難去把握遊戲的全貌，實際上也有人指
出這種狀況，甚至會影響到開發者投入開發遊戲的動力，本次講座中講解的這些工具，從
筆者個人角度來看，也明確感受到是一種能夠去解決這種問題的手法。
雖然這只是筆者個人的感想，但是岡村祐一郎在這場講座當中，會特別強調「創作」這個
用字，而不是單純使用「製作」，應該就是想要強調大家不應該只把遊戲開發當作一種工
作，只是機械性地去投入製作，而是要在其中加入創意發想去完成一場創作才對。
從不同職務角度出發能看到的事情不同，所以能夠催生出的點子也不一樣。如果能夠透過
自己本身職務特有的觀點和創造性，去參與遊戲開發工作的話，想當然是一定可以大幅提
昇開發第一線人員的士氣才對吧。
正如同岡村祐一郎本人指出的一樣，就算是採用讓領導人物決定一切的由上至下方式，還
是可以順利完成遊戲開發。而且即使費盡苦心開發出一大堆開發工具，也不能保證一定可
以完成比由上至下方式還要出色的遊戲。只不過《王國之淚》即使是如此，依然選擇了這
條要克服許多難關的道路。
本作之所以能夠在全世界各個國家，讓各個不同年齡層的玩家都給予極高評價，應該就是
因為費的這些苦功，的確有開花結果獲得成效的關係才對吧。當然這絕對不是一種能夠馬
上就讓所有遊戲開發現場模彷的手法，但是就在必須要在截止期限之前完成遊戲的現實考
驗當中，還能夠堅持要去追求理想，的確是件讓人感覺到十分精彩感動的事情。
https://p2.bahamut.com.tw/B/2KU/94/d5d0f446ed13b67a855d3089891rdmq5.JPG
原文網址：https://gnn.gamer.com.tw/detail.php?sn=273545
讓開發團隊全員都深入了解遊戲整體，並不論擔任職務都可以提出點子的平行製作手法。
為了實現這種理想，所以下定決心重新建構遊戲的開發環境。在日本遊戲開發者會議「
CEDEC2024」最後一天，有一場以「了解、創作、連結 在《薩爾達傳說 王國之淚》中重
新建構的開發環境與音效製作案例」為題的講座，在其中解說了任天堂開發團隊實際製作
的案例。
https://p2.bahamut.com.tw/B/2KU/45/e43a4b0df6c593f30f434dd7e11rdld5.JPG
登台主講
岡村祐一郎（任天堂 企畫製作部 首席程式設計師）
長田潤也（任天堂 企畫製作部 音效程式設計負責人）
日高祥藏（任天堂 企畫製作部 遊戲製作工具開發負責人）
https://p2.bahamut.com.tw/B/2KU/46/c16c7d18d53da7bfc7bb0c2d361rdle5.JPG
為了實現平行式創作手法，決定完全翻新開發環境
過去在開發遊戲時，因為開發規模都比較小，所以進行決策時的節奏輕快，在溝通交流方
面比很順暢，但近年來因為遊戲開發規模不斷在膨脹的關係，技術的分枝數量增加，開發
時的分工合作也變得更細膩。
想要在這種環境下創作遊戲，通常就會採用讓各個部門的領袖人物下去思考遊戲製作方針
，再分配工作給各個部下的所謂由上至下的創作手法。
只不過在《薩爾達傳說 王國之淚》（以下簡稱為《王國之淚》）的開發工作當中，卻是
以「團隊所有人都可以構思遊戲開發方向並不斷嘗試的平行式創作手法」為目標。可能會
看到美術設計師在考慮到遊戲平衡的前提下去設計新招式這種情況發生，是一種不論擔任
什麼職務都可以盡情提出自己創意點子的製作手法。
雖然團隊當中當然還是會有領袖人物存在，但開發團隊是認為，能夠讓每一個人都像過去
那個時代一樣親自參與創作過程，應該是更容易激出發優秀的點子才對。
https://p2.bahamut.com.tw/B/2KU/48/536c946014f558c40c1f2251931rdlg5.JPG
https://p2.bahamut.com.tw/B/2KU/49/6934aee546b36f3b21077535f81rdlh5.JPG
https://p2.bahamut.com.tw/B/2KU/50/8645b5e56cc20f26a2838156141rdli5.JPG
https://p2.bahamut.com.tw/B/2KU/51/555979c8714687e94f1f18e1511rdlj5.JPG
為了達成這個理想，重點就是必須要讓擔任各種不同職務的成員，都能夠清楚了解到自己
正在製作一款什麼樣的遊戲，岡村祐一良表示在達到這個前提之後，才能夠去「創作」。
雖然後面還會再次提到，但大家可以注意在這邊主講者並不是用「製作」，而是包含了創
造性在內的「創作」字眼，可以從中感受到其重點所在。
https://p2.bahamut.com.tw/B/2KU/52/2587329de780b1b480b22131ee1rdlk5.JPG
想要了解遊戲，可以遊玩正在開發中的版本，請教其他的開發者，又或者是閱讀規格書等
等不同的手段存在。只不過光是遊玩，常常會沒有辦法完全把握規格，而想要找人請教，
又必須要該部份的負責人剛好有空才可以，就算是去閱讀規格書，也會碰上加入遊戲時採
用的規格其實並不一樣的案例。
想要實現平行式創作手法，由於遊戲在開發過程中會不斷變化的關係，所以讓實現的難度
也隨之提昇。在前作《薩爾達傳說 曠野之息》（以下簡稱為《曠野之息》）當中，是採
用將遊戲各方面的動作方法和數值等，原本會以規格書說明的部份轉化為資料，以資料驅
動式手法進行開發。
將從資料中讀取到的情報，製作出表格、圓餅圖或者是投影片等視覺化資料，並且同時去
遊玩遊戲。透過這種兼併兩者方式的「可動規格書」下去了解遊戲，然後再連結到創作行
動上。另外岡村祐一郎特別強調「這並不是指不應該要去製作出規格書」，是表示規格書
雖然可以用來整理遊戲開發者腦海當中的想法，但是並不適合用來了解關於遊戲的最新情
報。
https://p2.bahamut.com.tw/B/2KU/53/6e67984d5e3c5133988e4e6ce51rdll5.JPG
https://p2.bahamut.com.tw/B/2KU/54/9943daeaf151d0a2c05af4d2621rdlm5.JPG
https://p2.bahamut.com.tw/B/2KU/55/a63c486d58f3c4775e616725b31rdln5.JPG
https://p2.bahamut.com.tw/B/2KU/56/9ec380f7680faf376e1fbea6621rdlo5.JPG
在現在一般的遊戲開發過程當中，通常是由核心團隊利用共通的框架去製作出各種不同開
發工具，打造出整合型開發工具讓大家使用，但是在《曠野之息》當中，其實是採用每一
個不同的部份，全都使用不一樣的程式語言和技術去製作的綜合組成方式。
雖然這是一種比起整合型開發工具來說，較為古老的開發手法，但同時也有柔軟性更高，
更容易去應對各式各樣不同遊戲設計的長處。因為只要有構想，不管是誰都可以下去製作
開發工具，所以更容易激發出全新的點子，也比較容易採用全新技術來累積不同的經驗，
促進開發團隊成員的技能成長，其實有相當多不同的長處。
比如說在開發《健身環大冒險》時製作出來的記錄用工具，就有轉用到其他遊戲開發工作
的成果。
但是另一方面，綜合組成方式與整合型開發工具相比之下，各個開發工具之間的連結力較
弱。有時候想要在某個開發工具裡加入一個方便使用的功能，就必須要去解析另一個不同
開發工具的情報才行。而且為了要了解遊戲整體的架構，就必須要同時使用複數不同開發
工具，並且去理解各個資料之間的連結才可以。
而且《曠野之息》的開發工具，因為將加入速度擺在第一優先的關係，有些工具其實沒有
什麼擴充的空間可言。再加上《王國之淚》的遊戲內容與前作相比之下更加複雜，內容量
自然也變得更為龐大。
於是包含岡村祐一郎在內的開發團隊成員，就決定要從頭打造一個全新的開發環境。開始
製作設置在各個開發者電腦裡的「本地資料庫（LocalDB）」、用來管理資料版本的「公
用資料庫（GlobalDB）」，以及讓各資料之間連結視覺化的「專案入口（Project Portal
）」等等開發工具程式。
https://p2.bahamut.com.tw/B/2KU/57/a936383f8cc94a388cffc04c9c1rdlp5.JPG
https://p2.bahamut.com.tw/B/2KU/58/8b55e35bdfaee1c0b4f6f87b941rdlq5.JPG
https://p2.bahamut.com.tw/B/2KU/59/9a74771cd047127d1b5183cd391rdlr5.JPG
https://p2.bahamut.com.tw/B/2KU/61/55f6fde2b1a321e37915672da41rdlt5.JPG
使用資料庫來連結不同的開發工具以及每個人的作業進度
「本地資料庫」是為了解決舊有開發環境的問題之一，也就是各開發工具之間連結力較弱
這個問題的工具。基本構想是先準備作為所有開發工具共用基礎來使用的資料庫，讓開發
工具透過資料庫去讀取各種檔案。只不過單純只是準備一個資料庫，開發第一線人員也不
會去使用。於是就採用了能夠利用在各種不同程式上面的 SQL 工具，讓不管是使用什麼
開發工具，都可以直接讀取到資料庫裡面的檔案。
另外關於要在資料庫裡寫入各種情報的時候，基本上是讓有最了解該檔案的人會下去執行
這個動作。比如說如果是遊戲的 3D 模型，那就是由 3D 模型工具的開發者下去將資料登
錄到資料庫裡面。
雖然這樣的確會增加特定開發者的工作量，但是因為資料庫成為可以共用的基礎部份，所
以即使會有複數開發工具都需要使用到 3D 模型，也就不用再分開來一一去應對，因此反
而能夠降低整體的負擔。
https://p2.bahamut.com.tw/B/2KU/62/4d440d737afa8876a4615d28b31rdlu5.JPG
https://p2.bahamut.com.tw/B/2KU/64/903ce7af843ee34b3c74d179101rdlw5.JPG
https://p2.bahamut.com.tw/B/2KU/65/46b87db46654392e9b91daac721rdlx5.JPG
只不過話雖如此，但即使是對該項檔案最了解的人，實際上也很難去預測其他不同開發工
具，會需要哪一些項目的資料。而且如果採用有人提出需求，就一一去對應該項目的方式
，那反而又會增加負擔，並不現實。
於是就決定在製作「本地資料庫」的時候，採用加入「盡可能多種不同的資料」這種方針
。舉例來說像是 3D 模型的檔案，就會記載包含頂點數量、骨架的名稱以及原型骨架、材
質名稱和使用著色器……等等，資料庫裡面記載的項目越多，就越方便其他開發者嘗試各
種不同的方案。
雖然在構思不同點子的時候，很難事前去預測會讓人想要對哪些項目動手調整，但只要事
先記載好盡可能多樣化的資料，那就能夠立刻對應突如其來的發想。
而且會記載在資料庫裡面的資料，包含 3D 模式、材質、關卡、事件、演員、特效、動畫
、數值以及背景音樂等等構成遊戲的檔案，還有用來製作這些檔案的 Maya 的 .ma 檔案
、 Photoshop 的 .psd 檔案，以及各項程式的源代碼等等，有各種不同種類的資料，可
說是包羅萬象（只不過像是頂點串流（Vertex stream）之類巨大的資料就會被視為例外
）。
https://p2.bahamut.com.tw/B/2KU/67/a9ce0a10e64ad5b16e73e353691rdlz5.JPG
不過就在這樣建構資料庫的過程當中，有人提出了「那資料庫應該要設置在哪裡」這個問
題。一般來說通常會把資料庫設置在伺服器上面，讓每人個使用自己的電腦去讀取資料庫
。只不過在開發過程中進行各種作業需要使用的檔案，基本上是放在每個人自己的電腦裡
面，而且還會因為開發遊戲時出現的不同構想持續加入變動。
這也就是說就算是同一份檔案，也會因為每一個人作業進度不同而產生差異，這樣子自然
就會讓每個人依照自己想法加入的變更，與伺服器上的檔案版本發生衝突，產生「同一份
檔案卻有複數不同版本，那到底是誰的版本才正確？」，這個在遊戲開發過程中大家都很
熟悉的問題。
於是日高祥藏就表示，這時候就必須要換一個想法。既然每一個人在開發過程中都需要進
行不同的作業，那麼就讓每一個人都有專屬於自己的資料庫不就好了嗎……在這個想法當
作前提之下，最後就採用了在每一個人的電腦裡面，都設置一個存在於本地的資料庫這種
做法。而因為是存在本地的資料庫，所以就命名為「本地資料庫」。
https://p2.bahamut.com.tw/B/2KU/68/f5498b47691f120224e258af011rdm05.JPG
https://p2.bahamut.com.tw/B/2KU/69/7cc5f99f5e178e1e0a4c29eb3a1rdm15.JPG
https://p2.bahamut.com.tw/B/2KU/70/0661c17a8fa0ba8f45dd8007e11rdm25.JPG
但雖然說是存在本地，可是每一個人的資料庫都還是有互相連結。而且各種開發工具，也
會透過資料庫互相連結。比如說有人使用 Maya 編輯某個角色模型並且更改了骨架的名稱
，那有用到這個骨架名稱的其他工具，也會更新資料將這個全新的名稱覆寫上去。
而且其他開發者只要有變更檔案內容，並且使用版本管理系統的話，這些變更也會反應到
自己的檔案裡面。這樣就不用去判斷到底誰的版本才正確，而是最新的變更會持續反應到
所有人持有的檔案當中。
只不過在這個系統裡，為了要提昇反應速度，所以刻意排除了不需要的檔案。所以因為對
自己擔任職務沒有必要性，因此沒有存在本地資料庫裡的檔案，就沒有辦法下去更改。
然而就算是這樣說，有時也是會需要用到這些檔案，於是就決定要在「本地資料庫」的系
統中，準備一個設置在伺服器上面的共用型資料庫，也就是「公用資料庫」來管理各種不
同檔案的版本資料。所以在想要使用自己手頭上沒有的檔案時，就可以連進「公用資料庫
」裡面去讀取這些檔案。
https://p2.bahamut.com.tw/B/2KU/71/19920e60ddefff44f7352381381rdm35.JPG
https://p2.bahamut.com.tw/B/2KU/72/8714c5f14b3465b6343e0c4d1c1rdm45.JPG
https://p2.bahamut.com.tw/B/2KU/73/728db2a3cf0e1545bdf26ce2f61rdm55.JPG
https://p2.bahamut.com.tw/B/2KU/74/acce08486d2b893b5052de829f1rdm65.JPG
以「本地資料庫」和「公用資料庫」，解決了開發工具之間連結力較弱的問題。
那現在就要開始處理另外一個問題，也就是「無法理解遊戲構造」。因為遊戲十分複雜，
會記錄在「本地資料庫」裡的情報量十分龐大的關係，很難只看這些情報就去了解到整體
遊戲的構造。
但既然如此就應該要去適當處理分類這些情報，所以就開始構想出一個可以選擇資料的種
類，並且盡可能縮限要讀取的情報範圍，讓使用者可以去追查資料與資料之間關聯的開發
工具，而這就是讓資料關聯視覺化的「專案入口」。
https://p2.bahamut.com.tw/B/2KU/75/c38bb69e4d9bbad9a5e21070451rdm75.JPG
在「專案入口」可以篩選想要尋找的資料種類，並且靠資料名稱以及加在各個資料上的標
籤來進行搜尋。
比如說以「大師之劍（マスターソード）」當關鍵字進行搜尋，除了大師之劍本身以外，
還會看到劍鞘以及台座等關聯項目也列在搜尋結果的清單裡，如果是想要找會被雷劈到的
武器，那就可以使用「金屬製」這個標籤來篩選要搜尋的範圍。
而且因為標籤本身也可以加入各式各樣的條件來進行篩選，所以就準備了相當龐大數量的
標籤。就和前面提到的「本地資料庫」裡要刊載的檔案種類一樣，加入的標籤數量越多，
就越能夠靈活對應每個人發揮出來的創意構想。
在加入的標籤當中，還有「前作就存在的武器」、「會從寶箱掉出來的武器」、「拿弓箭
的敵人」、「會遇見敵人的 NPC 角色」以及「會出現在神殿的設置物件」等等，可以看
出開發團隊為了要打造一個讓人可以進行「創作」的環境，付出了多少努力。
只不過正因為標籤十分詳細而且又多樣化，所以要靠人手去加入標籤就有極限存在。於是
在「專案入口」這個開發工具當中，就會把演員（在這裡指會出現在遊戲中的物件）的數
值也全部都當作是標籤來處理。
由於演員的性質會在資料內以數值化的方式來記載（比如說像是可以燃燒的演員，就會設
定一個可以燃燒的數值），所以只要將這些數值當作標籤對 SQL 送出請求就好。
這個在「專案入口」的設定中被稱為「請求標籤」，和一般的標籤一起搭配運用，就可以
使用十分複雜的條件來進行篩選。
應該可以說是參考自己想要使用的條件數值，直接去產生一個可以在當下使用的標籤吧。
也因為有這個設計，所以關於會使用數值來記載的性質，就不需要以人力來主動去加上標
籤了。
https://p2.bahamut.com.tw/B/2KU/76/10abc7d5cf39d4ba43f2b828d01rdm85.JPG
https://p2.bahamut.com.tw/B/2KU/77/59e6078c31630535a45086b8581rdm95.JPG
https://p2.bahamut.com.tw/B/2KU/78/5a03bdbcb65921e10b34ca901d1rdma5.JPG
https://p2.bahamut.com.tw/B/2KU/80/e5f6a71536f3e4650386d503751rdmc5.JPG
然後為了要把握遊戲的構造，還製作出可以直接看到資料之間連結（參考關係）的功能。
參考關係的箭頭在依照事件→演員→模型設定……這樣順向來表現時，直接使用一般的樹
狀圖就可以，但是要顯示出逆向樹狀圖的時候，就會發生可能會顯示出重複資料的問題，
於是就採用在顯示逆向關係的時候，改用清單方式的手法。
https://p2.bahamut.com.tw/B/2KU/81/4ea5f59e556a915f60035580281rdmd5.JPG
https://p2.bahamut.com.tw/B/2KU/83/2edc26746709d1229ac38ad1971rdmf5.JPG
而就演員和物理設定以及 3D 模型這種沒有直接關聯（離散程度較高）的資料來說，則是
提供了可以查詢各自資料的連結，取得必要情報後顯示成一覽表的功能。
比如說寶箱的配置情報，與放在裡面的演員，還有演員的賣價，這些原本應該是寫在不同
檔案裡面的情報，就會加工為一覽表，並且加上可以直接跳到情報所在位置的按鈕。
另外就波克布林（ボコブリン）來說，在演員表格裡面會有名稱和內容標籤，而在 3D 模
型表格裡會有名稱和邊界框架，在物理設定表格裡則是會記載質量，在這種情況下只要使
用 SQL 就可以製造出將名稱、產生出的縮圖與邊界框架、質量一覽表，以及除錯產生用
的按鈕都一字排開的一覽表。
本來應該要自己去參考每一個不同的資料，從中去理解資料之間的連結，但是透過「專案
入口」就可以加工成一覽表，提供讓人可以馬上就參考所有關聯資料的按鈕。
這樣子就可以量產出 SQL 或者是加工方法，於是就把這個功能稱為「資源表格」。當然
像這類試算表也可以直接用人手製作，但是自動化生產一定比較少會出現失誤。
https://p2.bahamut.com.tw/B/2KU/84/f98eda06597cee8f9498974bbb1rdmg5.JPG
https://p2.bahamut.com.tw/B/2KU/86/1b60c9f856200fdb2c9b0ab65f1rdmi5.JPG
https://p2.bahamut.com.tw/B/2KU/87/6617171cb1f46c81147a9780a91rdmj5.JPG
利用「本地資料庫」和「專案入口」，製作音效演出細節
接下來登台的長田潤也，則是以音效團隊的角度，舉出實例來解說活用「本地資料庫」和
「專案入口」的範例。
由於音效團隊工作性質之故，通常都是在遊戲開發後期才開始動工，但團隊一直都有希望
可以在早期就開始主動參與遊戲製作的想法。只要有「本地資料庫」和「專案入口」這兩
個開發工具，就可以在播放動畫片段的同時加入音效，又或者是介接到用來編輯動畫資料
的開發工具上。
而且還有加入在其他開發者變更動畫資料的時候，就會自動通知關聯音效製作者的設計，
讓整體作業效率有明顯提昇。
https://p2.bahamut.com.tw/B/2KU/88/598293de6f43ffb114ebd6f7531rdmk5.JPG
https://p2.bahamut.com.tw/B/2KU/89/a24ff0e624a0affe8aada446321rdml5.JPG
而且在格魯德小鎮（ゲルドの街）防衛戰這個遊戲事件中，還能夠讓音效演出變得更加緊
密。由於這在遊戲故事上也是一個十分重要的場面，所以就有人提出希望可以加入依照戰
鬥當下狀況，讓音效出現變化的演出這種提案。
於是就在利用「專案入口」仔細把握這個事件的規格之後，成功加入了在適當的時機去切
換戰鬥背景音樂，以及每一次破壞吉波得（ギブド）巢穴時樂曲都會發生變化等等，更具
有互動性的演出手法。
而在本作中玩家使用的武器，可以透過「餘料建造（スクラビルド）」黏貼上不同素材甚
至是其他的武器，每次黏貼後音效都會出現變化，設計可說是十分複雜，而在這方面「專
案入口」也是幫上很大的忙。
雖然只調查餘料建造的數值，也很難去了解比如說是用什麼方式黏貼上哪一種道具，也就
是整體產生了什麼樣的變化，但只要利用在「專案入口」當中，為了方便遊戲設計師調整
數值而加入的預覽，就可以完全理解當下使用的武器規格。
雖然說有的時候，在使用餘料建造黏貼上素材前後，音效也不會出現變化，但只要透過「
專案入口」調查，就可以馬上了解到這是刻意為之的設定，還是單純設定時出現失誤。
長田潤也表示，「專案入口」可以說是一個可信度極高的情報收集基礎建設工具，讓團隊
能夠放心打造遊戲細節到最後一刻，給這項開發工具相當高的評價。
https://p2.bahamut.com.tw/B/2KU/90/0f75556b05c0b4be9a4ba5c4b21rdmm5.JPG
https://p2.bahamut.com.tw/B/2KU/91/c5f6b7f8af839d20c4bd524fb41rdmn5.JPG
https://p2.bahamut.com.tw/B/2KU/92/96cf0638a05cc28c2e4a019fda1rdmo5.JPG
https://p2.bahamut.com.tw/B/2KU/93/8b20ab7b5a706cccd8dd1ca9dc1rdmp5.JPG
讓參與開發的所有開發者，不論其職務都可以提出點子，透過從不同視角出發的創意發想
讓遊戲變得更加完善……這應該是遊戲開發工作的理想狀態之一。然而當專案規模越變越
龐大，距離這種理想也就越來越遠。可以說在《王國之淚》的開發工作當中，就是透過打
造出各種不同的開發工具，盡最大努力去維持這種理想的狀態。
在近年來所謂 3A 大作當道，因為大規模遊戲作品成為主流，讓開發工作越來越高度分工
的時代裡，負責遊戲末端工程的開發者，真的是很難去把握遊戲的全貌，實際上也有人指
出這種狀況，甚至會影響到開發者投入開發遊戲的動力，本次講座中講解的這些工具，從
筆者個人角度來看，也明確感受到是一種能夠去解決這種問題的手法。
雖然這只是筆者個人的感想，但是岡村祐一郎在這場講座當中，會特別強調「創作」這個
用字，而不是單純使用「製作」，應該就是想要強調大家不應該只把遊戲開發當作一種工
作，只是機械性地去投入製作，而是要在其中加入創意發想去完成一場創作才對。
從不同職務角度出發能看到的事情不同，所以能夠催生出的點子也不一樣。如果能夠透過
自己本身職務特有的觀點和創造性，去參與遊戲開發工作的話，想當然是一定可以大幅提
昇開發第一線人員的士氣才對吧。
正如同岡村祐一郎本人指出的一樣，就算是採用讓領導人物決定一切的由上至下方式，還
是可以順利完成遊戲開發。而且即使費盡苦心開發出一大堆開發工具，也不能保證一定可
以完成比由上至下方式還要出色的遊戲。只不過《王國之淚》即使是如此，依然選擇了這
條要克服許多難關的道路。
本作之所以能夠在全世界各個國家，讓各個不同年齡層的玩家都給予極高評價，應該就是
因為費的這些苦功，的確有開花結果獲得成效的關係才對吧。當然這絕對不是一種能夠馬
上就讓所有遊戲開發現場模彷的手法，但是就在必須要在截止期限之前完成遊戲的現實考
驗當中，還能夠堅持要去追求理想，的確是件讓人感覺到十分精彩感動的事情。
https://p2.bahamut.com.tw/B/2KU/94/d5d0f446ed13b67a855d3089891rdmq5.JPG
作者: lucky0417 (L.W) 2024-09-10 01:15:00
卡
作者: zxcmoney (ä¿®å¸) 2024-09-10 01:18:00
有些概念在資策會的課程也有聽過就是不知道台灣的遊戲業落實到什麼程度
作者: XFarter (劈哩啪啦碰碰碰) 2024-09-10 01:24:00
鬼
作者: tiger870316 (Chien) 2024-09-10 01:30:00
厲害欸
作者: Hsan (亞熱帶大叔) 2024-09-10 02:09:00
幹那PM要超猛...
作者: yo0529 (Mojito) 2024-09-10 02:11:00
老任的專案管理真的超猛
作者: loesoo (小柳) 2024-09-10 02:17:00
先跪
作者: endorphin424 (endorphin424) 2024-09-10 02:20:00
設計出這種做法感覺也是很花錢花時間花精力，真不愧是充斥著鬼才的任天堂
作者: skycat2216 (skycat2216) 2024-09-10 02:23:00
SVN++?
作者: ohha0221 (蛋笨是的唸來過倒) 2024-09-10 02:23:00
某些有點像git的概念 但又更貼近遊戲設計 厲害
作者: shys4339 (longcat1234) 2024-09-10 02:27:00
鬼
作者: dreamerXYZ (○╳△□) 2024-09-10 02:34:00
猛
作者: katuski (牙月) 2024-09-10 02:37:00
竟然能結合不同程式語言的個別開發成果，老任真的有黑科技。（褒
作者: RushMonkey (無腦猴) 2024-09-10 02:39:00
這種技術老任願意分享真的好猛*技術概念跟心得
作者: sd2567 (starseed) 2024-09-10 02:41:00
這pm有點猛
作者: rockmanx52 (ゴミ丼 わがんりんにゃれ) 2024-09-10 02:41:00
鬼神般的專案管理因為他們其實也知道這些他們認為基本的東西別人也學不來吧
作者: PatrickYao (PatrickYao) 2024-09-10 02:50:00
老任的遊戲理念一直都是“共榮”的，抓一堆專利在手上卻不私藏也不拿來賺錢，只為了讓大家都能輕鬆用上他們的專利來開發遊戲，這樣才能一直有心血注入，作為三大主機廠中唯一一個遊戲專門，才能不斷推出新遊戲
作者: rockmanx52 (ゴミ丼 わがんりんにゃれ) 2024-09-10 02:54:00
其實還是有啦 十字鍵專利還在的時候是收錢的當時DC的控制器就有付錢
作者: JohnnyRev (Espejo水天) 2024-09-10 03:32:00
真的很感動 原來是這樣製作出來的 能實踐這種管理真的要超猛
作者: smallsteel (小鋼) 2024-09-10 06:21:00
並不是不藏私，而是大部分這些概念都不是新東西理想中的最佳結構，但實際要實行是會被白眼說"做夢比較快"，然後任天堂她媽真的辦到了*這種規模下要實行他們的PM到底是甚麼妖魔鬼怪
作者: Wangdy (蒙古人) 2024-09-10 06:30:00
沒有相關業界經驗，看不懂欸
作者: tamynumber1 (Bob) 2024-09-10 06:34:00
能夠確切執行真的很厲害相關經驗能夠傳承並應用在其他遊戲上也很厲害某些遊戲公司明明有上一代開發經驗了還是要從頭到尾再踩一次
作者: devilhades (菲特) 2024-09-10 06:57:00
講解的也太細了，這就是所謂的把餅做大嗎...
作者: efkfkp (Heroprove) 2024-09-10 06:58:00
天下第一高手不藏私，廣發九陰真經抄本的感覺
作者: freedom80017 (大頭公) 2024-09-10 07:07:00
老任：就是基本功而已，我們沒什麼特別的，只是普通的做遊戲，說不定下一個超越任天堂的工作室正呱呱落地
作者: mkhl3 (承夢草) 2024-09-10 07:09:00
這是什麼鬼(稱讚語調
作者: y0707186 (新阿姆斯特旋風噴射阿姆) 2024-09-10 07:20:00
任天堂系統厲害
作者: papertim (吃紙小鹿) 2024-09-10 07:29:00
這是管理學教材嗎？
作者: mikopeko (pekomikotete) 2024-09-10 07:34:00
我知道了，任天堂PM最強
作者: naya7415963 (稻草魚) 2024-09-10 07:41:00
老任，真的好強
作者: spfy (spfy) 2024-09-10 07:45:00
有當過工程師都知道他們講的這些一般公司根本不可能做到
作者: bnn (前途無亮回頭是暗) 2024-09-10 07:57:00
這是個很鬼神的管理系統... 反正別人抄不起來
作者: Ashen19 2024-09-10 08:06:00
推個，跟鬼一樣
作者: cloudin (☁雲應) 2024-09-10 08:15:00
收下我的膝蓋
作者: avans (阿緯) 2024-09-10 08:20:00
推詳盡的介紹說明
作者: keroroman (PorisHuang) 2024-09-10 08:36:00
任天堂PM是鬼
作者: frozensummer (冰凍) 2024-09-10 08:50:00
又要被抄了
作者: z932210 (嘎抓) 2024-09-10 09:08:00
理想很豐滿，現實很骨感，任天堂能兼顧真的是鬼
作者: WindowsSucks (大橋家的DD) 2024-09-10 09:14:00
超鬼，就我的想像把這個系統做出來可能還好，但管理跟維護裡面的資料怎麼想都超難的
作者: HolyBugTw (HolyBug) 2024-09-10 09:21:00
台灣由上而下: BOSS (一頁PPT > 一份PPT > gitlab) RD
作者: WLR (WLR™) 2024-09-10 09:49:00
任天堂教你做遊戲
作者: feedingdream (我不是人，是禽獸！) 2024-09-10 09:55:00
看了真是有點想哭
作者: ikaros35 (墮落的ikaros) 2024-09-10 10:03:00
其實對專案來說很基本 但現實幾乎難以實踐的東西現實都是隕石式開發然後版本資料庫對不起來 ：（
作者: Mikufans 2024-09-10 10:11:00
推
作者: kof78225 (聖劍天俠) 2024-09-10 10:19:00
越大的專案項目管理越重要
作者: ben2227486 (ben2227486) 2024-09-10 10:34:00
基礎概念不難懂 小團隊實踐也不難 但這是鬼扯的破200人大型專案阿 真的只能跪著看
作者: gg0079 (edr) 2024-09-10 10:50:00
這個系統的架構和管理的人真的是神鬼來著
繼續閱讀
[閒聊] 山田總帥 一張black80731[GBC] 怎麼老是在寫情歌啊OldYuanshen[閒聊] 2K真好玩！生涯模式比賽小感 majohnman[鐵道] 雲璃跟彥卿兩人進入教室後就沒出來HarunoYukinoRe: [閒聊] 俄國ACG圈意外也蠻龐大的?IAMCSH[艦娘] 秋天的瑞典初期艦rayven[閒聊] 銀魂最強梗是哪個ndhuctc[閒聊] 為什麼NPC會愛上玩家？故事中的吸引力設計法則dogluckyno1[Vtub] VEE Official 時間表 2024-09-09lingsk[Vtub] Ellise 同接500人耐久歌回 艾莉絲 Aepro あえぷろbely
