HianSorasaki763

蔚藍檔案誕生訪談逐字稿AI翻譯

Jul 7th, 2025
731
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 37.25 KB | None | 0 0
  1. 我們一直很想邀請幾位嘉賓來上節目,但一直沒能成功,後來機緣巧合下,終於把這三位都請到了,歡迎你們。
  2. 民瑞準備了很多。
  3. 不是啦,我只是陪襯而已,這樣說讓我壓力好大。
  4. 我可是很期待喔!
  5. 其實我沒準備什麼啦。
  6. 我今天是來揭露用賀本部長的真面目的。
  7. 「真面目」?這麼說好像他有假面一樣。
  8. 大家應該都認識他了,不過還是請看著鏡頭自我介紹一下。
  9. 大家好,我是蔚藍檔案的總監 PD,也是負責很多雜務的 Nexon Games IO本部長,蔚藍檔案/Project RX 總監金容河。很高興見到大家。
  10. 大家好,我曾經擔任過蔚藍檔案的開發導演、短暫擔任過PD,現在是 RX 工作室 PD,IO本部副本部長 車閔瑞。請多指教。
  11. 大家好,我也擔任過蔚藍檔案的導演,目前是蔚藍檔案 PD 安敬燮。請多多指教。
  12. 今天除了聊蔚藍檔案外,也會談到日本市場、亞文化、以及各位擁有的經驗與知識,希望能分享給大家。
  13. 我們準備了很多主題,但還是從最初蔚藍檔案是怎麼誕生的開始吧。
  14. 唉……
  15. 為什麼先嘆氣呢?哈哈
  16. 要講蔚藍檔案,得先從更早說起。我進遊戲業也有一段時間了,大概從1999年末開始,以兵役替代的方式進入業界,當時開發過套裝遊戲《Kingdom Under Fire》,之後參與開發 MMORPG《Shining Lore》,快要推出的時候轉去了《瑪奇》的團隊。
  17. 之後順應線上遊戲的潮流,持續製作 MMORPG 類型的作品,包括《瑪奇英雄傳》。
  18. 到了2010年代,我接觸到一款叫《擴散性百萬亞瑟王》的遊戲,花了很多錢……但也讓我有了想法:「啊,原來也可以這樣做遊戲」、「這種方式好像不錯,我也想做一款試試看」。
  19. 於是我在 Smilegate 製作了一款叫《Qurare:魔法圖書館》的遊戲。在此之前,我一直是在製作比較符合韓國潮流的 MMORPG 或動作類型遊戲,而製作 Qurare 時,我開始想做一款我自己也會玩得開心、有很多美少女角色的遊戲。
  20. 我想做一款像《擴散性百萬亞瑟王》那樣的卡牌型角色收藏遊戲,再強化線上要素,這個企劃也順利通過並投入開發,最後順利上線,且有不錯的反應,也經營了大約四年。
  21. 期間我也做過一款叫《Focus on You》的遊戲,那款作品同樣以美少女為中心,活用了我過去拍攝 Cosplay 照片的經驗。雖然概念上偏 niche,但《Focus on You》也獲得了很好的評價,有一定的市場反應。
  22. 所以我就想,蔚藍檔案也可以做成我喜歡、我自己玩得開心的遊戲。
  23. 剛好那時候,Nexon Games 的代表朴容賢來找我,說:「要不要試著做一款遊戲?」
  24. 他看到了 Qurare 有一定的表現,當時 Nexon Games 還叫 NetGames,就說「來做一款美少女遊戲吧」、「來做一款角色收藏遊戲吧」,這個企劃就延續成為了蔚藍檔案。
  25. 那個時間點,你腦中已經有蔚藍檔案的構想了嗎?像是概念之類的?
  26. 我們一開始做開發時,會先從市場調查開始。當時我自己也很投入在玩《少女前線》、《碧藍航線》等遊戲,看著那些作品,思考兩三年後會受歡迎的遊戲應該要有什麼樣的構成。
  27. 我們和早期參與的企劃人員、美術團隊討論後,決定了概念。當然這個過程中也有加入一些個人喜好,例如「我喜歡校園題材」,希望能以這個為中心來構築遊戲。
  28. 也一起討論了:「戰鬥要怎麼呈現比較好?」、「角色要怎麼設計才能在市場上吸引人?」結果自然發展成了現在的模樣。
  29. 最初設定的方向是「校園題材,有學生登場」,戰鬥則盡量避免近戰動作,而以遠距離戰鬥為主,這樣就能讓多名角色同時出現在畫面上,構成上也比較清楚。
  30. 這樣一來角色可以豐富登場,也適合做成角色收藏型的設計,所以我們就想:「那就做一款學生用遠距離攻擊、以校園為舞台的遊戲吧。」
  31. 如果是近戰,就會出現角色背影為主的畫面,顯得雜亂。
  32. 這背後其實也有開發成本的考量。
  33. 成本?
  34. 因為要做近戰戰鬥,就得製作很多動作序列,動畫也要大量製作,包括受擊動畫也要製作。
  35. 遠距離戰鬥就比較簡單一點,而打擊與反應之間的配合,在系統與資源層面來看,會需要更多開發預算。
  36. 當時選擇這個方向時,你們三位都有參與嗎?
  37. 我當時不在。
  38. 我也不在。
  39. 我其實是以團隊成員的身份加入這個專案的。
  40. 金本部長在新入職員加入時,會用簡報方式向大家詳細說明這款遊戲是什麼、重視什麼方向等等,這點很有趣。
  41. 在團隊層級上,也藉由這個說明達成了共識,才得以順利進行下去。
  42. 這份 PPT 有個名字,叫做《為何是 MX》,也就是蔚藍檔案的開發代號。
  43. 當時會定期集合新進人員,由本部長親自簡報《為何是 MX》。
  44. 那時他還是 PD 的身份,會向新人說明「我們打算做什麼樣的遊戲」,讓開發方向確立後再持續開發。
  45. 而且這份 PPT 內容在開發過程中也會隨著進展逐漸更新,因為起初的構想與實際開發過程會出現差距,他會隨時掌握這些變化並修正內容。
  46. 這也讓我們覺得,他是一位非常認真的 PD。
  47. (被誇獎中)
  48. 為什麼突然這麼誇他啦哈哈。
  49. 等到一切都大致整理好時,我才加入這個專案。原本我是在 NetGames 從《HIT》時期就開始工作的。
  50. 聽說金 PD 要來的時候,老實說對我來說……有點像是偶像人物。他是我年輕時在遊戲雜誌上常看到的人,或是出現在 2010 年 Nexon 開發者大會上。
  51. 他主持的節目我也常看,當時覺得「哇,有這樣的人啊」,像個神奇的人物。結果沒想到後來竟然要一起工作了。
  52. 他也曾在 OnGameNet 上節目過,雖然那影片現在應該找不到了,真是太好了(笑)
  53. 我們第一次見面,是透過推薦一起去吃飯。通常見面聊合作,會討論「想做什麼樣的遊戲」這類話題,但那次完全沒有聊這些,而是整場都在聊動畫、偶像。
  54. 但因為我也喜歡這些話題,就聊得很起勁,最後金 PD 說:「我們一起工作吧。」
  55. 我回家之後才想:「我該怎麼解讀這句話呢?」
  56. 因為通常要找主導企劃或資深職位的人,是個很重大的決定,一定要謹慎挑選人才。但他什麼都沒看,就說要一起工作?
  57. 其實是我很信任的一位後輩,也是非常有實力的企劃者,向我推薦的。
  58. 他說這人很強,有能力擔任 PD 或導演,所以我在企劃能力上是完全不懷疑的。
  59. 只是……我們要做的是美少女遊戲,他是否能將對角色的愛透過遊戲呈現出來?我有點疑問。
  60. 所以我就跟他聊了很多動畫、偶像的話題。
  61. 聊到最後我發現,這傢伙也是個御宅族……
  62. 那就沒問題了。雖然他沒做過美少女遊戲,但我相信他一定做得出來。
  63. 基礎都具備了。
  64. 要製作動作戰鬥,必須一路開發到幾乎完成階段,才能確定最終效果。但要召集能夠做到這點的團隊成員,在有限的時間內透過反覆試錯來實現,是很困難的。
  65. 即使是要打造自己喜歡的世界,也必須在預算範圍內完成。因此我們選擇了遠距離戰鬥。在遠距離戰鬥中,動畫可以設計得較簡潔,同時能做出掩蔽、建築物倒塌等演出效果,這樣一來就能展現出有說服力的戰鬥畫面。這個方向逐漸擴展成現在的戰鬥系統。
  66. 至於角色方面,我們不想走擬人化、物品萌擬化的路線。像是艦Colle是把戰艦萌擬化的遊戲、《少女前線》則是把槍械擬人化的作品。這種從既有物件中擬人化的做法,我們認為在2到3年後會不再流行。
  67. 因此我們選擇走原創設定的方向。設計上,我們讓世界觀中有多所學園,每間學園的制服風格稍有不同,避免完全一致導致設計過於單調。這樣每個學園都有自定化的制服設計,學園內再細分為各種社團、角色,然後用這些角色推動故事,逐步拼出整體世界觀。
  68. 你剛剛說的這一切真的非常精彩。說到為什麼是校園題材,若故事中的角色與敘事能讓人感覺像是真實存在,那麼玩家就會更容易喜愛、也會更有親近感。
  69. 雖然這的確是出於個人喜好選擇了學園背景,但這樣才能與當時其他作品形成差異化,也更有可能受到玩家喜愛。這點我也深受感動。
  70. 畢竟學園題材雖然已經非常普及,但在東亞文化圈,我們每個人都經歷過學生時代,也都熟悉「制服」這個主題。因此這個題材對所有人來說都是親切且易於理解的。
  71. 所以我當時就覺得,遊戲要打入市場的初期會相對容易。
  72. 我們國家在當時(甚至到現在)主要的遊戲題材還是中世奇幻。這類題材雖然大眾,但我個人可能不是那麼喜歡。
  73. 從小到大玩太多中世奇幻的遊戲了。我不想再做中世奇幻。
  74. 「中世美少女」這個概念……有點難以說服人。
  75. 中世美少女(笑)——通常也不會這樣描述角色。
  76. 這種設定總會讓人有距離感。為了打破這樣的框架,我也反覆思考很多邏輯。
  77. 從開發或成本的角度來說,中世奇幻其實在招募人員上反而比較容易,因為大家熟悉、有資源、素材也豐富。
  78. 但我也想過,也許你是想創造一個全新 IP。畢竟中世奇幻基本上是一種「既有 IP」的印象,像是托爾金的作品或北歐神話等,都是已完成的世界觀。
  79. 那可能就缺乏吸引力。中世雖然有某種浪漫感,但對我們來說還是感覺有些遙遠。
  80. 我去歐洲旅行時發現,那裡的環境本身就像奇幻世界。住在那種環境裡的人所創造的世界觀,對他們來說很親切也合理。
  81. 但我們是在都市長大的韓國人,大家在學校裡相處、衝突、生活——這樣的背景反而能帶來更有趣的故事。為什麼一定要選中世呢?
  82. 我們花了很多心力去思考:「如何讓玩家與角色的距離更貼近?」
  83. 因此我們選擇了和現代相差不大的背景設定,學生角色也設計成看起來就像現實中可能會出現的人物。演出方面也儘可能營造出親近感、對齊玩家視角,讓角色更貼近現實。
  84. 但這些學生角色,手持槍械、發射炸彈、甚至吃下迫擊砲還能安然無恙,這樣的設定……現在想想還是有點沒頭沒尾吧?
  85. 那算是……「祕密醬料」吧(笑)不需要解釋太多,只要看起來好吃、玩起來開心就行了。
  86. 關於這點還有個例子:遊戲裡不是有坦克從天而降嗎?那時候討論到底是讓它從後方出現,還是從天上掉下來,最後決定要從天上掉下來。
  87. 為什麼?這樣比較開心嘛!
  88. 與其從後方出現,不如從天上掉下來比較有氣勢。可是有人就問:「那洞穴裡的坦克要怎麼從天上掉下來?」
  89. 這時候有人就說:「這就是蔚藍檔案啊!」這句話一說出口,氣氛瞬間豁然開朗,大家都覺得這樣也不錯啊(笑)
  90. 是啊,雖然學生們中了槍依然健在,但他們終究會「倒下」。那要怎麼安排他們退場呢?
  91. 如果只是透明化消失,總覺得哪裡不對勁。
  92. 於是我們就提出:「那就讓他們被直升機救走吧。」
  93. 其實是我們不想呈現「倒下的樣子」,也不想用「死亡」這個字眼。所以相關的資源命名不是 death,而是 dying(垂死)或 retreat(撤退)這種詞。
  94. 甚至連變數命名都禁止用 death?因為這遊戲裡沒有「死亡」的概念?
  95. 是的,因為我們被觀念主導。只要是 death 就不行,因為這不是死亡。
  96. 我們最不希望看到的是學生倒地時發出「啊……」的痛苦模樣。這真的讓人無法接受。
  97. 其實這樣的想法很有道理。畢竟這些是我們非常喜愛的角色,不想看到她們痛苦的樣子。
  98. 但這麼說,團隊一開始就接受這個設計嗎?
  99. 不是的,這件事情我們吵了很久,吵了兩個月吧,光是這一點。
  100. 吵兩個月?!
  101. 是啊,因為多數遊戲都會有死亡演出,像是《原神》或《魔物獵人:荒野》等作品都有既定表現手法。
  102. 所以如果我們也採用類似方式,大家會覺得理所當然。但偏偏我們就要每個細節都說:「不對,要這樣做才對。」
  103. 那就得說服所有人為什麼要這樣做。問題是這種說服過程很難,不是用邏輯,而是靠「偏好」來主張。
  104. 這讓大家非常為難。
  105. 你剛剛一說「直升機」那段,我們兩個馬上就想起來當時那場爭論(笑)
  106. 所以你一開始並不同意使用直升機?
  107. 當然不同意啊!原本都說好用透明化退場,突然有人說「等一下!」
  108. 然後開始提出新方案。
  109. 而且透明化處理起來不是比較方便嗎?
  110. 是啊,簡單又沒爭議,根本不是會花時間討論的主題。我從沒想過會有人要改這個。
  111. 畢竟這做法會大幅增加開發成本,動畫、狀態、例外情況、角色個別處理……全部都要額外製作。
  112. 而你之前不是因為成本問題才放棄近戰嗎?這樣一比較……
  113. 這就對了!你點出了關鍵。
  114. 因為我們希望這款遊戲看起來和其他作品不一樣,要有專屬的特色。
  115. 如果只是近戰砍殺閃光特效,市場上已經有《第七史詩》等遊戲做過了,不容易在那方面做出差異。
  116. 雖然我們導入了掩體系統(Cover),
  117. 讓角色在移動時有不同的跳躍、掩蔽動畫,
  118. 在掩體後戰鬥的樣子也能展現角色個性。
  119. 從戰鬥系統的角度來說,我其實很討厭這些,
  120. 但也不是真的覺得「不能做」。
  121. 因為這就像是一種「視覺化原型設計」,
  122. 為了呈現我們的願景——「我們要做這種戰鬥」,
  123. 而且我們知道,做這些事情的角色是可愛的。
  124. 所以雖然很煩人,但還是得做,
  125. 正因為大家都知道「非做不可」,才更令人煩躁。
  126. 大家雖然都明白,但會開始妥協,例如說:
  127. 「牆壁是不是就不要做也行啊?」
  128. 但每個人看法不同,
  129. 因為那些場景真的很可愛。
  130. 其實到現在我也會想,
  131. 「如果牆壁真的能破壞就好了……」
  132. 因為角色躲在牆後又探出頭開槍的畫面實在太可愛了。
  133. 只是最後受限於各種現實問題,沒辦法做到。
  134. 例如右側能破壞,那左側也得能破壞……那就做不下去了。
  135. 我們有沒有哪些東西最後沒做出來呢?
  136. 當然有。舉例來說:
  137. 原本有人想做「與在二樓的敵人戰鬥」的場景。
  138. 我們曾討論:「要不要做樓層差?」
  139. 或是「向牆壁發射飛彈,讓牆塌掉」,
  140. 然後敵人從樓上掉下來這種演出。
  141. 這些在最初版本中都有。
  142. 像是建築倒塌、戰鬥痕跡導致招牌掉落、
  143. 或是牆壁被炸出缺口、敵人突然出現等等。
  144. 但最終因為成本問題,大多都被刪除了。
  145. 只剩下少數還保留在教學關卡(Tutorial)中。
  146. 不是完全沒做,而是做了後又逐步刪減,
  147. 已有資源就保留,新內容就不再新增,這樣的折衷方式。
  148. 但其實這個過程是很痛苦的。
  149. 因為我們不是在複製某個既有的遊戲類型,
  150. 而是打造一個前所未有的戰鬥系統,
  151. 沒有參考案例。
  152. 不像其他遊戲開發可以查前例、找比較依據,
  153. 我們只能靠金容河 PD 說「我覺得這樣比較好」。
  154. 卻無法用邏輯反駁,因為這種遊戲從來沒出現過。
  155. 我們參考過一些老遊戲,像《少女前線》、《Brave Brigade》,
  156. 但那種戰鬥模式都不會「戰況推進」。
  157. 但《蔚藍檔案》會持續推進戰況,這對
  158. 地圖設計師、戰鬥系統設計師來說壓力非常大。
  159. 因為每場戰鬥中敵人會隨機死亡、進程難以預測,
  160. 這些隨機性讓開發變得極度困難。
  161. 沒有參考例子也就算了,
  162. 但「不能反駁」就意味著——
  163. 「只要覺得可愛,就能強推?」
  164. 不只是可愛。
  165. 是因為這些畫面能強化角色與世界觀的關聯性。
  166. 這些「拼圖碎片」雖然數量龐大,
  167. 但都是不能缺少的。
  168. 而既然是「不能缺少」,那就不需要提出參考案例。
  169. 最後就是一個個「硬塞進去」:
  170. 加了(1)、加了(2)、加了(3)……
  171. 然後就有人說:「欸?好像還不錯耶?」(笑)
  172. 於是大家乾脆說:「好啦快做啦。」
  173. 「會議好煩,不如就滿足金 PD 的願望吧。」
  174. 這已經變成一種「教化過程」。
  175. 我們都被教化了(笑)
  176. 剛開始他來的時候更常發火,
  177. 因為我們常提出他覺得「無法接受」的方案。
  178. 但如果最後做出來了,那就是對的。
  179. 問題是——成功之前,有太多失敗的版本。
  180. 那些我們製作後覺得「不行」的內容,
  181. 實際上也是在測試他的構想。
  182. 我們團隊當時有句術語叫「去打團本」,
  183. 意思是我們要找金 PD 說服他放棄某些東西。
  184. 大家會說:「請看,這裡這裡有問題,
  185. 我們是否改用另一種方式比較好?」
  186. 他就會說:「我不喜歡,因為〇〇!」
  187. 一般來說不是會說「那就這樣吧」嗎?
  188. 但我們得猜他會不會說這樣,或那樣……
  189. 有時我們開玩笑說他是「祭司大人」:
  190. 「我預見金 PD 將會這樣說」——
  191. 然後大家集體回應:「啊……應該是吧……」
  192. 我們得準備好各種應對變數才能成功說服他。
  193. 但意想不到的事總會發生。
  194. 說到這裡可能會讓他看起來有點像反派……(笑)
  195. 不過說真的,當時很多其他專案的人
  196. 也有提到:「金 PD 正是因為這麼追求細節、
  197. 才會做出這麼棒的作品。你們應該協助他完成。」
  198. 這樣聽完後……我心情很複雜……
  199. 他過去硬要保留的那些東西,
  200. 現在看起來其實也挺不錯。
  201. 最後,我們都會有一種「好像還不錯」的學習效果。
  202. 像是那個「老師的名字會被角色唸出來」的功能,
  203. 當時也是所有人都反對的。
  204. 大家都說:「與其花錢做這個,不如去做其他內容。」
  205. 所以我們就說:「你如果真的想做,請你親自寫企劃書。」
  206. 結果真的寫了。還做了兩年。
  207. 這可以說是傳說等級的功能。
  208. 企劃書最困難的部分是:
  209. ——玩家輸入名字的時機在哪?
  210. ——如果伺服器已有該名字,可以即時呼叫;
  211.  如果沒有,要怎麼辦?
  212. ——途中若想更改要如何處理?
  213. 這些流程包括網路通訊順序、例外情況、錯誤處理都要列清楚。
  214. 這還會影響進入遊戲的初始體驗,
  215. 若一開始就出錯,會讓玩家直接退出。
  216. 要是這功能一出錯,玩家會覺得:
  217. 「什麼爛遊戲啊?」
  218. 更難的是,這功能還會有法律風險:
  219. ——如果玩家輸入奇怪的名字怎麼辦?
  220. ——出現問題誰要負責?
  221. 但金 PD只說一句:「我就是想讓角色唸出玩家名字。」
  222. 為什麼呢?
  223. 他說:「以前《心跳回憶》就有這種功能。」
  224. 「《Love Plus》也有。」
  225. 這能讓角色與玩家之間的距離感瞬間拉近。
  226. 只要嘗過這個甜頭,玩家就會懂這功能的好。
  227. 我們知道「這功能如果做得好會很棒」,
  228. 但通常會放在進入遊戲後才執行。
  229. 但金 PD 堅持:「不行,要一開始就唸。」
  230. 這讓我們很緊張。因為那是登入階段,
  231. 任何錯誤都會毀掉體驗。
  232. 我們預先製作了幾萬組常用名字的語音資料,
  233. 這樣玩家在輸入時能即時播放。
  234. 等到所有人都明白「這真的要做」時,
  235. 只能開始認真執行。
  236. 發行前5~6個月,我們終於正視這件事。
  237. 從「做了會更好」變成「這是必做項目」。
  238. 我還記得,那次金 PD 跟發行方會面時,
  239. 在所有議題中最認真說的就是:
  240. 「要讓角色唸出老師的名字」與「周邊商品」。
  241. 我們在旁邊聽都驚了,心想:
  242. 「等一下……這真的要做喔?」
  243. 於是我們的優先順序變成:
  244. **1. 唸出老師名字 & 周邊商品**
  245. **2. 發行相關的所有其他重要事項(數百項)**
  246. 日本上線初期確實發生過伺服器問題,
  247. 這功能有一次引發過異常,
  248. 但當時我們設有「緊急關閉按鈕」,
  249. 能即時停用該功能,避開了危機。
  250. 這樣的開發過程真的不簡單……
  251. 我那時說:「這樣會不會太複雜了?」
  252. 你看到右下角那個會累積的行動點數(Cost)吧?
  253. 但這樣就看不到學生了,我不喜歡。
  254. 是啊,視線如果被吸引到右下角,
  255. 那就會比較難看清楚學生們的樣子。
  256. 感覺這個設計變得太「功能導向」了?
  257. 雖然這麼說不是錯的,
  258. 但就是會讓人有點煩躁。
  259. 我們後來還是採用了現在這個行動點數系統(Cost),
  260. 雖然過程中花了很多心力,
  261. 做了好幾個版本,也實際玩過。
  262. 最後我也覺得——「好吧,還是用 Cost 吧,沒辦法」。
  263. 我們有試過更優雅的方案嗎?也許有些類似的……
  264. 但老實說,我已經刻意把那段記憶從腦中刪掉了。
  265. 因為……你看現在 Blue Archive 的遊戲平衡,
  266. 初期難度是刻意壓低的,
  267. 讓玩家能輕鬆推進、使用自動戰鬥(Auto),
  268. 直到某個轉折點,難度會突然提高,
  269. 例如角色可能會退場。
  270. 但我們希望在那之前讓玩家能長時間用 Auto,
  271. 等到玩家真的和學生們建立感情後,
  272. 再進入必須手動操作技能的階段。
  273. 所以,這個設計其實是種妥協。
  274. 而且其實當你點選學生來施放技能時,
  275. 這個操作本身也代表你在「看著」學生,
  276. 因為你必須拖動卡片,
  277. 這個過程中學生會出現在視野中。
  278. 雖然有人說這不是「看學生」而是「看技能位置」,
  279. 但反過來想,也算是注視角色的動作吧?
  280. 聽起來也沒錯。
  281. 結果就是——你會開始用這種邏輯說服自己(笑)
  282. 其實 Blue Archive 的 UI 設計也讓玩家會一直與學生互動。
  283. 這就是一種「感情交流」。
  284. 遊戲開場時就設定玩家收到平板電腦(Tablet),
  285. 整個遊戲都是以平板來與學生們互動的,
  286. 戰鬥中也是看著平板下達指令。
  287. 所以這樣設計其實很自然,沒什麼違和感。
  288. 實際玩起來後我們也發現這樣更有趣,
  289. 所以最後就採用了現在的形式。
  290. 在這過程中我們發現,
  291. 這個名為「Blue Archive」的遊戲,
  292. 一開始是無形的、抽象的,
  293. 但越做越能具現化,開始有實體、有樂趣,
  294. 從那時開始我們也能用「玩家視角」來討論、解決很多問題。
  295. 不過當時最難推進的不是戰鬥系統,
  296. 而是「行程系統(Schedule)」。
  297. 我們想展示各個學園的樣貌、
  298. 誰在哪裡上什麼課、有什麼事件發生等等,
  299. 這看似簡單的系統,背後需要很多設計。
  300. 我們必須先思考:「身為老師,該有怎樣的行為?」
  301. 「什麼行動是合理的?」
  302. 「在這個世界觀中,角色為什麼會出現在那個地方?」
  303. 比方說:如果學生根據時間出現在不同地點,
  304. 那麼玩家是否能在正確的時間遇見她們?
  305. 是否會觸發對話或事件?
  306. 這些都要有實感。
  307. 但問題是……如果這些都要搭配 Cost 運作,
  308. 事情會變得太複雜、太大。
  309. 現在的行程系統中,
  310. 你可以看到地圖中會有動態物件,
  311. 不只是雲在流動,
  312. 其實那些物件代表的是當時我們想實現的概念殘影。
  313. 例如:在某地區曾構思過會發生某些事件、
  314. 有哪些角色會參與、
  315. 她們會有什麼互動、
  316. 這些即便無法完全實現,
  317. 但我們希望保留那份「想像」。
  318. 即使只能用簡單的 2D 圖片來呈現,
  319. 也想讓這些元素有所連結。
  320. 像「咖啡廳」也是一樣的。
  321. 有哪些學生會在那裡活動?
  322. 要怎麼送禮?怎麼互動?
  323. 這些我們都討論了非常多。
  324. 最困難的是金用河 PD 會問:
  325. 「為什麼要有咖啡廳?」
  326. 「那些學生真的來了咖啡廳嗎?」
  327. 他說:抽卡後你獲得了學生,
  328. 代表她成為你作為老師要教導的對象。
  329. 那她們為什麼會在咖啡廳?
  330. 你怎麼說服我這樣的設定合理?
  331. 他不是單純從實作層面在問,
  332. 而是從「老師這個角色會怎麼看待這一切」的角度來思考。
  333. 所以我們在開發的每一個系統中,
  334. 都被要求思考「這有什麼合理性?」
  335. 「這對玩家來說在故事上成立嗎?」
  336. 這些不只是技術問題,
  337. 而是遊戲體驗與世界觀融合的問題。
  338. 因此就算只是做一個咖啡廳,
  339. 我們也會開始懷疑:「我們為什麼要做這個?」
  340. 若沒有這些思考,
  341. 後來也不會出現這麼豐富的二創。
  342. 這一切都來自於他對「脈絡」的高度關注,
  343. 在開發過程中不斷強調要「說得通」。
  344. 這真的像在打 Raid(高難副本)一樣。
  345. 他其實是想「讓玩家有體驗感」,
  346. 而不是單純做一個功能。
  347. 例如「好友」或「社團(Circle)」這些系統,
  348. 他會問:
  349. 「好友是什麼意思?是來自另一個世界線嗎?」
  350. 你會想反駁:「其他遊戲也都這樣啊……」
  351. 但在他眼中,這是非常嚴肅的議題,
  352. 不能用「別人都這樣」來搪塞。
  353. 即使只是技術上簡單的功能,
  354. 像好友邀請、角色支援,
  355. 他都要求我們思考:
  356. 「它的語意是什麼?」
  357. 「呈現在 UI 上會帶出什麼感覺?」
  358. 「玩家會如何體會這個系統?」
  359. 當然,我們最後還是得在技術與資源間妥協,
  360. 像是總力戰中會顯示其他老師的名字——
  361. 雖然從世界觀上不太合理,
  362. 但為了能實作排名系統,我們必須接受。
  363. 金 PD 其實做了很多妥協。
  364. 像是「社團」系統,最初我們稱為「公會(Clan)」,
  365. 但後來變成「Circle」,
  366. 就是因為「公會」不符合這個世界觀中「師生關係」的語意。
  367. 他從頭到尾最重視的是「合理的脈絡與理由」,
  368. 技術部分反而不是問題。
  369. 不過不管怎樣,
  370. 我就是不希望這讓人感覺是在「玩遊戲」。
  371. 希望能讓玩家有一種真的「存在於這個世界」的體驗。
  372. 所以我不斷和 UI 設計師、概念設計師討論:
  373. 「這要怎麼做才讓金容河 PD 能接受呢?」
  374. 「怎麼樣才能活用這個概念呢?」
  375. 這時候 UI 設計師(現在還在團隊內)突然準備了一份簡報,
  376. 詳細介紹我們遊戲 UI 設定的方向。
  377. 她在內部簡報時提到——
  378. 某些場景應該以某種方式來呈現,
  379. 而另外一些則不該這麼處理,
  380. 這些不同視角的設定該如何對應演出方式。
  381. 當金用河 PD 看完簡報後馬上說:
  382. 「這就是我想要的。」
  383. 例如戰鬥畫面就是老師透過平板觀察學生,發出指揮。
  384. 而戰鬥結束後角色擺出姿勢,就是在對老師說:
  385. 「老師,我們做得不錯吧?」
  386. 正是這種感覺——
  387. 角色知道老師正在透過平板看著她們、指揮她們,
  388. 所以也希望獲得稱讚。
  389. 有了這樣的想法再去製作動畫,
  390. 實際呈現出來的效果也會跟著改變。
  391. 意外的是,這類作業對某些開發者來說意義非常重大。
  392. 如果不能理解「我為什麼要做這個?這角色為什麼會做這個行為?」
  393. 就會缺乏動力與情感連結,自然也就沒辦法投入製作。
  394. 但若能建立起這層關聯,反而會讓成果更好。
  395. 經歷過這樣的討論多次後,
  396. 大家也變得習慣了,會先聽聽金 PD 的想法。
  397. 雖然一開始會有「這也太扯了吧……」的反應,
  398. 但還是會提醒自己:「不對,我們說好要先聽完。」
  399. 也常會這樣對話:
  400. 「我們至少還是要聽金 PD 的話吧。」
  401. 「畢竟他也是有想法才會提這些……」
  402. 「雖然聽起來不太可行……」
  403. —你覺得自己在這麼長的開發過程中有改變嗎?
  404. 其實我選擇用正面態度去看待這一切。
  405. 因為 Blue Archive 成功了。
  406. 當我看到老師們(玩家)的回饋與聲音,
  407. 很多其實都是金 PD 當初提出來的那些觀點。
  408. 每次看到這些我就會想:
  409. 「我當時是不是應該更努力去實現他的想法?」
  410. 「如果更早開始,是不是可以做得更好?更多?」
  411. 事實上我們現在正在做第二款遊戲。
  412. 現在的我,幾乎不再反對金 PD 說的任何事了。
  413. 因為他現在說的那些,我們早就都知道了。
  414. 我們甚至會主動模擬他的邏輯,預測他的反應:
  415. 「如果這樣做,他會說那樣,那我們就要轉個彎。」
  416. 現在大家已經能自動同步金 PD 的思維邏輯。
  417. 這整個過程,也讓我理解了「美少女遊戲」究竟是什麼。
  418. 一開始我認為這類遊戲只是某個時期的現象或流行,
  419. 畢竟市面上有這麼多遊戲。
  420. 但聽完金 PD 的每一個想法後,
  421. 我發現他其實是在逐個案例解釋
  422. 「這類遊戲為什麼會這麼有味道、這麼有魅力」。
  423. 如果沒有他的這些堅持,
  424. 我們可能根本做不出 Blue Archive 這樣的作品。
  425. —Blue Archive 的劇情也很有魅力。
  426. 一開始輕鬆搞笑,但後面卻越來越深沉,
  427. 這部分當初是怎麼構想的?
  428. 我們以前做過《Qurare:魔法圖書館》,
  429. 那時就想做一款比較輕鬆好讀的劇情。
  430. 起初我們用「搶銀行」之類的劇情來展示世界觀的特殊性。
  431. 但僅靠這些輕鬆搞笑的劇情是不足以支撐整個遊戲的,
  432. 所以我們當時也參考了《Fate/Grand Order》和《公主連結 Re\:Dive》。
  433. 這些遊戲都是從輕鬆進入,慢慢建立史詩級的主線劇情,
  434. 讓玩家可以跟隨同一個世界觀的長篇冒險直到故事終章。
  435. 我們內部也對這種長線鋪陳的做法達成共識,
  436. 雖然也曾擔心「手機遊戲能不能支持這麼長的劇情?」
  437. 但隨著我們每次推出的劇情章節都獲得好評,
  438. 我們也更確信要完整地推出「最終章」來收束整體故事。
  439. —但這也很冒險吧?
  440. 畢竟手遊壽命通常不長,
  441. 如果中途營運結束,故事該怎麼辦?
  442. 我不是那種會想太多的人(笑)
  443. 像 Qurare 當時也營運了四年,
  444. 我一開始就相信 Blue Archive 能長久走下去。
  445. 我們團隊裡沒人懷疑這一點。
  446. 我們其實從很早就覺得:「這遊戲會成功。」
  447. 問題反而是「怎麼維持、怎麼持續更新」。
  448. 我們的重點在於:
  449. — 每月更新內容怎麼規劃?
  450. — 怎麼在開發與營運負擔間取得平衡?
  451. 但當這樣發展下去,文字量、演出、成本都會大幅提升。
  452. 像最終章的演出,我們一開始其實沒打算做到那麼精緻,
  453. 但後來發現:「只要用心做,評價就會好。」
  454. 於是資源就越加越多,變成停不下來的雪球效應。
  455. 其中一個代表性成果就是 PV(宣傳影片)。
  456. 第一部 PV 是我們開發團隊偷偷做出來的(笑)
  457. 為什麼要偷偷做呢?
  458. 因為當時 PV 通常是行銷部門或發行商負責,
  459. 交給外包製作,再由開發團隊提供素材、審稿、給意見。
  460. 所以會有一種「開發團隊不該做這種東西吧?」的氣氛。
  461. 而且 Blue Archive 當時是個節奏緊湊的小團隊專案,
  462. 不應該把有限資源浪費在宣傳素材上,
  463. 所以我們在報告時只說:「這只是幾張關鍵圖啦,沒花什麼時間。」
  464. 但實際上有好幾位成員全職花了三個月來製作第一部 PV。
  465. 我們認為:
  466. 「如果我們想讓這個世界觀被視覺化、被理解,
  467. 那我們就必須自己做出能說服內部的素材,
  468. 讓大家產生共鳴,才能做出有一致感的遊戲。」
  469. 而結果也證明是正確的。
  470. 第一支 PV 完成後在內部公開時,大家都非常感動。
  471. 大家一邊看一邊想:「這遊戲一定會成功!」
  472. 畫面美、演出強、玩法新穎又有趣,
  473. 一切都讓人覺得:「只要我們好好做下去就會成功。」
  474. 那次讓所有實務工作者都更清楚知道:
  475. 「我們現在該做的是什麼。」
  476. 原本還懷疑這東西是不是搞錯方向,
  477. 但 PV 公開那刻,大家都明白了——
  478. 「原來你們是為了這個而做的啊!」
  479. 這讓我們的開發投入越來越深:
  480. — 第二部 PV 比第一部更長
  481. — 第三部 PV 的畫面數是第二部的兩倍
  482. 這樣的投入不只出現在 PV,
  483. 甚至連 EX 技能演出也是:
  484. 最初只是角色冒火然後射擊,
  485. 現在是背景變換、角色穿梭、特效滿天飛,
  486. 甚至還會有衝浪滑行等演出。
  487. 因為只要成功過一次,就會不斷追求更高品質。
  488. 我們決定要用長篇主線來引導這款遊戲,
  489. 那麼每個重要章節就要投入不合理的高規格資源,
  490. 這樣的做法也延伸到了 PV。
  491. 第六部 PV 幾乎就是動畫級的內容。
  492. 從最初的幾張素材,到現在每支 PV 製作週期長達一年。
  493. 我們與動畫公司反覆開會,提供設定與分鏡,
  494. 提前準備好未來一到兩年的劇情素材,
  495. 並且同步啟動第七部 PV 的製作,
  496. 因為光是製作就得提前一年開始。
  497. Blue Archive 從某個時刻開始,
  498. 就已經不再是只做半年的遊戲,
  499. 而是朝著未來一至兩年在規劃內容。
  500. 金 PD 那時就說:「Blue Archive 很安全。」
  501. 因為他早已規劃好了兩年後的發展……
  502. 「安全的。」
  503. 因為真的很安全。
  504. 如果不安全就糟了。
  505. 不安全的話會出大問題。
  506. 我們早就準備好了,
  507. 像「兩年後我們要做這個哦」這樣的話,
  508. 我們是真的這樣一步步慢慢推進的。
  509. 但要做到這樣,就必須很早就把劇情整體構想好,
  510. 不然根本不可能辦到吧?
  511. 像是大綱、主要登場人物、
  512. 還有哪些演出會以什麼形式出現,
  513. 我們都會事先記錄下來。
  514. 與此同時,我們會再精緻化這些劇本大綱,
  515. 從中製作會出現在遊戲裡的素材。
  516. 例如 PV 第 1 部、第 2 部、第 3 部的發布時機,
  517. 或是在直播中有老師說:「有大事件要來了嗎?」
  518. 事實上,這些老師們真的會這麼想。
  519. 於是就像 WWE 摔角一樣:
  520. 「來了嗎?要來了嗎?」
  521. 然後真的出現時會歡呼:「來了!」的感覺。
  522. 但對玩家來說只要期待就好,
  523. 「要來了嗎?」「來了!」——可以單純享受。
  524. 但對我們來說,
  525. 當要真的「給出大東西」時,壓力其實非常大。
  526. 不過工作室內部的成員,
  527. 比起感到壓力,更積極地思考:
  528. 「我們要怎麼做,才能讓這東西變得更好?」
  529. 大家都主動提出各種想法,
  530. 整體氛圍是「衝到底」。
  531. 正如我們在一開始面試時就說的,
  532. 我們會找那些有自我風格、有熱情的人。
  533. 這樣的人在這種關鍵時刻會提出更多想法,
  534. 也因此會產生更多好東西,形成正向循環。
  535. 例如每次我們有直播,
  536. 那天整個開發室的氣氛就會不同。
  537. 大家會提早下班,
  538. 點好外送,在自己位子上或家裡準備觀看直播,
  539. 然後一起在 Slack 的 Blue Archive 頻道裡討論。
  540. 那是一段療癒的時光。
  541. 像每次半年一次的大活動,
  542. 我們都會感嘆:「我真的為了這個超拼的……」
  543. 但看到大家這麼喜歡,真的非常感謝。
  544. 當你做出來的東西,
  545. 被老師們(玩家)親自遊玩,
  546. 那一刻真的非常感動。
  547. 雖然從開發端到玩家體驗之間有「延遲」時間,
  548. 但當你能即時看到玩家的反應時,
  549. 會覺得「我做了件非常有意義的事」,
  550. 也會獲得繼續創作的動力。
  551. 這已經變成一種文化,深植在團隊之中。
  552. 與老師們的直接互動,
  553. 讓我們看到自己的成果被珍惜、被喜愛。
  554. 這讓我思考:「我真的有可能做出這麼受人喜愛的遊戲嗎?」
  555. 即便再怎麼努力,
  556. 商業遊戲不見得能帶來這種「被愛」的感覺,
  557. 但 Blue Archive 給了我這份體驗。
  558. 也因此,我會更想去做、想得到更多回饋。
  559. 老師們的反應變成我們的動力來源。
  560. 這是其他地方得不到的幸福。
  561. 但這份「被愛」的回報,
  562. 不能是強迫的:「為了被喜歡你要努力!」這樣是行不通的。
  563. 這份品質,是取決於你把自己熱愛的事物,
  564. 融入作品中的程度。
  565. 不能用「大家會喜歡」當藉口來逼人加班。
  566. 那樣絕對不會有好作品誕生。
  567. 所以,我們要讓團隊每個人親自感受到,
  568. 自己傾注熱情完成的成果,真的受到好評。
  569. 像是我們會鼓勵大家參加線下活動,
  570. 無論是日本或韓國,
  571. 希望開發者能多與老師們見面交流。
  572. 參加活動不只是為了曝光,
  573. 也希望展現:「我真的持續為 Blue Archive 努力。」
  574. 如果我只說「遊戲很安全」但什麼都不做,
  575. 那就不是一位有責任感的開發者。
  576. 所以我會盡可能親自出席活動,
  577. 不論是官方還是非官方,
  578. 去現場感受老師們的熱度與想法。
  579. 而且我心中也有一份感謝之意,
  580. 即使是拍照等小事,
  581. 只要時間允許,我都會盡量滿足每一位老師的要求。
  582. 而這些互動,我們團隊也都在觀察與學習。
  583. 如何與老師們溝通、交流,
  584. 我們會從本部長身上學習,
  585. 然後在團隊內部形成良性循環、彼此提升。
  586.  
  587. 接下來是預告:「第2部 即將推出」。
  588. 會介紹日本市場的情況、競品如《賽馬娘》、
  589. 營運期間面臨的各種挑戰(如主線未配音)、
  590. 以及 IO 本部的延伸與新項目「RX」的開發理念等。
Add Comment
Please, Sign In to add comment