ゼルダの伝説TOTKの「スクラビルド」誕生秘話　現場の「ムリでは？」な雰囲気、どう解決したか　ディレクターが語る

　2023年に大ヒットしたゲーム「ゼルダの伝説：ティアーズ オブ ザ キングダム」（TOTK）。前作「ゼルダの伝説：ブレス オブ ザ ワイルド」の続編としての注目を浴びたのはもちろん、特に話題になったのは、2つのアイテムをくっつけることで、新たな機能や効果を得られる新機能「スクラビルド」だ。SNSや動画投稿サイトでは、アイテムを自由にくっつけて遊ぶ様子が大いに拡散した。

【その他の画像】

　とはいえこのスクラビルド、ゲーム内のありとあらゆるアイテムをくっつけられるだけあって、プレイヤーからも「よくこんな機能を実現できたなと思う」といった声が相次いでいた。実際、開発現場でも「ムリでは？」という空気が漂った時期があったという。TOTKの開発陣は、この機能をどんな経緯で考案・開発したのか。

　ゲーム開発者向けカンファレンス「CEDEC 2024」（パシフィコ横浜、8月21～23日）で、任天堂の藤林秀麿さん（ディレクター）と、廣瀬賢一さん（ゲーム開発インフラ担当）がその誕生秘話を語った。

●「スクラビルド」誕生のきっかけは「前作のギミック」

　藤林さんによれば、スクラビルドのような遊び方を思い付いたきっかけは、前作「ブレス オブ ザ ワイルド」のステージ「ラー・クアの祠」。このステージは、柵の向こうにあるスイッチをヤリで押せば先に進めるというギミックだったが、ここで「ヤリを2本つないで遊べたら楽しいだろうな」と考えたのがきっかけという。このアイデアは、他のアイテムにくっつけることで宙に浮かせられるアイテム「オクタ風船」という形でブレス オブ ザ ワイルドにも組み込んだが、TOTKでは目玉の機能として搭載されることになった。

　「ゼルダの伝説シリーズの本質は『推理して、実行して、その結果を楽しむ』ゲーム。例えば木を切れば丸太になる。それは押せば動く。川に押せば浮いて流される。流れる丸太に乗ればそのまま向こう岸に渡れる。どれも『こうなるんじゃないか』と推理してやってみて、その結果でゲームが進む形。ゼルダはこの工程が豊かなほど面白くなるので、新作を作るなら『推理』『実行』のターンでできることを、プレイヤーの自由な発想で広がるようにしたかった」（藤林さん）

　ただ、この発想がすぐに現在のスクラビルドになったわけではない。モノとモノを組み合わせると言えば簡単だが、そのやり方にはさまざまな形がある。例えば当初は「アイテムを合体させ、全く新しいものにしたら面白いのでは」というアイデアもあったという。A+B＝ABではなく、A+B＝Cにする考え方だ。

　しかし「推理して、実行して、その結果を楽しむ」というコンセプトに従うと、“合体案”は「完成したアイテムの見た目から、結果を事前に想像・推理しにくくなる」として不採用に。見た目が機能を表せるように、モノとモノがくっついた形になることが決まった。すると、今度は「いくつもくっつけられたら面白いのではないか」「角度も自由にできたら面白いのではないか」というアイデアが出てきた。

　ただし、これらのアイデアには問題点もあった。組み合わせが膨大になることだ。そもそもTOTKには大量のアイテムがあり、さらに自由な向きでくっつけられるとなると、パターン数は膨大になる。

　スクラビルドのアイデアを聞いたエンジニア陣からは「アイテム同士の効果をどのように反映するか」と、デザイナーやアーティストからは「くっつけた後の見た目はどういう法則で決めるのか、見た目の不具合の確認はどうするのか」、サウンドデザイナーからは「組み合わせ時の音声はどうするのか」、ゲームデザイナーからは「組み合わせたアイテムの命名規則はどうするのか」といった問題が提起された。結果「『ムリでは？』という漠然とした空気がチームを覆った」（藤林さん）という。

　しかし「ムリでは？　という空気に流されず、本当に実現が無理なのか知るため、ある作業を行った」と藤林さん。それは、浮き彫りになった問題の分解だ。まず、スクラビルドに関するアイデアや仕様を「希望・願望」（ウィッシュリスト）と「不可欠な仕様」（プランリスト）に分解したという。

