『ゼルダの伝説ティアキン』スクラビルドは組み合わせが膨大すぎて開発チームもお手上げ？やらないものを決定しても12万通りの組み合わせが存在【CEDEC2024】

2024.08.23 16:35

更新

　2024年8月21日（水）から23日（金）にかけて開催されている、日本最大のコンピュータエンターテインメント開発者向けカンファレンス“CEDEC2024（Computer Entertainment Developers Conference 2024）”。本稿では、22日に開催されたセッション“『ゼルダの伝説　ティアーズオブザキングダム』（以下、『ティアキン』）のスクラビルドができるまで～準備のために準備する～”の模様をお届けする。

　講演者は、任天堂株式会社・企画制作部の藤林秀麿氏と廣瀬賢一氏。藤林氏は『ティアキン』でディレクターを、廣瀬氏はゲーム開発インフラチームのリードエンジニアを務めた。

『ゼルダの伝説　ティアーズオブザキングダム』(Switch)の購入はこちら（Amazon）

『ゼルダの伝説　ティアーズオブザキングダム』(Switch)の購入はこちら(楽天)

新しい『ゼルダの伝説』を作る際のテーマは“おもしろいことが起きる仕組みを作ること”

　まずは、ゲーム開発インフラチームの役割について廣瀬氏が紹介。同チームは、ゲーム開発時に使用するサービスやインフラを整備する役割を担当している。ここでのサービスとは、ブラウザから利用するWebアプリのことを指す。

　たとえば、同社のゲーム開発インフラチームが手掛ける画像掲示板もサービスのひとつ。アーティストがアイデア画像を投稿して共有するための仕組みで、Webブラウザから利用している。

　インフラとは、サーバーなどのサービスを動かす受け皿のこと。ゲーム開発インフラチームは、これらをプロジェクト内に広めることで、開発をより便利に、効率よくすることが仕事となる。

　講演では、スクラビルドを発案する側の人としてディレクターの藤林氏、サービスインフラを作る側の人として廣瀬氏が、それぞれセクションを代表して解説。『ティアキン』で登場した新しい遊び“スクラビルド”がどのような発想で生まれたのか、それを実現するためには何が問題だったのか、そしてどのように解決したのかが解説された。

　スクラビルドは、武器や盾、弓に何かひとつの素材をくっつけることで、別の効果を付加できる能力。藤林氏いわく、この能力は、前作『ゼルダの伝説　ブレスオブザワイルド』（以下、『ブレワイ』）でラークアの祠のプロトタイプを制作中にアイデアを発想したという。

　ラークアの祠では、鉄格子の先にあるスイッチを槍で突いてオンにする遊びを制作。このとき、より遠くにスイッチがあり、槍を2本くっつけて届かせるというギミックの解きかたができればおもしろいだろうなと思ったのが最初とのこと。

　『ブレワイ』で登場した、オクタ風船をくっつけて浮かぶことができる要素はその片鱗で、遊びをより豊かにしたいという狙いで実装。これらの経験を通じて、何かをくっつけるという遊びに高いポテンシャルを感じていたそうだ。

　ポテンシャルを感じた理由は、前作から通じて、新しい『ゼルダの伝説』を開発するにあたって、ひとつのテーマがあったから。それは、“おもしろいことが起きる仕組みを作る”というもの。

　これは、ゲームの中で、自然とおもしろいことが起こるような仕組みをたくさん作っておいて、それらが掛け合わさることで、思いもよらないことが起こり、その現象を通じて新しい体験を生み出そうと考えられていたからだ。

　たとえば、物理を導入した世界で、起伏のある地形と丸い岩、そしてそれが入りそうな穴を用意。崖の上に押せそうな岩と、その下に穴をセットする。また、敵がいるところの崖上に岩を設置。歩いている人が見える丘の上にも置いてみる。

　同じ岩を配置しておくだけでも、シチュエーションによってさまざまな現象が発生する。これが、前作から通じて目指した、“おもしろいことが起きる仕組み”とのこと。こういった仕組みをたくさん配置しておけば、新しい『ゼルダの伝説』の遊びが生まれそうだと感じたそう。

