『ゼルダの伝説 ティアーズ オブ ザ キングダム』のスクラビルドができるまで ～準備のために準備する～｜CEDEC2024レポート

CEDEC2024が8月21日～23日に開催されました。
楽屋でまったりでは様々なセッションのレポートをお送りいたします。
今回は『ゼルダの伝説　ティアーズ オブ ザ キングダム』に登場するスクラビルドの発想と課題解決プロセスについてのセッションをご紹介いたします。

『ゼルダの伝説　ティアーズ オブ ザ キングダム』のスクラビルドができるまで　～準備のために準備する～

受講スキル

1. ゲームデザインに興味がある方
2. 開発環境・ツール・インフラ基盤に興味がある方
3. QAに興味がある方

得られる知見

1. ゲームデザインとエンジニアリング両面から見た、新しいアイデアを形にするまでのプロセスの一例。

『ゼルダの伝説　ティアーズ オブ ザ キングダム』

「スクラビルド」発想の原点

『ゼルダの伝説 ティアーズ オブ ザ キングダム』の「スクラビルド」とは、武器や盾、弓に1つの素材を付けることで、別の効果を得られる能力のことです。

ディレクターの藤林さんの発想の原点は、前作『ゼルダの伝説 ブレス オブ ザ ワイルド』の祠のプロトタイプ制作中にあったとのことです。鉄格子の向こう側にあるスイッチを槍で突いてオンにするというアイデアから始まり、「もし槍を2本繋げて、さらに遠くのスイッチに届かせたら面白いのでは？」という発想に至ったそうです。

また、「オクタ風船」は、オブジェクトにくっつけて何かを浮かせる仕組みで、遊びの幅を広げるために実装されました。「何かをくっつける」という遊びには、非常に高いポテンシャルを感じていたとのことです。

ゲーム内にその仕組みを組み込むことで、プレイヤーが思いもよらない新しい体験を生み出せると考えたそうです。その発想をさらに発展させたのが『ゼルダの伝説 ティアーズ オブ ザ キングダム』で登場した「スクラビルド」だそうです。

藤林さんは、『ゼルダの伝説』の本質は推理し、実行し、その結果を楽しむゲームだと考えているそうです。

矢に火がつけば箱が燃え、拾った木の枝にも火がついて木に着火できる。草も燃やせるし、木を切れば丸太になり、それを押すこともできる。プレイヤーが「こうなるのでは？」と推理し、実際に試すことでゲームが進んでいきます。

『ゼルダの伝説』はこの試行錯誤が豊かであればあるほど楽しめるゲーム。新作を作るにあたっては、推理と実行の幅を広げ、プレイヤーの自由な発想をさらに引き出すことで、より豊かで楽しい『ゼルダの伝説』を目指されました。そうして生まれたのが、「スクラビルド」の「くっつける」というアイデアです。

スクラビルドの仕様作成に向けた問題解決

スクラビルドは作った物の見た目が機能を説明している必要があるということ。棒と岩をくっつけると破壊力のありそうな武器が出来上がるんじゃないか。推理・実行・結果を楽しんでもらうためには、結果が想像できるものでなければならないと考えたそうです。

くっつけたものが別のものになるという選択肢も検討されました。しかし、この仕様では結果を事前に想像することが難しく、推理する楽しさが失われてしまいます。2つのものをくっつけて形状が変わり、パワーアップするというアイデアが悪いわけではありませんが、今回のスクラビルドの遊びには適しておらず、プレイヤーが結果を想像・推理できるようにしたいと考えたそうです。

組み合わせが膨大になることで生じた問題についてお話しいただきました。

各セクションからの問題提起は次の通りです。