　例えば、ウィッシュリストには「敵を操れる笛と、剣を組み合わせたら、振るだけで敵を操る剣が作れる」「グライダーの機能を持つアイテムと盾を組み合わせたら、背負うだけで滑空できるアイテムになる」といったアイデアを振り分け。一方でプランリストには「見た目が機能を表す」「素材を複数個、自由な場所にくっつける」といった仕様を振り分けた。

　その後、仕様として不可欠なプランリストから優先して、「組み合わせが膨大」というポイントにつながる部分をさらに分解・検証していった。

　例えば、たくさんのアイテムをくっつけたら本当に面白くなるのかを、テスト環境で実際に遊んで検証。結果、たくさんアイテムをくっつけると「相手を狙いにくくなる」「4本の武器をくっつけた武器を持つより、2本の武器をくっつけた武器を2セット持っていた方が便利」ということが分かった。さらに、くっつけるものが増えると、完成したアイテムの見た目から機能を推理しにくくなり、「見た目が機能を表す」というコンセプトに沿わないことも明らかになった。

　次に「自由な角度でモノをくっつけられたら楽しいのか」を検証。結果、角度が「見た目が機能を表す」ことが関連せず、面白さにつながらないことが分かった。例えば、風を起こせる葉っぱと棒をくっつけると、うちわ型のアイテムになるというアイデアにおいて、角度は面白さにつながらなかったと藤林さん。むしろ、適当にくっつけてもうちわ型になってくれた方が楽しいことが分かったという。

　ゲームデザイナーから出た、名前の組み合わせについても検証した。組み合わせたアイテム名をユニークなものにはせず、もともとのアイテム名をシンプルにしておいて、それを組み合わせれば分かりやすくなると結論が出た。例えば、薪は奇をてらわず「薪の束」に、たいまつはそのまま「松明」にし、組み合わせたときも「薪の束の松明」とすれば分かりやすくできたという。

　ここから、「見た目が機能を表す」「くっつけられるのは2つまで」「くっつく場所は固定」「名前は組み合わせ」といった、現在のスクラビルドの仕様が定まった。

　その後、改めてウィッシュリストのアイデアを確認。仕様に沿うものはそのまま、あるいは少し内容を変えて再利用したという。例えば「グライダーの機能を持つアイテムと盾を組み合わせたら、背負うだけで滑空できるアイテムになる」というアイデアは「空を飛べるわけではないが、坂道や平野をそりのように滑れる」形で再利用した。

　これにより、組み合わせ数の問題もある程度解決。「ムリでは？」という雰囲気も解消したという。最大2つの組み合わせでも約12万通りあったが、エンジニアやサウンドデザイナーからは「その程度ならどうにかできそう」と、ゲームデザイナーからは、名前について「法則が決まっているのであれば自動生成できそう」との回答が得られた。

　ただし、デザイナー・アーティストは「無限でないならやりようはあるが、数が膨大なのは変わらず、不具合のチェックについて根本的な問題は残る」とした。そして、これが機能開発における壁の一つになった。

●約12万通りのチェック、負荷削減の手は

　スクラビルドで生まれたアイテムは、見た目に不具合があると、くっつき方が想定と異なるものになる恐れがあった。さらに、元のアイテム名を組み合わせる命名法則に沿うと、見た目と名前が一致しなくなってしまうケースもあり、それぞれ修正したり、例外を設けたりする必要があった。

　例えば「岩と剣を組み合わせたら、岩に剣が刺さったような見た目にしたいのに、剣に岩が乗っているような見た目になってしまうので修正する」ケースや、「『白銀ライネル』というモンスターの角と剣を組み合わせたら、命名規則的には『白銀ライネルハンマー』になるが、見た目がハンマーっぽくないので『白銀ライネル粉砕剣』に修正したい」ケースなどだ。

　ただし、この確認作業は手間が膨大だった。開発機でゲーム内のカメラを回しながら確認し、アイテム一覧画面に移動して名前がおかしくないかチェックしなくてはいけない。確認のタイミングは、アーティストが武器やアイテムの見た目を作成・変更した後や、プロジェクトの区切りなど。確認はある程度数を絞って行う方針だったが、それでも都度チェックするのは負担が大きく、見た目の変更がためらわれる事態にもつながりかねなかった。

　そこで、ゲーム開発を支援するツールやそのインフラを手掛けるゲーム開発インフラチームは、スクラビルドで生まれたアイテムをあらかじめ撮影し、その写真を確認することで、おかしな点がないかチェック可能な仕組みを整えた。

　とはいえ、ただ画像がフォルダ内に並んでいるだけでは、チェックの手間はさして減らない。よりチェックを便利にするために、廣瀬さんはあるツールを使うことにした。それは、アーティストがアイデアやスケッチを記録するために使っていた社内の画像掲示板だ。