　そして、今作でこの仕組みをさらに伸ばすものとして発想したのが、スクラビルドとなる。くっつけることでどうなればおもしろいのか、それを考え、発想をどのように形にしていったのか。藤林氏から、その過程が詳細に語られた。

より豊かで楽しい『ゼルダの伝説』を作るため、スクラビルドのくっつける遊びを追求

　そもそも『ゼルダの伝説』は、推理して、実行して、結果を楽しむゲームだと藤林氏は考えを語る。矢に火をつけて放ち、それが当たった木箱は燃えるし、丸太は切って川に浮かべて流すことで、向こう岸を渡る手段にすることもできる。与えられた状況から推理して、それを実行。結果として行ったことがどのような形であれ、正解であればご褒美がもらえたり、ゲームが進んだりする。これが『ゼルダの伝説』の遊びであるという。

　『ゼルダの伝説』はこの工程が豊かなほどおもしろくなる構造を持っている。それゆえ、新作を作るなら、推理と実行のターンでできることの幅をプレイヤーの自由な発想で広がるようにしておけば、より豊かで楽しい『ゼルダの伝説』ができると思い、スクラビルドのくっつけるというアイデアを突き詰めることにしたそうだ。

　アイデアを形にするにあたって、まずは武器に何かをくっつけることができる能力としてスクラビルドを検証。カボチャ畑で槍を振り回せば、先端にカボチャがくっつき、破壊力が増して木箱が壊せるように。左右に剣がくっついた盾を背負えば、歩いているだけで足元や周囲の草を刈ることができる。蜂の巣を武器にくっつけたら、蜂が敵を襲うことも起きる。

　こういった検証をくり返し、くっつけることで推理の幅は広がりそうだと確信が持てるように。同時に、スクラビルドの本質が見えてきた。それは、“絵が機能を表す”ということだ。

　つまり、スクラビルドは、“作ったものの見た目が機能を説明している必要がある”ということ。木の棒に岩をくっつけたら破壊力のありそうな武器ができるのではないかと想像できるように、推理→実行→結果を楽しむためには、結果を想像できるものであることが重要となる。

　当初は、くっつけた結果、別のものに変化するというパターンも選択肢として存在していたという。しかし、この仕様だと、結果を事前に想像するのが困難なため、推理することも難しい。ふたつのものをくっつけて形状が変化してパワーアップするというアイデアがダメというわけではなく、スクラビルドの遊びに向いていないため、この仕様は見送られた。記号で表すと、A＋B＝Cではなく、A＋B＝ABで絵が機能を表せば、求める遊びができると考えたそうだ。

　となると、つぎはくっつける要素を拡張させ、3つ、4つと複数くっつけるとどうなるのか、たくさんくっつけることができればもっとおもしろいことが起きそうだと、アイデアはどんどん膨らんでいく。

スクラビルドの膨大な組み合わせによる不安を解消するため、“問題を分解”する

　しかし、ここで問題が。それは、組み合わせが膨大になること。無限のような組み合わせが発生するため、スクラビルドの実現に暗雲が立ち込める。

何でもくっつけられると武器の性能はどうするのか
くっつけて新しい武器を作った場合はどのような見た目や名前にするのか
武器を振ったり特殊な効果が発動したりしたときなど、それにどんな音をつけるのか
不具合のチェックが膨大な数になるがどうするのか

　など、各セクションからさまざまな意見が出てきた。

　組み合わせが膨大という問題により、「ムリでは？」という空気がチーム関係者内に渦巻く。各セクションスタッフが膨大な数の組み合わせに対し、漠然と問題視している状態が発生したそうだ。

　しかし、それは「しかたない」と藤林氏。そもそも、スクラビルドの仕様自体がまだ検証段階で、妄想や想像を多分に含んでおり、フワっとした仕様だったからだ。そのため、「ムリでは？」という空気に流されず、本当に実現がムリなのかを知るべく、ある作業を行ったという。

　それは、“問題を分解”すること。スクラビルドのフワッとした仕様を明確にするべく、膨らんだ構想を「こういったものがあったらいいな」という希望・願望と、不可欠な仕様に分類。希望・願望を“ウィッシュリスト”、不可欠な仕様を“プランリスト”と呼ぶことに。