• エンジニアセクション: 武器が元々持っている効能が、くっつけることでどう変わるのか？くっつけた物の効果が一度に発動するのか？
• アーティストセクション: くっつけて新しい武器を作った場合、その見た目に不具合がないかをチェックする作業が膨大になるが、どう対応するのか？
• サウンドデザイナーセクション: 武器を振った時や特殊な効果が発動した時など、さまざまなシチュエーションで必要な音が膨大な組み合わせに対してどう付けるのか？
• ゲームデザイナーセクション: 膨大な数の武器に対して、どのように名前を付けるのか？

数が膨大なために実現が難しいのではないかという漠然とした不安がチーム関係者の間に広がり始めたそうです。この段階では、問題が漠然と認識されている状態でした。そもそもスクラビルドの仕様自体がまだ検証段階で、明確に固まっていなかったためです。そんな中、無理ではないかという空気に流されないよう、ある作業が行われたそうです。

まず、漠然とした仕様を「こういうのがあったらいいな」という希望や願望、そして不可欠な仕様に分ける作業から始めたそうです。

• ウィッシュリスト
  • 見た目から挙動が想像でき、方向性は良かったものの、推理するには発想が飛躍しすぎているため、いったんウィッシュリストに移すもの。
• プランリスト
  • 絵が機能を表す
  • なんでもくっつけられる
  • 素材は複数個つけられる
  • 素材は自由な場所にくっつけられる

2つの項目に分けた結果、ウィッシュリストは必須の条件ではないため、優先作業から外されました。残ったプランリストの中で、「数が膨大になる問題」の詳細な分析が行われます。各セクションから提起された問題に焦点を当て、さらに具体的に分解していきました。

実際に試してみることで、それぞれの良し悪しが明確になり、ルールを絞り込むことができたそうです。解決への糸口が見えてきたため、次のステップに進まれます。

分解検証を通じて、やらないことを決めたそうです。もちろん、現実にはこれだけではありませんが、ルールとしては次の3つとのことです。

• 「2つ以上のくっつけ」はやらない
• 「つく場所が自在」はやらない
• 「名前を1つ1つユニークに」はやらない

ここまでシンプルに絞り込めたのは、問題を細かく分解できたからとのこと。そして、やらないことをプランリストに反映させると下記の画像のようになります。

上記の2つは変わらず、基本のコンセプトも維持されています。素材をくっつける場所は固定し、企画を絞ったわけではなく、この方が『ゼルダの伝説』らしい推理と実行が可能だと判断されました。名前に関しても重要なプラン項目として追加されています。プランリストが確定したタイミングで、ウィッシュリストから条件に合ったものが再検討され、採用されたものもあります。

• エンジニアセクション: 2つ以上の素材をくっつけないのであれば、数は限られるため対応可能。
• アーティストセクション: 無限ではないなら対応は可能だが、根本的な数の問題は解決しておらず、問題は残る。新しい条件でも組み合わせは12万通りある。
• サウンドデザイナーセクション: 一定のルールが確立されるのであれば対応可能。
• ゲームデザイナーセクション: プランリストに「名前も機能を表す」が追加されたことで、一定のルールに沿って名前を付けることができれば問題は解決するのではないか。

当初の「無理では？」という漠然とした不安は、問題を分解して検証し、対処方法を考えたことで和らいできました。デザイナーセクションの「12万通りの不具合チェック」という大きな問題は依然として残っていますが、それを含めたやり方を模索することで「いけそう！」という感触が得られたそうです。解決のカギは、ゲーム開発インフラの活用にあります。

ゲーム開発インフラ（廣瀬さん）

プランリストに基づき、見た目の不具合チェックさえクリアできれば、スクラビルドの実現が可能だと分かりました。見た目の不具合チェックには、くっつき方がおかしいという問題や、見た目と名前が一致しないという問題があります。

組み合わせは12万通りあり、その面白さは検証済みなので、妥協して組み合わせを減らすとゲームの魅力が損なわれてしまいます。そこで、ゲーム開発インフラチームとQAチームが連携して対応することになったそうです。

