[閒聊] 薩爾達傳說 王國之淚 打造可動的規格書 重構開發環境
原文標題:【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/52/2587329de780b1b480b22131ee1rdlk5.JPG
想要了解遊戲,可以遊玩正在開發中的版本,請教其他的開發者,又或者是閱讀規格書等等不同的手段存在。只不過光是遊玩,常常會沒有辦法完全把握規格,而想要找人請教,又必須要該部份的負責人剛好有空才可以,就算是去閱讀規格書,也會碰上加入遊戲時採用的規格其實並不一樣的案例。
想要實現平行式創作手法,由於遊戲在開發過程中會不斷變化的關係,所以讓實現的難度也隨之提昇。在前作《薩爾達傳說 曠野之息》(以下簡稱為《曠野之息》)當中,是採用將遊戲各方面的動作方法和數值等,原本會以規格書說明的部份轉化為資料,以資料驅動式手法進行開發。
將從資料中讀取到的情報,製作出表格、圓餅圖或者是投影片等視覺化資料,並且同時去遊玩遊戲。透過這種兼併兩者方式的「可動規格書」下去了解遊戲,然後再連結到創作行動上。另外岡村祐一郎特別強調「這並不是指不應該要去製作出規格書」,是表示規格書雖然可以用來整理遊戲開發者腦海當中的想法,但是並不適合用來了解關於遊戲的最新情報。
https://p2.bahamut.com.tw/B/2KU/53/6e67984d5e3c5133988e4e6ce51rdll5.JPG
在現在一般的遊戲開發過程當中,通常是由核心團隊利用共通的框架去製作出各種不同開發工具,打造出整合型開發工具讓大家使用,但是在《曠野之息》當中,其實是採用每一個不同的部份,全都使用不一樣的程式語言和技術去製作的綜合組成方式。
雖然這是一種比起整合型開發工具來說,較為古老的開發手法,但同時也有柔軟性更高,更容易去應對各式各樣不同遊戲設計的長處。因為只要有構想,不管是誰都可以下去製作開發工具,所以更容易激發出全新的點子,也比較容易採用全新技術來累積不同的經驗,促進開發團隊成員的技能成長,其實有相當多不同的長處。
比如說在開發《健身環大冒險》時製作出來的記錄用工具,就有轉用到其他遊戲開發工作的成果。
但是另一方面,綜合組成方式與整合型開發工具相比之下,各個開發工具之間的連結力較弱。有時候想要在某個開發工具裡加入一個方便使用的功能,就必須要去解析另一個不同開發工具的情報才行。而且為了要了解遊戲整體的架構,就必須要同時使用複數不同開發工具,並且去理解各個資料之間的連結才可以。
而且《曠野之息》的開發工具,因為將加入速度擺在第一優先的關係,有些工具其實沒有什麼擴充的空間可言。再加上《王國之淚》的遊戲內容與前作相比之下更加複雜,內容量自然也變得更為龐大。
於是包含岡村祐一郎在內的開發團隊成員,就決定要從頭打造一個全新的開發環境。開始製作設置在各個開發者電腦裡的「本地資料庫(LocalDB)」、用來管理資料版本的「公用資料庫(GlobalDB)」,以及讓各資料之間連結視覺化的「專案入口(Project Portal)」等等開發工具程式。
https://p2.bahamut.com.tw/B/2KU/57/a936383f8cc94a388cffc04c9c1rdlp5.JPG
使用資料庫來連結不同的開發工具以及每個人的作業進度
「本地資料庫」是為了解決舊有開發環境的問題之一,也就是各開發工具之間連結力較弱這個問題的工具。基本構想是先準備作為所有開發工具共用基礎來使用的資料庫,讓開發工具透過資料庫去讀取各種檔案。只不過單純只是準備一個資料庫,開發第一線人員也不會去使用。於是就採用了能夠利用在各種不同程式上面的 SQL 工具,讓不管是使用什麼開發工具,都可以直接讀取到資料庫裡面的檔案。
另外關於要在資料庫裡寫入各種情報的時候,基本上是讓有最了解該檔案的人會下去執行這個動作。比如說如果是遊戲的 3D 模型,那就是由 3D 模型工具的開發者下去將資料登錄到資料庫裡面。
雖然這樣的確會增加特定開發者的工作量,但是因為資料庫成為可以共用的基礎部份,所以即使會有複數開發工具都需要使用到 3D 模型,也就不用再分開來一一去應對,因此反而能夠降低整體的負擔。
https://p2.bahamut.com.tw/B/2KU/62/4d440d737afa8876a4615d28b31rdlu5.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
但雖然說是存在本地,可是每一個人的資料庫都還是有互相連結。而且各種開發工具,也會透過資料庫互相連結。比如說有人使用 Maya 編輯某個角色模型並且更改了骨架的名稱,那有用到這個骨架名稱的其他工具,也會更新資料將這個全新的名稱覆寫上去。
而且其他開發者只要有變更檔案內容,並且使用版本管理系統的話,這些變更也會反應到自己的檔案裡面。這樣就不用去判斷到底誰的版本才正確,而是最新的變更會持續反應到所有人持有的檔案當中。
只不過在這個系統裡,為了要提昇反應速度,所以刻意排除了不需要的檔案。所以因為對自己擔任職務沒有必要性,因此沒有存在本地資料庫裡的檔案,就沒有辦法下去更改。
然而就算是這樣說,有時也是會需要用到這些檔案,於是就決定要在「本地資料庫」的系統中,準備一個設置在伺服器上面的共用型資料庫,也就是「公用資料庫」來管理各種不同檔案的版本資料。所以在想要使用自己手頭上沒有的檔案時,就可以連進「公用資料庫」裡面去讀取這些檔案。
https://p2.bahamut.com.tw/B/2KU/71/19920e60ddefff44f7352381381rdm35.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/81/4ea5f59e556a915f60035580281rdmd5.JPG
而就演員和物理設定以及 3D 模型這種沒有直接關聯(離散程度較高)的資料來說,則是提供了可以查詢各自資料的連結,取得必要情報後顯示成一覽表的功能。
比如說寶箱的配置情報,與放在裡面的演員,還有演員的賣價,這些原本應該是寫在不同檔案裡面的情報,就會加工為一覽表,並且加上可以直接跳到情報所在位置的按鈕。
另外就波克布林(ボコブリン)來說,在演員表格裡面會有名稱和內容標籤,而在 3D 模型表格裡會有名稱和邊界框架,在物理設定表格裡則是會記載質量,在這種情況下只要使用 SQL 就可以製造出將名稱、產生出的縮圖與邊界框架、質量一覽表,以及除錯產生用的按鈕都一字排開的一覽表。
本來應該要自己去參考每一個不同的資料,從中去理解資料之間的連結,但是透過「專案入口」就可以加工成一覽表,提供讓人可以馬上就參考所有關聯資料的按鈕。
這樣子就可以量產出 SQL 或者是加工方法,於是就把這個功能稱為「資源表格」。當然像這類試算表也可以直接用人手製作,但是自動化生產一定比較少會出現失誤。
https://p2.bahamut.com.tw/B/2KU/84/f98eda06597cee8f9498974bbb1rdmg5.JPG
利用「本地資料庫」和「專案入口」,製作音效演出細節
接下來登台的長田潤也,則是以音效團隊的角度,舉出實例來解說活用「本地資料庫」和「專案入口」的範例。
由於音效團隊工作性質之故,通常都是在遊戲開發後期才開始動工,但團隊一直都有希望可以在早期就開始主動參與遊戲製作的想法。只要有「本地資料庫」和「專案入口」這兩個開發工具,就可以在播放動畫片段的同時加入音效,又或者是介接到用來編輯動畫資料的開發工具上。
而且還有加入在其他開發者變更動畫資料的時候,就會自動通知關聯音效製作者的設計,讓整體作業效率有明顯提昇。
https://p2.bahamut.com.tw/B/2KU/88/598293de6f43ffb114ebd6f7531rdmk5.JPG
而且在格魯德小鎮(ゲルドの街)防衛戰這個遊戲事件中,還能夠讓音效演出變得更加緊密。由於這在遊戲故事上也是一個十分重要的場面,所以就有人提出希望可以加入依照戰鬥當下狀況,讓音效出現變化的演出這種提案。
於是就在利用「專案入口」仔細把握這個事件的規格之後,成功加入了在適當的時機去切換戰鬥背景音樂,以及每一次破壞吉波得(ギブド)巢穴時樂曲都會發生變化等等,更具有互動性的演出手法。
而在本作中玩家使用的武器,可以透過「餘料建造(スクラビルド)」黏貼上不同素材甚至是其他的武器,每次黏貼後音效都會出現變化,設計可說是十分複雜,而在這方面「專案入口」也是幫上很大的忙。
雖然只調查餘料建造的數值,也很難去了解比如說是用什麼方式黏貼上哪一種道具,也就是整體產生了什麼樣的變化,但只要利用在「專案入口」當中,為了方便遊戲設計師調整數值而加入的預覽,就可以完全理解當下使用的武器規格。
雖然說有的時候,在使用餘料建造黏貼上素材前後,音效也不會出現變化,但只要透過「專案入口」調查,就可以馬上了解到這是刻意為之的設定,還是單純設定時出現失誤。
長田潤也表示,「專案入口」可以說是一個可信度極高的情報收集基礎建設工具,讓團隊能夠放心打造遊戲細節到最後一刻,給這項開發工具相當高的評價。
https://p2.bahamut.com.tw/B/2KU/90/0f75556b05c0b4be9a4ba5c4b21rdmm5.JPG
讓參與開發的所有開發者,不論其職務都可以提出點子,透過從不同視角出發的創意發想讓遊戲變得更加完善……這應該是遊戲開發工作的理想狀態之一。然而當專案規模越變越
龐大,距離這種理想也就越來越遠。可以說在《王國之淚》的開發工作當中,就是透過打造出各種不同的開發工具,盡最大努力去維持這種理想的狀態。
在近年來所謂 3A 大作當道,因為大規模遊戲作品成為主流,讓開發工作越來越高度分工的時代裡,負責遊戲末端工程的開發者,真的是很難去把握遊戲的全貌,實際上也有人指出這種狀況,甚至會影響到開發者投入開發遊戲的動力,本次講座中講解的這些工具,從筆者個人角度來看,也明確感受到是一種能夠去解決這種問題的手法。
雖然這只是筆者個人的感想,但是岡村祐一郎在這場講座當中,會特別強調「創作」這個用字,而不是單純使用「製作」,應該就是想要強調大家不應該只把遊戲開發當作一種工作,只是機械性地去投入製作,而是要在其中加入創意發想去完成一場創作才對。
從不同職務角度出發能看到的事情不同,所以能夠催生出的點子也不一樣。如果能夠透過自己本身職務特有的觀點和創造性,去參與遊戲開發工作的話,想當然是一定可以大幅提昇開發第一線人員的士氣才對吧。
正如同岡村祐一郎本人指出的一樣,就算是採用讓領導人物決定一切的由上至下方式,還是可以順利完成遊戲開發。而且即使費盡苦心開發出一大堆開發工具,也不能保證一定可以完成比由上至下方式還要出色的遊戲。只不過《王國之淚》即使是如此,依然選擇了這條要克服許多難關的道路。
本作之所以能夠在全世界各個國家,讓各個不同年齡層的玩家都給予極高評價,應該就是因為費的這些苦功,的確有開花結果獲得成效的關係才對吧。當然這絕對不是一種能夠馬上就讓所有遊戲開發現場模彷的手法,但是就在必須要在截止期限之前完成遊戲的現實考驗當中,還能夠堅持要去追求理想,的確是件讓人感覺到十分精彩感動的事情。
https://p2.bahamut.com.tw/B/2KU/94/d5d0f446ed13b67a855d3089891rdmq5.JPG
--
講座的內容很多,很充實且豐富,專案入口的設計,讓參與其中的開發者可以更方便進行版本管理,以及針對資料庫中的內容進行篩選與搜尋。
以王國之淚的開發規模來說,能讓這麼大的團隊,在預定日程內進行開發,並且多人進行同步協作。而這樣的開發工具也能讓其他專案,或是未來的遊戲開發中使用,由衷佩服任天堂以及王國之淚的開發團隊們
--
清廉正直射命丸文,世界第一可愛
https://i.imgur.com/XqOptr2.jpg
--
卡
有些概念在資策會的課程也有聽過
就是不知道台灣的遊戲業落實到什麼程度
鬼
厲害欸
幹那PM要超猛...
老任的專案管理真的超猛
先跪
設計出這種做法感覺也是很花錢花時間花精力,真不
愧是充斥著鬼才的任天堂
SVN++?
某些有點像git的概念 但又更貼近遊戲設計 厲害
鬼
猛
竟然能結合不同程式語言的個別開發成果,老任真的有黑科
技。(褒
這種技術老任願意分享真的好猛
*技術概念跟心得
這pm有點猛
鬼神般的專案管理
因為他們其實也知道這些他們認為基本的東西別人也學
不來吧
老任的遊戲理念一直都是“共榮”的,抓一堆專利在手上
卻不私藏也不拿來賺錢,只為了讓大家都能輕鬆用上他們
的專利來開發遊戲,這樣才能一直有心血注入,作為三大
主機廠中唯一一個遊戲專門,才能不斷推出新遊戲
其實還是有啦 十字鍵專利還在的時候是收錢的
當時DC的控制器就有付錢
真的很感動 原來是這樣製作出來的 能實踐這種管理真的
要超猛
並不是不藏私,而是大部分這些概念都不是新東西
理想中的最佳結構,但實際要實行是會被白眼說"做夢比
較快",然後任天堂她媽真的辦到了
*這種規模下要實行
他們的PM到底是甚麼妖魔鬼怪
沒有相關業界經驗,看不懂欸
能夠確切執行真的很厲害
相關經驗能夠傳承並應用在其他遊戲上也很厲害
某些遊戲公司明明有上一代開發經驗了
還是要從頭到尾再踩一次
講解的也太細了,這就是所謂的把餅做大嗎...
天下第一高手不藏私,廣發九陰真經抄本的感覺
老任:就是基本功而已,我們沒什麼特別的,只是普通
的做遊戲,說不定下一個超越任天堂的工作室正呱呱落
地
這是什麼鬼(稱讚語調
任天堂系統厲害
這是管理學教材嗎?
我知道了,任天堂PM最強
老任,真的好強
有當過工程師都知道他們講的這些一般公司根本不可能做到
這是個很鬼神的管理系統... 反正別人抄不起來
推個,跟鬼一樣
收下我的膝蓋
推詳盡的介紹說明
任天堂PM是鬼
又要被抄了
理想很豐滿,現實很骨感,任天堂能兼顧真的是鬼
超鬼,就我的想像把這個系統做出來可能還好,但管
理跟維護裡面的資料怎麼想都超難的
台灣由上而下: BOSS (一頁PPT > 一份PPT > gitlab) RD
任天堂教你做遊戲
看了真是有點想哭
其實對專案來說很基本 但現實幾乎難以實踐的東西
現實都是隕石式開發然後版本資料庫對不起來 :(
推
越大的專案項目管理越重要
基礎概念不難懂 小團隊實踐也不難 但這是鬼扯的破20
0人大型專案阿 真的只能跪著看
這個系統的架構和管理的人真的是神鬼來著
爆
Re: [今島] 《遊戲設計系學生不玩薩爾達》年輕人只就實務上來說,遊戲設計的講師要學生多玩一些經典遊戲也不能算錯。 像FF14開發的時候,吉田就讓FF14開發團隊成員去玩WOW;曠野之息開發的時候,團隊成員 也玩過好幾款開放世界遊戲;大宇要開發2D RPG遊戲,徵人條件之一就是玩過P5、歧路旅人 。 這次王國之淚發售,連索尼、微軟都發文祝賀了,他們自己旗下的遊戲製作人,一定很多也爆
Re: [閒聊] 極客灣 : 被SWITCH拖累的神作DF 剛剛放上新的分析影片。不同版本的 NS 在性能上有一些差異。 主要是記憶體的CL 在新版跟舊版有所不同。 王國之淚採用的方式是double frame Vsync。然後目標是30fps。所以當記憶體的速度 不夠在 33ms 下繪製完下一張 frame 時,就會直接把上一張frame 放出去。這也是為88
[閒聊] 《王國之淚》無縫設計:開發到最後才實現青沼英二談《王國之淚》無縫設計:開發到最後才實現 《薩爾達傳說:王國之淚》在《曠野之息》的基礎上添加了數量眾多的天空空島已經面積龐大的地下世界,並且在此基礎上實現了無縫設計,玩家甚至可以從天空島嶼上一躍而下,徑直突入地下洞窟而來到地下世界,其中並不需要任何的黑屏加載,另眾多的遊戲設計者以及玩家們感到震驚。 近日,《薩爾達傳說》系列製作人青沼英二以及製作總監藤林秀麿在接受 FAMI 通採訪時提到了這個《王國之淚》中的無縫設計,並表示多虧了程式員們的創造力,直到項目結束時才做到無縫加載。 採訪原文如下:58
[閒聊]《FF7 重生》製作人:終於可以玩薩爾達王淚《FF7 重生》製作人最愛《薩爾達傳說:王國之淚》:「我終於有時間回去玩遊戲了!」 最近由 Square Enix 所開發的話題大作《Final Fantasy VII 重生》已經正式釋出 ,讓許多期待的玩家們終於能在 PS5 上玩到這款經典重製版的第二部分。也代表《 Final Fantasy VII 重生》的開發團隊最重要的任務終於已經結束,而對於遊戲製作人北49
[閒聊] 股東擔心Switch性能不足 老任:限制讓我股東擔心Switch性能已經不足 任天堂:性能限制讓我們做出有趣遊戲 日本遊戲大廠任天堂本月底舉行股東大會,不少股東針對 Switch 以及未來可能發售的新 機進行提問。其中有股東提到, Switch 已經是邁入第 7 年的主機,開發人員是否能在 這台主機上實現他們想到的點子。目前身為任天堂執行董事、同時也是軟體開發最高領導 人企劃製作本部長的高橋伸也就說明了他的看法。40
[情報] 任天堂前員工表示自己不會輕易推薦他人現年 45 歲的自由 CG 設計師 Koichi Miura 最近在社交媒體發文引起注目,他分享自己在 任天堂工作的經歷,同時也分享自己在萬代南夢宮、Squre Enix、任天堂工作時的年收入變 化。他公開表示任天堂只適合在遊戲開發方面有天賦的人才入職,普通人只會感受到地獄般 的經歷。 根據外媒報導,前任天堂員工Koichi Miura 在《薩爾達傳說:王國之淚》所負責的工作是25
[閒聊] 開發初期的王國之淚在今年2024年3月於舊金山舉行的遊戲開發者大會上, 王淚的開發團隊們分享了在製作本作品時的心得與碰到的一些問題。 現場影片在前幾天的5/22放上了Youtube23
[閒聊] 看完王國之淚開發影片對老任深感佩服今年三月 任天堂王國之淚的開發人員 在GDC上講解王淚的物理引擎跟音效製作 整個演講主要內容 在於老任開發王淚時遇到哪些困難 團隊選擇如何克服7
[閒聊] 薩爾達傳說 王國之淚 CEDEC講座今年CEDEC講座 老任的王國之淚舉辦了4場 巴哈翻譯的速度比較慢 如果不介意簡中的話 可以看一下B站翻譯的3
[閒聊] 薩爾達傳說 王國之淚 早期開發畫面任天堂在GDC 2024上公佈了一些的《薩爾達傳說 王國之淚》早期開發畫面,果然王淚的 物理引擎不是那麼好做的 --
爆
[閒聊] 任天堂告《幻獸帕魯》開發商爆
Re: [閒聊] 任天堂告《幻獸帕魯》開發商82
[閒聊] 俄語遮羞的觀看數顯示了什麼?81
[情報] 海賊王真人版 羅賓&鱷魚68
[閒聊] 芙莉蓮漫畫戰鬥真的普通嗎?56
Re: [閒聊] 任天堂告《幻獸帕魯》開發商53
[閒聊] 老任告帕魯 疑似的專利權侵犯內容?47
[閒聊] 原神現在484瑟瑟發抖了?44
[閒聊] 帕魯粉現在在想什麼?48
[閒聊] 幻獸帕魯撐得住任天堂的法務攻勢嗎?45
[閒聊] 你會推薦什麼台灣美食給外國朋友?37
Re: [閒聊] 任天堂告《幻獸帕魯》開發商41
[抄襲] 餐哥會怎麼評論幻獸帕魯被告?35
[俄語] 蛋雕去面試484第一個被刷掉爆
[24夏] 俄語艾莉同學 12 真的是一坨大便片29
[閒聊] 為何邊緣行者神作,鐵血孤兒吃屎?19
Re: [閒聊] 任天堂告《幻獸帕魯》開發商28
Re: [閒聊] 任天堂告《幻獸帕魯》開發商31
[乳摸] NS2外觀模型圖,12G的RAM、256G的儲存45
[閒聊] 為啥霸凌渣男通常比較受女性觀眾歡迎31
[閒聊] 韓媒曝幻獸帕魯Mobile如火如荼開發中!30
[閒聊] 奶奶你的耳朵怎麼那麼大29
[閒聊] 蔑天骸看到殤不患的收藏品會怎麼想?27
[俄語] 艾莉同學 #12 這是智障們的選舉破腦戰嗎?28
[holo] 早上貼個PM28
[活俠] 護食小饞貓39
[情報] Win11超越Win10成為最流行的PC遊戲作業25
[閒聊] 復活邪神2 今天開始試玩22
[閒聊] 江湖寶貝現在在想什麼25
[我推] 帽子和茜寶都想H的男人