　ここで、ウィッシュリストの一例を紹介。ボスボコブリンの持つ笛の音色で、子分であるボコブリンを操れることに着目し、笛を自分の武器につけて、振って音を鳴らしてボコブリンを操れるようにするアイデアが生まれた。ほかには、ゾナウギアの翼をつけて背負えば空を飛べるというアイデアも存在しており、どちらも絵から挙動が想像できるので方向性としてはよかったが、推理するには少し発想が飛躍しすぎだということで、いったんウィッシュリストに分類されたという。

　プランリストについては、代表的なものとして、絵が機能を表す、なんでもくっつけられる、素材は複数個つけられる、素材は自由な場所にくっつけられるといったものが存在した。

　ふたつに分類してみたところ、ウィッシュリストは必須な条件ではないとして、いったん優先作業から外すことに。そして、残ったプランリストの中で“数が膨大になる問題”の分解を行っていく。

　各セクションからあがってきた問題において“膨大な数”がポイントとなっていたので、さらなる分解においては、そこに焦点を当てることに。同じ武器を複数くっつけてみたり、くっつく角度を変化させてみたり、とにかくたくさんくっつけて、自動でくっついたときの手ごたえなども確認。ほかにも、くっつけたものを変化させるA＋B＝Cタイプの検証を行うなど、数多くの検証を実施した。

　道具以外にも、武器を3本、4本とくっつけることができたら楽しいのかという検証も行ったそうだが、狙いづらい、背中にしまえないという問題があり、2本くっつけたものを2セット作ったほうが有効だったため、2本くっつけるのがちょうどよいという考えに至ったとのことだ。

　また、素材を自由な角度でくっつけることができたら楽しいのではというアイデアについては、角で試した場合、角が真横を向いているから剣を横に振った時に強い、といったような仕様は今作にはないので、角度は意味をなさないために見送られた。

　強い風を起こすことができる葉については、これも武器にくっつけて振れば風が起きそうという推理と、絵が機能を表すということにおいて角度は重要ではなかった。むしろ、適当につけて真っすぐつくほうが絵から推理しやすいのでは、という気づきを得ることができた。

　いろいろな種類のアイテムをくっつけることができたら楽しいのでは、というアイデアの検証では、想像しているときは楽しげだが、どういう形状になるのか結果が想像できず。できあがったものから機能が推理できないため、目指す遊びには向かなかった。

　名前は機能を表すというのはどうか、という点についても検証。これはとてもわかりやすかったので、もともとの名前自体もできるだけ機能を表すように命名することを決めた。

　これらの結果をもとに「やらないことを決めた」と藤林氏。大きなものとして、“ふたつ以上のくっつけ”、“つく場所が自在”、“名前をひとつひとつユニークに”をやらないことに決定する。やらないことをプランリストに反映し、内容の更新も行っていた。その中で、ウィッシュリストから実現できそうなものは再検討して採用。盾に翼をつけるアイデアは、当初とは異なる効果として実装されている。

　プランリストが更新されたことで、エンジニアは「“ふたつ以上のくっつけはしない”なら数が限られるので何とかなる」、サウンドデザイナーは「“ふたつ以上のくっつけはしない”、“つく場所が自在”をしないなら、やりようがある」と、各セクションの意見も変化。

　ただ、新しい条件でも組み合わせが12万通り存在するため、アーティストによる膨大な見た目のチェックに負担がかかるという課題が残った。

12万通り存在する組み合わせの確認コスト削減のため、画像掲示板を利用

　それを解決するために行われたのが、ゲーム開発インフラの利用。ここで廣瀬氏が登壇した。

　12万通りという組み合わせは膨大なものの、見た目のチェックの問題を解決すればスクラビルドは実現可能で、遊びのおもしろさも検証によって明らかとなっているので、組み合わせを減らすことはせず、妥協せずに取り組むことに。その問題解決のため、ゲーム開発インフラチームがQAチームと連携して行った取り組みが紹介された。

　スクラビルドを行った際のチェック項目としては、見た目と名前がある。剣と岩をくっつけるときは、剣の上に岩が乗るのではなく、剣の先に岩がくっつく必要がある。名前については、藤林氏が紹介したように一定のルールで生成されるが、ルールに不足があると見た目と名前が合っていないという問題が発生する。