アーティストは武器やアイテムの制作後、その結果を確認する必要があります。例えば、岩を作った場合には、見た目が破綻していないか、めり込んでいないか、変更後の結果を適宜確認します。また、テスターはプロジェクトの重要なマイルストーン時に全体的なチェックを実施し、製品の品質を確保できる状態でピックアップした形で対応します。

チェックが頻繁に行われるため、確認サイクルを素早く回すことが重要です。確認作業は手間がかかり、確認コストも発生します。ブラッシュアップの内容がコストに見合うかを判断する必要があり、変更に対する躊躇が生じることがあります。場合によっては変更を取りやめる可能性もあり、面白さの追求が十分にできなくなるかもしれません。

そこでスクラビルド後の画像を予め撮影し、「撮影済み画像」を用意。

ゲームをプレイすることなく、画像を見るだけでチェックを完了させ、時間を短縮できます。しかし、フォルダに画像があるだけではチェックが大変です。そこで、「画像掲示板」を使って整理することになったそうです。

絞り込みもできて、詳細画面から画像を確認することができる。

気になる点があれば、直接タスクを発行することも可能です。手順が複雑だと後回しにされることがあるため、手軽にタスクを作成できることが重要だと考えられたそうです。

画像掲示板からワンクリックでゲーム内に生成できる機能が用意されました。

画像掲示板とゲーム画面が連動し、ゲーム内で直接必要なアイテムを生成できるようになりました。これにより、チェック中に撮影画像で情報が不十分と感じた場合でも、ワンクリックで実際のゲーム画面上でアイテムを確認できます。

この機能により、スクラビルドの確認コストが軽減され、12万通りの組み合わせチェックも現実的な負荷に抑えられました。スクラビルド以外の目視確認が必要な作業にも効果を発揮し、プロジェクト内で評判が広がり、新たな依頼が増えたそうです。さらに、プレイヤーの防具や画像掲示板に動画も投稿できるため、風による揺れの挙動などの確認も容易になりました。

ディレクターの藤林さんが分解した結果、見た目の不具合チェックは撮影画像を用いることで現実的な負荷に落ち着きました。

しかし、ゲーム開発インフラの役割は、発案された課題を解決するだけでなく、その仕組みを活用して新たな発案を行うこともあるとのことです。

ゲーム開発インフラ側の準備をゲームデザイナーが利用した実例

スクラビルドの実装を具体的に進める段階では、関係するチームメンバーに様々な情報を共有し、浸透させる必要がありました。プランリストを中心に、チーム全体がスクラビルドの目指す方向を共通の認識として持つことが重要です。コンセプトやプランの内容を明確にし、共通の理解を築くための「辞書作り」のようなプロセスが求められました。

チーム文化の形成は開発サイクルを円滑に回すために必要であり、効率化できる箇所がないかを検討されました。その中で、ゲーム開発インフラチームが作成した掲示板が重要な役割を果たしました。

• 「意見」ではなく「情報」を書く
• 認識が変わったら追記
• 議論は「やらないこと」

改良の手がかりがあるかどうかを見極めるためには、どの部分に何を感じ、もし異なる状況だったらどう感じたかを書くことが有効です。これにより、焦点を絞りやすくなります。情報が不足していると投稿者に質問する必要があり、双方の時間が無駄になることがあります。感情を情報に変換することも重要なポイントでした。投稿者が気になる事象について分析して書くことで、自分たちが作っているゲームに対する理解が深まるという利点があったとのことです。

モニター情報として非常に役立ったとのことです。投稿者が最初に「難しい」と感じたことを投稿していましたが、プレイを続けるうちにその感覚が変わることがあったそうです。そのため、初期の書き込みだけでは情報の精度が低くなってしまうため、追記を行うことで投稿者の思考の変遷を把握できるようになったとのことです。この方法は、ゲームバランスの調整やレベルデザインに特に有効だったと述べていました。

