国内最大規模のゲーム業界カンファレンス「CEDEC2024」が、2024年8月21日（水）から8月23日（金）までの日程で開催されました。
初日の8月22日（木）には、任天堂 企画制作部の『ゼルダの伝説 ティアーズ オブ ザ キングダム』のチームから、ディレクターの藤林 秀麿氏とゲーム開発インフラ担当の廣瀬 賢一氏が登壇。「『ゼルダの伝説 ティアーズ オブ ザ キングダム』のスクラビルドができるまで ～準備のために準備する～」と題した講演を行いました。
主人公・リンクが使う武器などに素材をくっつけられる能力「スクラビルド」は、その組み合わせの数が膨大となり、開発には困難を伴います。
その実現過程を通じて、問題解決の方法やチームとのコミュニケーション、チェックの効率化などの“課題への向き合い方”が語られた本講演をレポートします。ゲーム開発に限らず、新しいことを始めてみたものの課題にぶつかった際にも応用できる知見です。
TEXT / 酒井 理恵
SUPPORT / 田端 秀輝
ディレクターの藤林 秀麿氏（左）とゲーム開発インフラ担当の廣瀬 賢一氏（右）
本講演に登壇したのは『ゼルダの伝説 ティアーズ オブ ザ キングダム（以下、ティアーズ オブ ザ キングダム）』 のディレクターを担当した藤林 秀麿氏とゲーム開発インフラを担当した廣瀬 賢一氏です。
藤林氏は2005年度に任天堂に中途入社。以降、ディレクター、ゲームデザイナーとして携わる。それ以前にも「ゼルダの伝説」シリーズ開発に携わっていた
廣瀬氏は2018年に任天堂に中途入社。『ティアーズ オブ ザ キングダム』では、ゲーム開発インフラチームのリードエンジニアを担当した
廣瀬氏のポジションである任天堂の「ゲーム開発インフラ」は、ゲーム開発時に使用するサービスやインフラを整備する部署で、プロジェクト内のエンジニアの役割の一つとして存在します。開発をより便利に、効率を高める役割を受け持ちます。
「ゲーム開発インフラ」はブラウザで利用できるウェブアプリの形でサービスを提供し、サーバーなどサービスを動かす受け皿の部分を整備する
ゲーム開発インフラチームが開発したサービスの例には「画像掲示板」があります。アーティストがアイデア画像を投稿して共有するための仕組みで、ウェブブラウザからアクセスするものでした。
「ディレクター」と「ゲーム開発インフラ」という、同じプロジェクトといえど、異なる分野の仕事を受け持つ2人が話すのは『ティアーズ オブ ザ キングダム』に登場した能力「スクラビルド」ができるまでの過程。
『ティアーズ オブ ザ キングダム』の主人公・リンクが使う、武器や盾、弓に何か1つの素材をくっつけることで別の効果を付加することができる能力であるスクラビルドは組み合わせの数が膨大になりますが、それにどう対処したのか、また、その仕様をどのように固めていったのか、「ディレクター」と「ゲーム開発インフラ」の両面から語ります。
「スクラビルド」の発想は、前作『ゼルダの伝説 ブレス オブ ザ ワイルド（以下、ブレス オブ ザ ワイルド）』の開発中に鉄格子の向こう側にあるスイッチを槍でつついて動かすという仕掛けを作った時に生まれたと藤林氏。槍を2本つなげると、さらに奥のスイッチに届くというものができたら面白いと思ったそうです。
『ブレス オブ ザ ワイルド』で、鉄格子の隙間にあるスイッチを槍でつつく場面。この時は槍一本を使った仕掛けだった
藤林氏は新しい「ゼルダの伝説」を開発する際に、面白い事が起きる仕組みを作るというテーマを持ち続けていました。さらに、こうした仕組みを掛け合わせることで、思いもよらない新しい体験を生み出せそうだと思っていたそうです。
『ブレス オブ ザ ワイルド』に登場した、オブジェクトに付けると浮かばせることができる「オクタ風船」。何かをくっつけるという遊びに高いポテンシャルを感じていたという
例えば、物理法則が効いている世界に、起伏がある地形と押せば転がる岩を用意します。崖の下に穴や敵、通行人を設定したらどうなるかと藤林氏は想像させます。
講演では、崖上に岩、崖下に敵を配置し、転がり落ちる岩で敵にダメージを与える動画を再生しながら、仕組みを掛け合わせることで、さまざまな体験が生み出せることを提示しました。
「もの」と「もの」をくっつける「スクラビルド」という能力もこうした思考の延長に生まれたと藤林氏。しかし、ゲームに採用されるまでにはさまざまな試行錯誤があったと言います。
試行錯誤の過程の説明に入る前に、藤林氏は「ゼルダの伝説」シリーズの本質について「推理し、実行してみて、結果を楽しむゲーム」であると考えを述べました。
例として、開発過程での検証用ゲームでリンクが火をつけた矢を木箱に当てて木箱が燃える様子や、切った木を使って川を下る様子を見せます。
そこにあるものから何ができるか推理・実行し、ゲームを進めるのが「ゼルダの伝説」シリーズの遊びだと藤林氏。この工程を豊かにすることがシリーズの命題だと考えました。
そこで、推理と実行の幅をプレイヤー自身の自由な発想で広がるようにすべく、藤林氏は「スクラビルド」の「くっつける」というアイデアを練ることにしました。
「スクラビルド」の検証は、武器に何かをくっつける能力として行われました。
検証を繰り返す中で、物をくっつける「スクラビルド」は確かにゲーム中での推理の幅を広げると藤林氏は感じました。
初期のスクラビルド実装例。カボチャ畑で槍を振り回せば槍先にカボチャがくっつき、破壊力が増して木箱を壊せる
左右に剣をくっつけた盾を背負って歩くと、周囲の草が刈れたり、ぶつかった木の小枝が切断できたりする
同時に、「スクラビルド」の本質が「絵が機能を表す」、つまり見た目が機能を説明している必要があるということに辿り着いたと藤林氏は言います。推理し実行し結果を楽しむという遊びにおいて、結果が想像できることは重要です。「A+B=C」のようにAとBとは別のもののであるCが生まれるのではなく、「A+B=AB」のようにAとBから想像できるABが生まれるようなものが良いと結論しました。
棒と岩をくっつけたら、破壊力のありそうな武器ができそう、と絵から推理できる
「A+B＝C」パターンは結果を事前に推理・想像するのが困難
「スクラビルド」の仕様検証の過程で、2つ、3つとたくさんくっつけることができたらもっと面白いことが起こりそうだとアイデアは膨らんでいきました。
くっつける素材を増やした場合のイメージ。この3つの素材だけでもさまざまなバリエーションを作れそうだが……
しかし、この案は組み合わせの数が膨大で、開発チームに「スクラビルドは無理ではないか」という漠然とした不安を広げてしまったと藤林氏。さまざまなセクションから疑問が噴出します。
例えば、エンジニアセクションからは「くっつけた時の武器の効能は元からの武器の効能がいっぺんに発動するのか」という疑問。アーティストセクションからは「見た目の不具合がないか、膨大な数のチェックをどうするのか」という疑問。他にも、サウンドデザイナーセクションから武器を振ったときの音のバリエーション、ゲームデザイナーセクションから武器の命名規則に対する疑問などが挙げられたと言います。
しかし、こうした空気はスクラビルドの仕様が未完成であったから生まれたと藤林氏。本当に無理なのかを確認するため「問題を分解する」作業に着手したそうです。
問題の分解作業は、膨らんだ構想を「あったらいいな」という希望や願望である「ウィッシュリスト」と不可欠な仕様である「プランリスト」の2つに分けることから始めました。
「ウィッシュリスト」には、ボコブリンを操るボスボコブリンの笛を武器に付けたらプレイヤーもボコブリンを操れる、盾に翼をつけて背負えば空を飛べる、などの案がリストインしました。推理するには発想が飛躍しすぎであるためです。
ウィッシュリストに挙げられたものは必須の条件ではないため、ここで一旦優先作業から外します。
一方、「プランリスト」には「絵が機能を表す」「何でもくっつけられる」「素材は複数個つけられる」、「素材は自由な場所にくっつけられる」といったものがリストインしました。
バリエーションの数の問題を分解・検証する作業は最初期に行ったと藤林氏。当時の様子の動画では、先ほど不採用案として紹介された「A+B=Cパターン」をはじめ、「同じ武器をたくさんくっつける」「剣にくっつける角度を変える」「くっつけるときの手ごたえ」「くっつける物の大きさ」「剣に付けた薪が燃えてなくなる」などを検証していました。
肉を弓矢にくっつけて飛ばす検証も実施していた
くっつける物を2つ、3つと増やしてみると、狙いにくい・背中に背負えないといった問題が発生しました。また、武器としても2本つなげたものを2セット持っていたほうが有用でした。
長さや相手との距離は3Dゲームでは捉えにくい。これもくっつけられる数を増やさなかった理由の1つ
素材を自由な角度でくっつけられたら楽しいのではないかというアイデアは、『ティアーズ オブ ザ キングダム』に角（つの）の向きと剣の振る方向を連動させて攻撃力が変わるような仕様がないため、あまり意味がないことが分かりました。
武器につけて振ると強い風を起こすことができる葉っぱも、プレイヤーに「風が起きそう」という推理をさせたかったことから、むしろ適当な角度でつけても団扇状の見た目になるほうが有用でした。
多数の種類の素材をつける案は形状・機能の結果予測をしづらいため「推理を遊ぶ」という目的には向いていないと判断しました。
名称の検証においては、名前が機能を表す案は分かりやすいことが分かりました。くっつける前の名称もできるだけ機能を表すようにし、くっつける際はその名前をシンプルにくっつけるのが有効でした。
このような検証を通して「敵から取得したものや、落ちているものなど何でもくっつけられる」というのは、見た目からの推理・実行ができる仕組みであると確信が持てたと藤林氏は言います。
実際に触って検証し、ルールを絞りこんだ後に実施したのは「やらないことを決める」ことでした。検証の結果「やらないこと」は主に3つに絞りこめました。
この内容をプランリストに反映した結果、「素材は複数個つけられる」という項目は「素材は1つだけつけられる」に、「素材は自由な場所にくっつけられる」という項目は「素材をつける場所は固定する」に変わりました。しかし、企画の内容そのものを絞ったわけではなく「ゼルダの伝説」シリーズにおける「推理し、実行する」とうい遊びに適した形に変更したものです。
ここまでシンプルに絞れたのは、問題を分解することの効果だと藤林氏は述べます。
検証を通して、命名規則も重要なポイントとしてプランリストに追加となった
プランリストを絞りこめたため、ここでウィッシュリストの案のうち、プランリストの条件をクリアし、実現の見込みのあるものを採用しました。
盾に翼をつけた時の効果も初期案の滑空する挙動ではない形で復活した
「スクラビルドの実装は無理ではないか」という空気は、問題を分解して考え、検証や対処を考えたことにより「なんとかなりそうだ」と変化したそうです。ただし、検証を反映した新しいプランリストでも組み合わせは12万通りに及びました。この12万通りすべてに対して、デザイナーセクションは見た目の整合性と不具合チェックをする必要があります。
ここで話者が廣瀬氏に交代。スクラビルドの開発に必要な12万通りに及ぶチェック作業という課題を、ゲーム開発インフラがいかに解決したか語ります。
ゲーム開発インフラチームは、明確になったスクラビルドの遊びが妥協によって減ってしまうことのないよう不具合チェックをいかに効率を上げるかQAチームと連携して取り組みました。
アーティストは武器やアイテムの見た目を制作後、その結果の確認が必要です。例えば、岩の形状を変更した場合は、その岩をスクラビルドし、カメラを操作してめり込んでいないか、見た目が破綻していないかなどのチェックが必要です。
岩が剣の上に乗ってしまっており、アーティストの意図通りにならなかった例。右の絵のように修正した
また、スクラビルド後の武器名は一定のルールによって生成されますが、ルールに不足があると、武器の名称と見た目が一致しないということが起こります。こうした整合性もチェック・修正する必要があります。
ポーチ画面を見て名前やアイコンの画像を確認。「白銀ライネルハンマー」という名前の武器だが、ハンマーには見えない。武器名は「白銀ライネル粉砕剣」に変更した
これらのチェック作業は、重要なマイルストーンの際に、製品の品質を担保できる範囲でピックアップした上でテスターによるチェックを実施します。このため、全体チェックは複数回実施することになります。確認サイクルは素早く回せることが重要です。
確認コストが高いということは、ブラッシュアップの内容がコストに見合うかという判断が入り、変更に躊躇や取りやめが発生しかねません。それでは面白さの追求が十分にできなくなってしまう、と廣瀬氏。確認の手間を軽減することはゲームの質を上げるためにも非常に大事でした。
12万通りの不具合チェックの問題の解決策として、ゲーム開発インフラはスクラビルド後の画像をあらかじめ撮影し、撮影済み画像として用意。ゲームをプレイすることなく画像を見るだけでチェックが完了するようにしました。
撮影済み画像は、代表的な武器に同一のものをくっつけた画像や、ポーチを開いた状態での画像などを用意しました。オブジェクト同士の不自然な隙間・貫通状態の確認には、スクラビルド済みの武器だけを多面展開図で撮影したものを使っています。
全体感の確認に使用した撮影済み画像。不自然な形状、地面に埋まったものがないかを確認
ポーチを開いた状態での確認。武器全体の形状やアイコン、見た目と武器名が合っているかなどをチェック
プロジェクトの進行に伴い、必要な撮影バリエーションは増加。フォルダに画像が並んでいるままではチェック作業が困難になるため、手軽にチェックできるよう「画像掲示板」を使っての整理も実施しました。
画像を一覧できるとともに、必要な観点での絞り込みも可能。画像をクリックすれば、画像の詳細も確認できる
気になった点を見つけた場合は直接、報告作業ができるようになっています。手順が複雑だと後回しにして忘れてしまうということが起こりえるため、手軽に作成できる仕組みを用意しておくことが大切だと廣瀬氏は述べています。
画像掲示板はゲームと連携していて、画像掲示板内からワンクリックで直接ゲーム内に必要なものを生成できる機能があります。撮影画像では情報が不十分と感じた場合は、この機能を使って確認を進めます。
画像掲示板の「素材を接地生成」を実行し、樽を出現させる
スクラビルド済みの武器を装備して出現させることもできる
アーティストが見た目をブラッシュアップした後の確認を画像掲示板上でできるよう、最新の撮影画像は画像掲示板に毎日投稿されます。
撮影時のビルド番号も表示されるため、問題発生時にいつから発生していたのか、原因となったコミットがどれなのかも特定できます。これはバグ発生時期の調査負担の軽減に非常に有効だったと廣瀬氏は述べました。
画像掲示板上で変更した武器の名称で絞り込むことで一括で確認が可能
写真にはバグ発生時のビルド番号も表示
こうした対応により、スクラビルドの確認コストは軽減。12万通りの組み合わせチェックという問題は現実的な負荷に落ち着きました。
スクラビルドに限らず、大量の目視確認が必要な作業でこの撮影の仕組みは有用であったため、プレイヤーの防具確認など新たな使用用途でも依頼が来るようになったそうです。
画像掲示板に動画を投稿できることを利用して、風による揺れの挙動も確認可能に
スクラビルドの「仕様作成のための準備」として問題解決を行ったのに対し、その準備を進めるために「準備のための準備」の作業が必要だったと話す藤林氏。ここからは、ゲーム開発インフラが課題解決を行うのではなく、ゲーム開発インフラの作った仕組みをゲームデザイナーが活用した実例を話しました。
『ティアーズ オブ ザ キングダム』の制作は、スクラビルドを含めたゲームデザイン全般の各種資料を提示するところから始まります。メンバーにその内容を説明した後に実装、そしてマイルストーンごとの全メンバーによるプレイ「マイルプレイ」を行います。マイルプレイで集めた情報は収集・集約され、主要メンバーで精査。今後さらにゲームをより良くするためにどんな作業をするのかを確定すると、再びチームのメンバーに情報が展開され、実装へと続きます。これを繰り返し、最後に完成となります。
四角の枠で囲っている部分を繰り返すことで開発サイクルが回っていく。赤い部分は膨大な情報の収集や整理が必要であり、効率化できる方法が求められていた
この一連の開発サイクルを効率化するにはチーム文化の形成が不可欠と藤林氏。チーム文化とは、どういうものを是とし、何を非とするのかというルールや認識合わせ、いわば「共通の辞書作り」です。例えば、スクラビルドの目指すところやコンセプトの理解、プランリストとウィッシュリストの内容、そして「やること」と「やらないこと」の理解などが挙げられます。
ディレクターやセクションのリーダー、担当するゲームデザイナーは認識を合わせ、明確なビジョンを持つ必要がある
そこでチーム文化の形成を推進するにあたって活躍したのがゲーム開発インフラチームが作っていた掲示板でした。
ここで、開発サイクルを円滑に回す大きな力となった「ルピー掲示板」を紹介しました。ルピーとは「ゼルダの伝説」シリーズで使われる通貨の単位。「ルピー掲示板」は、掲示板にゼルダチーム独自の運用ルールと簡単なカスタマイズを加えたものです。
ルピー掲示板にはマイルプレイ中のメンバーがリアルタイムで感じたことを書き込んでいきます。投稿は次の10個の入力欄で構成されています。
他のメンバーも傍らでルピー掲示板を常に見ておくというのが基本ルールで、もし自分も同じように感じた投稿があれば新しく投稿するのではなく、ルピー欄に投票します。これにより、同じ情報の重複投稿が避けられ、マイルプレイ後の情報集約の負担を大幅に削減できました。
掲示板の名前の由来となる「ルピー欄」は投稿への同意を示す投票欄。1つの投稿につき1人1ルピー＝1票を投じることができる。赤が20票、青が5票、緑は1票を表し、色は自動で変換される
レビュー欄では、この件についてどのように議論が行われ、どういう経緯で結論が出たのかをチームメンバー全員がダイレクトに知ることができます。透明性や納得度が高く、伝言ゲームにならずに情報を正確に共有・浸透するのにつながりました。
「レビュー欄」には今後どのような方針で動くのかが表記されるため、掲示板をそのまま作業管理ツールとして運用できる
ルピー掲示板はカテゴリー別のリスト化や、ルピー得票数の昇順・降順のソートも可能で、数千ある投稿の中で最多ルピーを獲得している投稿がすぐ分かりました。便利な機能ですが、掲示板は使い方を間違えると利用者に恐怖を与える可能性もあると藤林氏。そこで、開発チームでは掲示板の利用について3つのルールを設定しました。
「意見」と「情報」の違いを例を挙げて説明。それぞれ以下のような表現になります。
意見：「トゲをくらってゲームオーバーになりました。理不尽です」
情報：「トゲをくらってゲームオーバーになるのは理不尽に感じた。なぜかというと右から見たときはトゲが見えていたのに、左からの時はトゲが見えず不意打ちになったから」
両者の違いは、改良の手がかりがあるかないかだと藤林氏は言います。「情報」には、投稿者の感じた理不尽ポイントが書いてあるため、修正すべき点が絞りやすいです。これがないと、担当者は投稿者に再びインタビューすることになり、双方の時間が消費されて非効率となってしまいます。
また「意見」は感情的な書き方や捉え方になることがあります。それを「情報」に変換して書くことで投稿者は気になった事象を分析するようになるため、自分たちが作っているゲームへの造詣が深まるという利点もあります。
コメント欄には、感じたこととその理由、もしこうなっていたら書いたようには感じなかった、といったことが書かれていると良いと藤林氏
プレイの最初は「難しい」という情報も、プレイしているうちに感じ方が変わるという事はよくあることです。これを最初の「難しい」という情報のままにしておくと精度が低くなってしまいます。追記することによって、思考の変遷を知ることができ、ゲームデザイナーが難易度調整レベルデザインする上でとても有効な情報になったと藤林氏は語りました。
ルピー掲示板の投稿欄は追記機能で他人の投稿にコメントすることもできますが、『ティアーズ オブ ザ キングダム』の開発チームでは、コメントによる議論はやらないことにしていました。もし、何か思うことがあれば議論ではなくて、自分が感じた内容を新しく情報として投稿する形の方が、チーム文化の形成の促進につながると考えていたからです。
また、書くことで自分たちが作っているゲームへの造詣が深まり、他のメンバーが投稿した情報を読むことでも造詣が深まります。
スクラビルドの発動手順の短縮は掲示板の情報により改善されたものの1つ。スクラビルド発動で一気にくっつけられるところまで自動化した
ルピー掲示板により、メンバー同士で作ろうとしているものへの意識が統一され、チーム文化も形成。開発サイクルがうまく回せるようになったと藤林氏。ルピー掲示板では、新しく投稿されたものであっても均衡したルピー得票数になることもあり 、それはそれで貴重な情報になったといいます。
このルール運用でルピー掲示板はゲームをより面白くするためだけの情報が集まり、開発サイクルを効率的に回せるツールとなりました。
ここからは再び廣瀬氏に代わり、ゲーム開発インフラチームで行っていた「準備のための準備」を語ります。
ゲーム開発を支えるサービスには、ルピー掲示板や画像掲示板がありました。ゲーム開発では問題点とともに新たにやりたいことも多数発生しますが、その全てをゲーム開発インフラチームが直接解決するのは限界があると考えたそうです。
そこで、『ティアーズ オブ ザ キングダム』が「面白いことができる仕組みを作る」ことによって、プレイヤーが自由な発想のプレイスタイルで進めていくことができるのと同様に、ゲーム開発インフラでも開発者が自由に発明できる仕組みを作ることにしました。
ゲーム開発インフラが準備したデータ収集/分析の仕組みを例にとって解説します。
エンジニアから「バグの内容を分析したい」という相談を受けたゲーム開発インフラチーム。そこで、ゲーム開発インフラチームは、データ収集/分析の仕組みを用意。エンジニアはそれを利用して、開発機から出力されるエラー情報を投稿するようにしました。これにより、よく起こるバグが一覧できるようになりました。
データ収集/分析の仕組みは、エラー情報だけではなく、幅広いデータが格納可能な仕様でした。そのため、担当者によってさまざまな使い方が発明されました。
スケジュール管理担当者はプロジェクトの進捗度合いの分析に利用。データ収集/分析の仕組みにタスクの進捗情報を入れ始めました。
タスクの進捗をグラフ化したほか、タスク数の分析、期限までにタスクが完了できるかの予測にも使われました。
最適化の担当者は、負荷状況の可視化にデータ収集/分析の仕組みを採用。『ティアーズ オブ ザ キングダム』の舞台であるハイラル全土を少しずつ場所を移動しながら負荷を計測。自動処理でその結果をデータ収集/分析の仕組みに集約しました。
取得したデータを基にマップに負荷状況をプロットしたヒートマップは毎日作成し、それを参考に最適化を実施していきました。
赤いところは負荷が高いところを示す。徐々に赤いところが減って最適化が進んでいったことがわかる
サウンド担当者は、ゲーム中の各場面を戦闘以外・通常敵戦・ボス戦と分類し、それぞれの場面における音量計測結果をデータ収集/分析の仕組みに投入。通常敵戦やボス戦といった緊張感が増す場面ほど、平均音量を大きくするというサウンドデザイナーの方針が実現できていることの確認に役立てました。
グラフの縦軸は音量。横軸が長いほどその音量の発生回数が多い
それぞれの立場の人が自分が解決したい要件のために自由に利用し、新たな使い方を多数発明しました。
発明のために使われたのはデータ収集/分析の仕組みだけではありません。アーティストのアイデアやラフスケッチを投稿するために作成した画像掲示板は、QAチームとゲーム開発インフラチームが協力してスクラビルドの撮影を投稿するという新たな使い方を発明しました。
ほかにも、スクラビルドの武器名のローカライズもこうした仕組みを利用して誕生したそうです。
スクラビルドの開発のために、数多くのサービスが生まれた
ここまで廣瀬氏が解説した多数のサービスは、サーバーがダウンするとプロジェクトの開発者全員の手も止めてしまうものです。
そのため、ゲーム開発インフラはサーバーがクラッシュしても動き続ける安定稼働を実現しました。サーバーの負荷が上昇するプロジェクトの増員時に、自動的にサーバー台数が増え、性能が上がるようにしています。
プロジェクトの役に立つものを作ることは、ともすると一人よがりの仕様になってしまうことがある、と廣瀬氏。これを避けるためにはできるだけ早い段階で現場投入し、フィードバックを受けながら作り込むことが非常に有効だと語りました。
例として、組み合わせ不具合チェックの確認のために行ったスクラビルドの撮影サービスを挙げました。
この撮影は、製品上の見た目での確認が必要なため開発機で撮影したいという要件がありました。しかし、スクラブルドの組み合わせは12万通りあり、しかも複数観点での撮影が必要なため、撮影すべき点数が膨大になりました。さらに、撮影活動はプロジェクトでどんどん広がり、日々増加している状況でした。
撮影の種類を増やすためには開発機を追加する必要がありますが、開発機やPCは用意・配線・初期設定などの準備が必要で手間がかかります。
そこで、ゲーム開発インフラチームで「開発機クラウド」というものを構築することにしました。これはあらかじめ準備されている開発機の中から必要な分をすぐに利用できるという仕組みです。また、開発機を制御するためのCI用PC環境も同時に用意しました。
Switch開発機・CI用PC環境ともに物理的な作業なしで利用開始可能な仕組みになっている
さらに、利用開始までの手続きが煩雑になるとスピード感が失われてしまうため、セルフサービスによる無人対応を重視。必要な人が必要な分だけ利用可能にしました。この開発機クラウドにより撮影の種類を増やすための開発機の追加が素早く完了するようになりました。
思い立ったらすぐに利用できるようWeb UIも用意
用途を選べばおすすめのスペックが作成できるようになっている
本作の開発を通じて新しく作り上げた開発機クラウドは社内の他のゲームにも利用が広がったそうです。
別のプロジェクトで利用する際もボタン1つで済む簡単な仕様で、任天堂社内の幅広いプロジェクトで開発機クラウドが利用されました。使われずに放置されている開発機も減り、全体的な利用効率が上昇したと言います。
プロジェクトで必要になったのを契機に作り始めた開発機クラウドは、検証の段階から現場投入し、実利用を通じてサービスを作り込みました。共通で使用できるインフラ基盤として作ったことがさまざまなプロジェクトに広がった要因だと廣瀬氏は考えています。
開発機クラウドは撮影以外の用途でも利用されました。スクラビルドの組み合わせ自動実行により、クラッシュしたり、予期せぬエラーが発生したりしないかというテストも行われています。また、CI用PC環境を利用したゲームリソースのコンバートといった用途にも使われました。
最後に、藤林氏が本講演をまとめます。
スクラビルドは「くっつける」というアイデアの発案はもちろん、発案する側の問題解決という準備、ゲームインフラ開発側のチェック効率化という準備を双方が行ったことで、実現しました。
しかし、その裏では、発案する側はゲーム開発インフラ側が準備したものを活用した、チーム文化の形成という「準備のための準備」を、またゲーム開発インフラ側も発案する側と綿密に連携しつつ、ゲーム開発を支えるサービスの用意という「準備のための準備」をしていたのでした。
実際に『ティアーズ オブ ザ キングダム』でスクラビルドを実現するために効果を発揮した手法の概念や運用手法は、他のプロジェクトでも応用できるかと思い紹介したと藤林氏。「もし本日お話しさせていただいたことが、今後、皆さんのゲーム開発の一助になれば幸いです」という言葉で本講演を締めくくりました。
『ゼルダの伝説 ティアーズ オブ ザ キングダム』公式サイト『ゼルダの伝説 ティアーズ オブ ザ キングダム』のスクラビルドができるまで ～準備のために準備する～ - CEDEC2024ゲームメーカーズ編集。その他、ソーシャルゲーム、ボイスドラマ等のフリーのシナリオライターとしても活動中。突き抜けた世界観のゲームが好き。
『サガ・フロンティア』のアセルス編などのゲームを心のバイブルにして生きてます。
西川善司が語る“ゲームの仕組み”の記事をまとめました。
Blenderを初めて使う人に向けたチュートリアル記事。モデル制作からUE5へのインポートまで幅広く解説。
アークライトの野澤 邦仁（のざわ くにひと）氏が、ボードゲームの企画から制作・出展方法まで解説。
ゲーム制作の定番ツールやイベント情報をまとめました。
東京ゲームショウ2024で展示された作品のプレイレポートやインタビューをまとめました。
CEDEC2024で行われた講演レポートをまとめました。
BitSummitで展示された作品のプレイレポートをまとめました。
ゲームメーカーズ スクランブル2024で行われた講演のアーカイブ動画・スライドをまとめました。
CEDEC2023で行われた講演レポートをまとめました。
東京ゲームショウ2023で展示された作品のプレイレポートやインタビューをまとめました。
UNREAL FEST 2023で行われた講演レポートをまとめました。
BitSummitで展示された作品のプレイレポートをまとめました。
ゲームメーカーズ スクランブルで行われた講演のアーカイブ動画・スライドをまとめました。
UNREAL FEST 2022で行われた講演レポートやインタビューをまとめました。
CEDEC2022で行われた講演レポートをまとめました。