　これらは、アーティストやテスターが確認する必要ある。その際、岩の形状を変更した場合は岩がめり込んでいないかなど、素材を変更したことによる組み合わせの結果も確認しなければならない。また、プロジェクトの重要な時期ごとに全体的なチェックが何度もくり返されるので、確認のサイクルが素早く回ることも重要となる。

　確認作業はスクラビルドを行い、カメラを回しながら見た目に問題がないか、ポーチ画面を見て名前やアイコンの画像が変ではないかをチェック。1回ならまだしも12万通り存在するので、非常にたいへんな作業となった。

　確認コストが重いと、ブラッシュアップの内容がコストに見合うかどうかを判断する必要になり、場合によっては取り止めになることも。そのため、おもしろさの追求が十分にできなくなってしまう。

　そこで確認の手間を軽減するべく、スクラビルドの画像をあらかじめ撮影し、撮影済みの画像をWebブラウザでチェックできる仕組みを用意。これにより、ゲームをプレイすることなく、画像を見るだけでチェックが行えるようになった。冒頭に紹介された画像掲示板を使用して整理し、条件を指定して絞り込みも可能に。一覧画面から画像をクリックすると、画像の詳細に飛び、そこで気になった部分を修正するタスクも作成できる。加えて、画像掲示板からワンクリックで素材をゲーム上に生成できる機能も搭載した。

　撮影した日付を履歴に残しているため、問題が発生した際に“いつから発生していたか”がひと目でわかる。撮影時のビルド番号も表示されており、原因の特定も容易だ。問題が発覚した際、いつから起きているのかを調査するのはたいへんなので、その手間を解消できたことは非常に大きかったとのこと。

　この画像掲示板の機能によって、スクラビルドの確認コストは軽減し、12万通りのチェック問題は現実的な負荷になった。なお、この画像掲示板はプロジェクト内で評判が広がり、防具や風の揺れの挙動確認などでも利用されている。

チーム文化の形成を行うためにルピー掲示板を利用

　続いて、藤林氏が再び登壇。先ほど紹介されたスクラビルドの仕様作成には、“チーム文化の形成”という準備のための準備も必要となったそうだ。スクラビルドを実装するには、プランリストを中心にチームメンバーがスクラビルドの目指すところを共通の認識として持っている必要がある。どういったものを是とし、何を非とするのかというルールや認識合わせ、いわば共通の辞書作りを行うのが、“チーム文化の形成”とのこと。

　これには、ゲーム開発インフラチームが作成した掲示板が役立ったという。その説明の前に、『ティアキン』の制作フローを紹介。新たな仕様などを説明し、メンバーが理解したうえで実装。マイルストーンごとにメンバー全員でプレイし、情報を収集して、主要メンバーが精査する。改善点をメンバーに共有し、再び同じ制作フローが実施されていく。

　チーム文化の形成は、この開発サイクルを円滑に進めるために必要で、とくにマイルプレイ、情報の集約、精査の効率化が求められた。そこで役だったのが掲示板のシステム。マイルプレイ中にメンバーが感じたことをリアルタイムに投稿し、ほかのメンバーもプレイしながら掲示版をつねに見ておくことをルールに。

　投稿には、通し番号や投稿者欄のほか、よかった点、気になった点を選択できる印象欄、具体的なコメントを書くコメント欄、投稿内容に共感したメンバーが押す“そうだね”ボタン、リーダーが精査した結果を表示する方針欄、プロデューサーやディレクター、各セクションのリーダーが集まり、精査した内容を記載するレビュー欄などがある。“そうだね”の数は『ゼルダの伝説』内の通貨“ルピー”で表示されるため、掲示板の名前もルピー掲示板になったそうだ。

　とくに役立ったのは、レビュー欄だと語る藤林氏。投稿された件について、どういった経緯で結論が出たのかをチームメンバー全員が直接確認できるので、透明性や納得度が高く、伝言ゲームのようなことにもならず、情報を正確に共有、浸透させることができたそうだ。
　
　ただ、コメントが書き込める掲示板という性質上、使いかたを誤れば開発の進行を阻害するトラブルが発生する危険性もある。そのため、掲示板利用時の大きなルールとして、“意見”ではなく“情報”を書く、認識が変わったら追記、議論は“やらないこと”の3つを定めたそうだ。