ルピー掲示板では、他人の投稿に追記することはできるものの、コメント欄での議論は行わない方針が取られていたそうです。もし同じ事象に対して異なる意見があれば、それは別途投稿するようにしていたとのことです。議論を避ける理由は、単に議論がダメだというわけではなく、個々の感じたことを新たな情報として投稿することが、チーム文化の形成を促進すると考えられたためです。

この運用ルールによって、ルピー掲示板はゲームをより面白くするための情報が集まり、開発サイクルを効率的に回すツールとなったとのことでした。

ゲーム開発を支えるサービスについて

ゲーム開発時には多くの困りごとや悩みが発生しますが、ゲーム開発インフラチームが直接解決できる範囲には限界があります。そこで、ゲームと同じ考え方で課題解決の仕組みを用意することにしたそうです。『ゼルダの伝説 ティアーズ オブ ザ キングダム』では「面白いことが起きる仕組みを作る」という考え方に基づいてゲームデザインがされています。プレイヤーが自由な発想で進めることができるようになっています。これと同様に、ゲーム開発インフラでも「開発者が自由に発明できる仕組みを作る」という方法で対応することにしたとのことです。

エンジニアから「バグの内容を分析したい」という相談を受けたゲーム開発インフラチームは、「データ収集／分析の仕組み」を用意しました。エンジニアは開発機から出力されるエラー情報を投稿するようになり、その結果、よく起こるバグの一覧が明らかになりました。

この「データ収集／分析の仕組み」は広範な情報収集が可能で、さまざまな担当者が新しい使い方を発明し、別の用途が次々と生まれたとのことです。例えば、スケジュール管理担当者は「プロジェクトの進捗度合いを確認したい」と考え、タスクの進捗情報を「データ収集／分析の仕組み」に入力して、タスクの進捗をグラフ化し分析する仕組みを作りました。これにより、タスク数の分析や期限までにタスクが完了するかの予測分析が可能になったとのことです。

まとめ

スクラビルドの実現に向けて、まず発案側はスクラビルドの「くっつける」機能の発案だけでなく、事前にスクラビルドに関する問題解決の準備を進めました。一方、ゲーム開発インフラチームはチェックの効率化に向けた準備を行い、スクラビルドの実装に向けたサポートを整えました。

これらの準備を有効に運用するために、発案側はゲーム開発インフラ側が準備した仕組みを活用し、チーム内の文化形成という準備のための準備を、ゲーム開発インフラ側もゲーム開発側と綿密に連携しつつ、ゲーム開発を支えるサービスの用意という準備のための準備をされていました。

今回のセッションでは、スクラビルドの完成に至る過程で特に効果を発揮した運用についてお話しいただきました。

ご登壇者

藤林 秀麿さん

任天堂株式会社
企画制作部『ゼルダの伝説　ティアーズ オブ ザ キングダム』 ディレクター

<講演者プロフィール>

「ゼルダの伝説」シリーズの開発に主にディレクターとして従事してきました。
『ゼルダの伝説　ティアーズ オブ ザ キングダム』でもディレクターを担当。

<受講者へのメッセージ>

2017年の講演に引き続き、制作にあたってチャレンジした実例と明日から使える耳よりな話を紹介できればと思っています。

廣瀬 賢一さん

任天堂株式会社
企画制作部『ゼルダの伝説　ティアーズ オブ ザ キングダム』　ゲーム開発インフラ担当

<講演者プロフィール>

ゲーム開発用のツールやサービスの開発、およびそれらを動かすためのインフラ基盤の構築を担当しています。
『ゼルダの伝説　ティアーズ オブ ザ キングダム』ではゲーム開発インフラのリードを担当。

<受講者へのメッセージ>

今作で直面した課題をゲーム開発インフラとしてどの様に対応していったかを紹介できればと思います。
ゲーム内の遊びを実現する為の課題解決事例の一つとして、何かのお役に立てれば幸いです。

こちらの記事もチェック！

▼ゲームクリエイターズギルド LINEはこちら