スクラビルドのテーマは「面白いことがおきる仕組みを作る」。12万通りもの組み合わせチェック問題を解決し、実現へ導いた「準備のための準備」とは。【CEDEC2024】

2024年8月21日～23日に開催された「CEDEC 2024」にて、任天堂の藤林秀麿氏と廣瀬賢一氏による講演「『ゼルダの伝説　ティアーズ オブ ザ キングダム』のスクラビルドができるまで　～準備のために準備する～」が行われた。 【この記事に関連するほかの画像を見る】 『ゼルダの伝説　ティアーズ オブ ザ キングダム』（以下、『ティアーズ オブ ザ キングダム』）の特徴のひとつとなっているスクラビルドは、武器や盾、弓にさまざまな素材をくっつけて、性能を強化したり別の効果を付加できる能力だ。 今回の講演では、「スクラビルドを発案する人」として、同作ディレクターの藤林秀麿氏が、「サービス・インフラを作る人」として同作のゲーム開発インフラ担当の廣瀬賢一氏が、それぞれのセクションを代表して登壇し、スクラビルド実現の裏側について詳細に語った。 両氏の講演を通じて浮かび上がったのは、単なるアイデアの発案だけでなく、それを実現するための「準備」、さらにはその準備を支える「準備のための準備」の重要性だ。 開発を進める中で、チーム関係者内に渦巻いていた「ムリでは？」という空気をどのようにして変えたのか。そして、スクラビルドで生まれた12万通りもの組み合わせのチェック作業をいかにして可能としたのか。本稿ではその講演の内容をレポートしていきたい。 文／Grezzz 編集／久田晴 ■テーマは「面白いことがおきる仕組みを作る」。『ゼルダの伝説』とは推理→実行→結果を楽しむゲーム 藤林氏によると、スクラビルドの発想は前作『ブレス オブ ザ ワイルド』の開発中に生まれていたという。とあるほこらのパズルで、鉄格子の向こうのスイッチを槍で突いてオンにするという仕組みを作った際、「もっと遠くにスイッチがあり、槍を2本つなげたら届くというのがやれたら面白いだろうな」と思ったのが始まりだったそうだ。 同じく『ブレス オブ ザ ワイルド』に登場したオクタ風船もその片鱗だといい、「何かをくっつける」という遊びには高いポテンシャルを感じていたという。 これらの発想の背景には、「面白いことが起きる仕組みを作る、という『ティアーズ オブ ザ キングダム』開発のテーマがあった」と藤林氏は話す。ゲームの中に自然と面白いことが起こるような仕組みをたくさん作っておき、それらが掛け合わされることで思いもよらないことが起こり、新しい体験を生み出せると考えたそうだ。こうした仕組みをさらに伸ばすものとして発想したのが「スクラビルド」だった。 次に、スクラビルドという発想を形にすることについて語られた。ここで藤林氏は「そもそも『ゼルダの伝説』とは、どのようなゲームなのでしょうか」と、シリーズの本質を問う。氏によれば、その答えは「推理して実行して、結果を楽しむゲーム」だという。 そして、前作『ブレス オブ ザ ワイルド』の開発中の検証映像を例に挙げ、「矢に火がつき木箱が燃える」「火が付いた木の枝で木に着火できる」「木を切って丸太にし、それを川に流して渡る」など、様々な相互作用を示した。これらはすべて、プレイヤーが「こうなるんじゃないか」と推理し、実行して進むゲームプレイの例である。 藤林氏は、この工程が豊かなほど、ゲームが面白くなる構造を持っていると指摘した。そのため、新作では実行のターンでできることの幅をプレイヤーの自由な発想で広げられるようにすることで、より豊かで楽しいゼルダができると考え、「くっつける」というアイデアを突き詰めることにしたという。 そして様々な組み合わせで検証を進める中で、スクラビルドの本質が明確になってきた。その本質とは「絵が機能を表す」ということ。スクラビルドで作られたものの見た目が、その機能を直感的に説明している必要があるということである。 実は「くっつけた結果、別のものに変化する」というパターンも選択肢としてはあったという。ただ、この仕様だとその結果を事前に想像し、推理することが困難となるため、今回のスクラビルドの遊びには向いていないと判断された。 「絵が機能を表す」という方針が明確になった上で、さらに3つ4つとくっつけたら面白くなりそうだとアイデアは膨らんでいったが、ここには大きな問題があった。組み合わせの数が膨大になるということである。 ■問題を分解して「やらない事」を決める スクラビルドの実現においては、無限のような組み合わせに対して各セクションからさまざまな問題提起が行われた。総じて「数が膨大」という問題で共通し、「ムリでは？」という漠然とした空気がチーム関係者内に渦巻き始めたという。 藤林氏は、この状況に対して「ここで落ち着かないといけません」と強調する。「この段階では各セクションスタッフがただ、膨大な数になりそうな組み合わせに対し、漠然と問題視している状態です」と語り、そもそもスクラビルドの仕様自体がまだ検証段階で、「ふわっとした仕様」であるが故の、仕方のないことであると説明した。 そこで藤林氏が取った行動は、「問題を分解する」というアプローチだった。まず、スクラビルドの仕様を明確にするため、膨らんだ構想を「こういうのがあったらいいな」という希望・願望の類（ウィッシュリスト）と、推理→実行に不可欠な仕様（プランリスト）の2つに分解することから始めた。 そして、ウィッシュリストは必須の条件ではないとして優先作業から外し、プランリストの中で「数が膨大になる問題」に焦点を当て、検証をしていくことになった。 そうした検証の中で、「槍を3本、4本と繋げても扱いづらい」「くっつける角度は、ゲームの仕様や絵が機能を表す点であまり意味がない」「いろいろな種類をつけると、結果や機能が推理できない」ということが判明した。 一方で「名前も機能を表す」ように命名するのは、分かりやすく非常に有効であることが分かったり、「なんでもくっつけられる」要素は、見た目からさまざまな結果を想像する、「推理→実行」を地で行く仕組みであると確信したという。 これらの検証結果を踏まえ、次に藤林氏たちが行ったことは「やらないことを決める」ということだった。厳密にはここに列挙されるものに限らないそうだが、「ふたつ以上のくっつけ」はやらない、「つく場所が自在は」やらない、「名前をひとつひとつユニークに」はやらない、という3つが重要な項目として挙げられた。 そして、これら「やらないこと」をプランリストに反映した結果、「絵が機能を表す」「なんでもくっつけられる」は基本コンセプトとして変わらず残り、「くっつけられるのはひとつ」「くっつくパターンは固定」に変更。そして新たに「名前も機能を表す」ことがプランリストに追加された。 プランリストを更新したことにより、各セクションでも変化があった。組み合わせの数が限定されたことや、「名前も機能を表す」という項目の追加によって、おおむね問題への対処が可能となったのだ。 こうして、当初あった「ムリでは？」という漠然とした空気は、問題を分解して考え、検証や対処を考えたことにより、「行けそう！」という前向きな雰囲気に変わっていった。 ただし、ここにはアーティストセクションの「12万通りの見た目の不具合チェック」という大きな問題が残されたままである。 ■12万通りのチェックを可能にしたゲーム開発インフラ ここで話し手は廣瀬氏に交代し、12万通りの組み合わせをチェックするためにゲーム開発インフラチームが実施したことについて、説明が行われた。 まず、見た目の不具合チェックの具体例として、スクラビルドのくっつき方がおかしい問題や、武器の見た目と名前が合っていない問題が挙げられた。 こうした確認作業をゲーム上で行うのは非常に手間な上、アーティストによる見た目の変更時や、テスターによる全体的な確認など、チェックは何度も実施される。さらに組み合わせが12万通りともなれば、作業量は膨大だ。 こうなると、「変更が確認コストに見合わない」という理由から変更の躊躇や取りやめが発生したり、ほかのテストの時間が奪われる、という問題が懸念される。それゆえ、確認の手間を軽減することが非常に大切だったと廣瀬氏は強調する。 そこで開発インフラチームが用意したのが「撮影済み画像」の活用だ。この方法では、ゲームをプレイすることなく画像を見るだけでチェックが完了するので、手間が大幅に軽減できる。 これらの画像は、扱いやすいように「画像掲示板」によって整理された。さまざまな条件での絞り込みが可能で、画像の詳細からは直接タスクを発行可能だ。 また、ゲーム上で直接確認したい場合に、画像掲示板内のボタンから必要なものを直接生成できる仕組みも用意された。 さらに、最新の撮影画像が毎日投稿されるようにすることで、アーティストが見た目の変更を確認できるようになったほか、問題が発生したときに、その時期の特定も可能となった。 この撮影の仕組みはスクラビルドに限らず、大量の目視確認が必要な作業にはすべて効果を発揮した。プロジェクト内で評判が広まった結果、プレイヤーの防具の撮影や、風による揺れの挙動の確認などにも活用されたという。 これらの取り組みによって、「12万通りの不具合チェック」は現実的な負荷に落ち着いたという。 ■「準備のための準備」チーム文化の形成に役立った「ルピー掲示板」 ここで話し手はまた藤林氏に戻り、スクラビルドの問題解決という準備を進めるための「準備のための準備」として、「チーム文化の形成」について語られた。 スクラビルドの実装を具体的に進める段階では、関係するチームメンバーが、プランリストを中心にスクラビルドが目指すものを共通の認識として持つことが重要であり、それこそがチーム文化の形成だと同氏は話す。 そのチーム作りの具体的な方法の前に、藤林氏はまず『ティアーズ オブ ザ キングダム』の制作フローについて説明した。先ほど説明された「チーム文化の形成」は、上の図にある開発サイクルをスムーズに回すために必要であり、その中でも「マイルプレイ【※】」「情報の集約」「精査」の部分は、膨大な情報の収集や整理が必要なため、特に効率化が求められたという。 そこで活用されたのが「ルピー掲示板」と呼ばれるツールだ。これは、ゲーム開発インフラチームが作成した掲示板に、ゼルダチーム独自の運用ルールと簡単なカスタマイズを加えたものだ。 掲示板には、マイルプレイ中にメンバーがリアルタイムで感じたことを書き込み、他のメンバーの書き込みもプレイする傍らで常にチェックするのが基本ルールとなっている。 ひとつの投稿は合計10個の欄で構成されており、通し番号や投稿者欄、「良かった」か「気になる」を選択する印象欄、エリアについて表示する分類欄などがある。コメント欄はプレイ中に心境の変化があれば追記できる仕様だ。 掲示板の名前の由来でもあるルピー欄には「そうだね」ボタンがあり、プレイ中に投稿内容と同じように感じたものがあれば、新規投稿はせずにボタンを押して投票するルールだという。これにより情報の重複を避け、マイルプレイ後の情報集約が大幅に効率化されたと藤林氏は話す。 また、最後の項目のレビュー欄には、プロデューサーやディレクター、各セクションのリーダーが集まって精査した内容の経緯と詳細が明確に書かれており、チームメンバーが直接それを確認できる。透明性と納得度が高く、メンバー全員での正確な情報共有が可能となったことにより、開発サイクルを円滑に回す大きな力になったと藤林氏は話した。 投稿内容は、カテゴリ別にリスト化したり、ルピー獲得順でのソートも可能。数千ある投稿の中で、「最多獲得ルピー投稿」もすぐに分かる仕様は「恐怖でもありました」と藤林氏は冗談交じりに振り返った。 ただ、掲示板であり、コメントが書き込めるという特性上、使い方を間違うと危険であると同氏は言う。そこで、ルピー掲示板を運用するにあたって大きく3つのルールを定めたという。 まず、「意見」ではなく「情報」を書くこと。「どこの何に、どう感じ、その理由はどうしてか？ もしこうなら、そう感じなかったのではないか」という情報が書かれていれば、担当者は投稿者が感じた理不尽なポイントや修正すべき点について焦点を絞りやすくなると藤林氏は言う。 また、意見は感情的な要素を含むこともあり、それを情報へと変換して書くこともポイントになったそうだ。そうすることで、投稿者は気になった事象に対してしっかり分析して書くことになり、それを通じて自分たちが作っているゲームへの造詣が深まるのだと藤林氏は説明した。 次に、認識が変わったら追記すること。例えば最初は難しいと感じていたことが、プレイしている途中で変わった場合、最初に書いた情報をそのままにしておくと情報の精度が低くなってしまう。逆に、追記することによって投稿者の思考の変遷を知ることができ、ゲームデザイナーが難易度調整やレベルデザインをする上でとても有効だったと藤林氏は語った。 最後に、議論は「やらない事」。掲示板は他人の投稿にコメントする機能も有していたが、もし同じ事象に対して別に感じた情報があれば、別途投稿するルールとしたそうだ。 理由として藤林氏は「議論することが駄目というわけではなくて、もし何か思うことがあれば議論ではなく、自分が感じたことの内容を新しく情報として投稿する形の方が、チーム文化の形成の促進につながると考えていた」と説明した。 また、新しく投稿したものが均衡したルピー得票数になることもあり、それはそれで貴重な情報となったという。 これらのルール運用によって、ルピー掲示板はゲームをより面白くするためだけの情報が集まり、開発サイクルを効率的に回せるツールになったと、藤林氏は振り返った。 ■スクラビルドを支えた数多のサービス。ゲーム開発インフラにもあった「準備のための準備」 ここで再び廣瀬氏が登壇する。同氏は、発案する側の「準備のための準備」と同様に、ゲーム開発インフラチームでも「準備のための準備」を行っていたと説明した。それは、ゲーム開発を支えるサービスの提供だった。 ゲーム開発時には常に新たな課題や要望が発生する。しかし、これらをすべてゲーム開発インフラチームが直接解決していくのは限界があると廣瀬氏は考えた。そこで、ゲームと同じ考え方で課題解決の仕組みを用意することにしたという。 『ティアーズ オブ ザ キングダム』では、先述のように「面白いことができる仕組みを作る」という考えに基づいたゲームデザインがされている。プレイヤーが自由な発想でプレイするのと同様に、「開発者が自由に発明できる仕組み」をゲーム開発インフラが作ることで、課題解決を図ったと廣瀬氏は説明した。 その中の一例として、廣瀬氏からデータ収集分析の仕組みの事例が紹介された。これは、エンジニアからのバグ内容分析の要望に応えるために開発されたものであり、エンジニアは開発機から出力されるエラー情報をこのシステムに投稿することで、頻発するバグの一覧が可視化され、エラー状況の全体像を把握しやすくなった。 そしてこのデータ収集分析の仕組みは、エラー情報に限らず幅広いデータを格納できる柔軟な設計になっている。そのため、さまざまな部門の担当者がそれぞれの課題解決のために独自の使い方を発明していったという。 例えば、スケジュール管理担当者はプロジェクトの進捗度合いを分析するために、タスクの進捗情報をこのシステムに入力した。これにより、タスクの進捗をグラフ化し、分析する仕組みが生まれ、期限までにタスクが完了できるかの予測分析にも活用された。 最適化担当者は、ゲームの舞台となるハイラル全土の各地点の負荷を計測し、そのデータをシステムに入力した。その結果、ゲームマップ上に負荷状況をプロットしたヒートマップが作成され、日々の最適化作業に活用された。 さらに、サウンド担当部門もこのシステムを活用した。ゲーム中の各場面（通常時、戦闘時、ボス戦など）における音量計測結果を入力し、その結果をグラフ化することにより、緊張感の増す場面ほど平均音量を大きくするという、サウンドデザイナーの方針が実現できているかを確認することができた。 このように、当初はエラー分析のために作られたシステムが、プロジェクト全体の進捗管理やパフォーマンスの最適化、音響設計の検証など、多岐にわたる用途に発展していった。これらは、「開発者が自由に発明できる仕組み」を提供するという方針が実を結んだ例といえるだろう。 スクラビルドを支えたサービスは、ルピー掲示板や画像掲示板だけにとどまらない。例えば、スクラビルド後の武器名を世界各国の言語に翻訳するためのローカライズの仕組みなど、様々なサービスが重要な役割を果たした。 これらの多数のサービスを安定稼働させることが大切だと、廣瀬氏は強調する。サービスが停止すれば、プロジェクト全体で開発の手が止まってしまうからだ。そのため、サーバーの一部がクラッシュしても全体としては動き続けるようにしたり、負荷増大に自動的にサーバーを増やすなど、さまざまな取り組みでサービスの安定性と快適性を維持したと同氏は語った。 廣瀬氏は、プロジェクトに役に立つサービスを作ることは、実は非常に難しいことだと語る。理由として、ひとりよがりな方向性・仕様になりがちなことを挙げ、できるだけ早い段階で現場投入し、フィードバックを受けながら作り込むことが非常に有効だと廣瀬氏は感じているという。 そういったゲームプロジェクトの中で成長したサービスとして、「開発機クラウド」が紹介された。 スクラビルドの組み合わせ確認作業では、12万通りもの組み合わせを複数の観点から撮影する必要があり、撮影すべき量は膨大になる。また、先述したように、撮影という活動はどんどん広がっていき、種類が日々増加している状況だったという。 撮影の種類を増やすためには、開発機を追加する必要があるが、従来の方法では、PCの用意、配線、初期設定などに多くの時間と手間がかかり、迅速な作業開始の妨げとなっていた。 この問題を解決するため、ゲーム開発インフラチームが構築したのが「開発機クラウド」だ。これは、あらかじめ準備された開発機の中から必要な分をすぐに利用できる仕組みで、開発機を制御するためのCI用PC環境も同時に用意される。これらは物理的な作業なしで利用開始が可能な設計となっている。 思い立ったらすぐに利用できるように、WebUIも用意された。「利用開始までの手続きが煩雑になってしまうと、そこでスピード感が失われてしまう」と廣瀬氏は指摘する。それゆえ、セルフサービスによる無人対応を重視し、必要な人が必要な分だけ利用できるようにしたという。こうして「開発機クラウド」によって、開発機の追加が迅速に行えるようになった。 プロジェクト内で生まれ、成長したサービスである「開発機クラウド」は、任天堂社内の他のプロジェクトにも利用が広がったという。プロジェクト間での開発機の再利用が容易になり、全体的な利用効率が向上したと廣瀬氏は話す。 「開発機クラウド」が共通で使用できるインフラ基盤として、さまざまなプロジェクトに広がった理由として、廣瀬氏は「全社共通となりうるものだとしても、独立して作らなかったことが広く受け入れられた一因」と分析している。 このように、スクラビルドの組み合わせチェック作業を現実的な負荷にするための準備として、スクラビルドの撮影活動があり、さらにその撮影活動は、画像掲示板や開発機クラウドをはじめとした、ゲーム開発を支援するサービスという「準備のための準備」によって実現したのだった。 講演の最後には藤林氏が再び登壇し、スクラビルド実現までの道のりを改めて振り返った。スクラビルドを発案する側は問題解決という準備を行い、同時にゲーム開発インフラ側はチェックの効率化を準備した。しかし、これらを有効に運用するために、その裏側でさらなる「準備のための準備」が行われていた。 発案する側は、ゲーム開発インフラ側が準備したものを活用して「チーム文化の形成」を、ゲーム開発インフラ側も、発案する側と綿密に連携しつつ「ゲーム開発を支えるサービス」の用意という、両者が「準備のための準備」を行っていたのだった。 最後に藤林氏は、今回紹介した手法やインフラの概念、やり方、運用手法などが、今後の皆さんのゲーム開発の一助になることを願うと述べ、講演を締めくくった。