　“意見”ではなく“情報”を書くことは、もっとも重要なルールとのこと。「トゲを喰らってGAME OVERになりました。理不尽です」という書き込みは意見。「トゲを喰らってGAME OVERになるのは理不尽に感じた。なぜかというと右からはトゲが見えていたのに、左からはトゲが見えず、不意打ちになったから」という書き込みは情報となる。両者の違いは、情報があるかどうか、改良の手がかりが存在するか、という点だ。

　つぎに、認識が変わったら追記することについて。「最初にプレイしたときは難しく感じたが、プレイを続けるうちに慣れてきて楽しめた」と感じた際には、その認識の変化を書き込む。そうすることで、ゲームデザイナーが難易度調整、レベルデザインを行ううえで役立ったそうだ。

　最後に、議論は“やらないこと”。掲示板では、他人の投稿にコメントすることができたが、そこで議論は行わず、同じ事象に対してべつに感じた情報があれば、別途投稿するようにしている。議論することがダメではなく、思うことがあれば新しく情報として投稿したほうが、チーム文化の形成の促進につながると考えたからだそうだ。

　これらのルール運用により、掲示板は純粋にゲームをおもしろくするためだけの情報が集まり、開発サイクルを効率的に回せるツールとなったと藤林氏は振り返った。

開発者が自由に発明できる仕組みを実装し、より効率のよいゲーム開発に

　廣瀬氏の開発インフラチームでも、準備のための準備が行われた。これまで紹介された画像掲示板やルピー掲示板をはじめとするサービスを支えるための取り組みを実施している。

　ゲーム開発では、悩みごとや困りごと、新たにやりたいことが多数発生する。これをどんどん解決してより便利に効率化したいが、直接解決していくのには限度がある。そのため、ゲームがプレイヤーの自由な発想で楽しむことができるように、開発インフラチームも、開発者が自由に発明できる仕組みを作るという方法で対応したそうだ。

　その一例として紹介されたのが、“データ収集/分析”の仕組み。エンジニアからの「バグの内容を分析したい」という相談を受けて実装したもので、開発機から出力されるエラー情報を投稿することで、よく発生するバグが一覧で確認できるようになった。

　“データ収集/分析”の仕組みは、エラー情報だけではなく幅広いデータが格納可能なため、さまざまな担当者により使いかたが発明され、別の用途が順次生まれていったという。

　なお、この仕組みを利用したサービスは安定稼働させることが重要なので、サーバーが数台クラッシュしても問題なく動き、開発メンバーが増えて負荷が大きくなっても、自動的にサーバーの台数を増やして性能が上がるような環境を整えている。

　廣瀬氏は、プロジェクトに役立つものを作ることは、非常に難しいことだと感じているとのこと。ともすると、独りよがりな方向性や仕様になってしまう可能性があるため、できるだけ早い段階で現場投入し、フィードバックを受けながら作り込むことが大事であるという。

　そうした、プロジェクト内で成長したサービスとして、開発機クラウドのシステムが紹介。あらかじめ準備されている開発機の中から、必要なぶんをすぐに利用できるという仕組みで、同時に開発機を制御するためのCI用PC環境も用意。これにより、開発機が追加で必要となった際、すぐに利用手続きが行えるようになった。この手軽さにより、開発機クラウドのシステムは、任天堂社内の幅広いプロジェクトで利用されたとのことだ。

　ここまで紹介されたところで、最後に藤林氏が登壇。改めて、スクラビルドができあがるまでには、アイデアを発案するディレクター側にてチーム内文化の形成、ゲーム開発インフラ側ではゲーム開発を支えるサービスと、それぞれ準備のための準備があったと振り返る。

　そして、「今日お話ししたことは、スクラビルドができるまでのすべてというわけではありませんが、実現のために効果を発揮した手法、インフラ概念や運用方法などは応用していただけるかと思いご紹介いたしました。もし、本日お話させていただいたことが、今後皆さんのゲーム開発の一助になれば幸いです」と締めくくり、セッションは終了した。