　画像掲示板はもともとゲーム開発インフラチームが開発したもの。ここにスクラビルドで作成できるアイテム画像をアップロードしたり、一覧化や絞り込み検索をしたりできるようにした。気になった点があったときは、対応が必要な旨を示せる仕様に。画像掲示板のボタンを押すだけで、ゲーム上に画像のアイテムを出現させたり、キャラクターに装備させたりする機能も用意した。これにより「まずは画像で確認し、気になる点があればそのままゲーム内で確認できる」フローを実現したという。

　この改善には思わぬメリットもあった。画像の撮影・投稿は見た目を変更したタイミングで毎回行う決まりで、履歴も残せた。この履歴から、バグなどの問題がいつから起こったか追えるようになったという。これにより、12万通りの組み合わせのチェックは「現実的な範囲に収まった」（廣瀬さん）。

　この評判はプロジェクト内で広がり、他の用途でも使われるように。例えば風による衣装の揺れの挙動確認にも使われたという。余談だが、廣瀬さんらゲーム開発インフラチームでは、開発者の悩みを直接解決するのではなく「開発者が自由に発明できる仕組みを作る」方針を取っていたため、利用の幅が広がったことも想定の内だったとしている。

●開発サイクルを円滑化「ルピー掲示板」

　スクラビルド含むTOTKの開発においては、藤林さんなどディレクター陣ではなく、廣瀬さんたちのチームが発案した仕組みが役立つこともあったという。その最たるものが「ルピー掲示板」だ。

　ルピーはゲーム内通貨の名前。もともとゲーム開発インフラチームが作っていた掲示板を独自にカスタマイズし、開発サイクルの改善に活用したという。

　TOTKでは、（1）新しいアイデアやシステム、仕様を発案する、（2）メンバーに説明し、理解してもらう、（3）実装する、（4）区切りごとにメンバー全員でプレイし、より良くできる点や気付きを探す、（5）得た情報を集約する、（6）集約した情報を精査する──という開発サイクルを回していた。ただ、特に（4）～（6）は膨大な情報を収集・集約する必要があり、効率化が求められた。

　そこで役立ったのがルピー掲示板だ。ルピー掲示板は、（4）で得た気付きを投稿できる場所。「良かった」もしくは「気になった」点についてコメントでき、誰が投稿したのかも明記される。対応がなされたり、対応の方針が定まった場合は担当者や関係者などがその旨を入力するため、掲示板をそのまま作業管理ツールや、精査時の資料として活用できたという。

　最大の特徴は投票機能だ。他の人の投稿で、共感できるものがあった場合、一人1ルピー（1票）を投票できる。これにより、共感した人がどれだけ多いか可視化する仕組みだ。ルピーが多い順に並べ替えることで、共感する人が多い投稿を絞り込むこともできた。

　「投稿について、どのように議論が行われ、何が取捨され、どういう経緯で結論が出たか、チームメンバー全員がダイレクトに閲覧できたので、透明性や納得度が高く、伝言ゲームのようにならない正確な情報共有ができた」（藤林さん）

　ただ、この掲示板には「誰のどんな投稿がルピーを獲得したか」が誰にでも分かってしまうため、ともすれば作業に携わったメンバーを委縮させてしまうリスクもあった。

　そこでチームでは「意見ではなく情報を書く」といったルールを設け、これを抑止したという。例えば「トゲを食らってゲームオーバーになった、理不尽だった」はNG、「トゲを食らってゲームオーバーになったのは理不尽に感じた。なぜなら、右から見ていたときはトゲが見えたのに、左からは見えず、不意打ちのようになったから」はOKという具合だ。

　他にも「認識が変わったら追記すること」「掲示板では議論はしない。同じ事象に対して別の意見があるなら、それは別途投稿すること」というルールも設けたという。スクラビルドについても、ルピー掲示板を発端として機能改善があった。例えば、当初は実際にアイテム同士をくっつけるのに5つの手順が必要だったが、面倒という意見が共感を集め、3手順に短縮したという。

　「スクラビルドができるに当たっては、アイデアの発案はもちろん、事前の問題解決という準備を行い、ゲーム開発インフラ側でもチェックの効率化という準備を行い、実装する人に落とし込んでいった。これらの準備を有効に運用するために、発案側はチーム文化の形成を、ゲーム開発インフラ側はサービスの用意という準備のための準備をしていた。今回の話はスクラビルドができるまでの全てではないが、ゲーム開発の一助となれば幸い」（藤林さん）