「ゼルダの伝説　ティアーズ オブ ザ キングダム」のスクラビルドはいかにして生まれたか。そこには“準備のための準備”があった［CEDEC 2024］

　ゲーム開発者会議のCEDEC 2024で，任天堂の藤林秀麿氏と廣瀬賢一氏によるセッション「『ゼルダの伝説　ティアーズ オブ ザ キングダム』のスクラビルドができるまで 〜準備のために準備する〜」が行われた。


　「ゼルダの伝説　ティアーズ オブ ザ キングダム」（以下，ゼルダの伝説 TotK）の大きな特徴となっている「スクラビルド」は，武器をはじめとした装備に別の素材をくっつけ，性能を強化するもの。それを実現するため，藤林氏と廣瀬氏が行ったさまざまな作業が紹介されたセッションをレポートしよう。

藤林秀麿氏（左），廣瀬賢一氏（右）

　ゲームボーイカラーの時代から「ゼルダの伝説」に携わってきた藤林氏は「ゼルダの伝説 TotK」のディレクターで，スクラビルドの発案者でもある。
　廣瀬氏は，ゲーム開発インフラチームのリードエンジニアとして同作に携わった。ゲーム開発インフラチームは，開発で利用する使用するサービス（主にブラウザで利用するWebアプリ）を整備し，開発をより便利に効率良くするのが仕事となる。

スクラビルドの面白さと問題

　まず藤林氏が，スクラビルドの「くっつける遊び」を発案した経緯を紹介した。
　もともとのアイデアは，前作「ゼルダの伝説　ブレス オブ ザ ワイルド」（以下，ゼルダの伝説 BotW）の開発にあった。藤林氏が「鉄格子の向こうにあるスイッチを槍でつついてオンにする」という仕掛けを作ったときに，「もっと遠くにスイッチがあり，槍を2本つなげて届かせる遊びができたら面白い」と感じたことにあるという。
　また，同作の「オクタ風船」（オブジェクトにくっつけると宙に浮かべることができる）にも，「何かをくっつける遊び」としてポテンシャルを感じていたそうだ。

　そう感じた理由は，「ゼルダの伝説 BotW」から続くゼルダの開発テーマに「面白いことが起きる仕組みを作る」があったからだという。藤林氏は，ゲームの中に面白いことが起きそうな仕組みを作っておくと，それらが掛け合わされて思いもよらないことが起こり，新しい体験を生み出せると語った。

「起伏のある地形」と「丸い岩」だけでも，穴に入れたり，敵にぶつけたり，人を驚かせたりと，さまざまな遊びが生まれる

　このテーマを「ゼルダの伝説 TotK」でさらに発展させるために考えたのがスクラビルドというわけだ。藤林氏は，この発想をどう形にしていったのかの紹介に移ったが，ここで「ゼルダの伝説とはどんなゲームなのでしょうか？」という根本的な問いを投げかけ，自身としては「推理して実行して結果を楽しむゲーム」だと思っていると語った。


　「ゼルダの伝説 BotW」「ゼルダの伝説 TotK」では，「たき火の向こうにある木箱に向かって矢を放てば，途中で矢に火がついて刺さった木箱が燃える」「木を切れば丸太になり，それを押して川に浮かべ，流れに乗って下れる」といったことが可能だが，これを藤林氏は「こうなるんじゃないかと推理してやった結果でゲームが進む」と表現した。そしてこれこそが“ゼルダの遊び”であり，この工程が豊かなほど面白くなる構造を持っているという。

この説明は，「ゼルダの伝説 BotW」開発中に行われた遊びの検証時の映像を用いて行われた

　そのため藤林氏は「ゼルダの伝説 TotK」でも，「推理と実行」のターンでできることの幅を，プレイヤーの自由な発想で広げることを目的に，スクラビルドのくっつける遊びを突き詰めていった。

　まずは武器に何かをくっつけるところから検証を始めた。カボチャ畑で槍を振り回すと切っ先にカボチャがくっついて破壊力が上がる，同じく槍の先に蜂の巣をくっつければそこから蜂が出てきて敵を攻撃する，盾の左右に剣をくっつけ，背負って歩くと周囲の草を刈れる……といったことができることが分かり，藤林氏は，推理の幅が想像した通りに広がりそうだと確信を持った。そして，スクラビルドの本質が見えてきたという。

　それは「絵が機能を表す」，見た目が機能を説明している必要があるということだった。棒に岩がくっついたら，いかにも破壊力が上がりそう，といった感じだ。
　くっつけると元のものとはまったく違った見た目に変化する選択肢もあったが，プレイヤーに想像や推理をしてもらうためには，A＋B＝Cではなく，A＋B＝ABの形がいいと判断したという。


　手応えを感じた藤林氏は，ここから「3つ4つくっつけたら，さらに面白くなるのでは」とアイデアを膨らませたが，当然ながら組み合わせの数が膨大になるため，ほかのスタッフからの問題提起があった。

　エンジニアからは「くっつけた場合，元の武器の効能がいっぺんに発動するのか？」，アーティストからは「どんな見た目になるのか？　不具合のチェックが莫大な数になるがどうやるのか？」，ゲームデザイナーからは「武器の名前が膨大な数になるけどどうするの？」といった具合で，チーム内に「無理では？」といった空気が渦巻き始めたという。


　藤林氏は，集まった聴衆に向けて「こういう空気によく遭遇されることがあったのではないでしょうか」と呼びかけると，「ここで落ち着かないといけません」と語った。この段階ではスクラビルドの仕様が検証段階でふわっとしているため，スタッフが膨大な数の組み合わせを漠然と問題視するのは仕方がないという。

　そこで行なわれたのが「問題の分解」だ。仕様を明確にするため，「こういうものがあったらいいな」という希望願望の類を「ウィッシュリスト」，不可欠な仕様を「プランリスト」に入れて分解した。

　この時点でのウィッシュリストには，「ボスボコブリンの笛を剣につけて振ると，その音色でボコブリンを操れる」「盾に翼のゾナウギアをつけると空を滑空できる」といったものがあったという。
　一方のプランリストは「絵が機能を表す」「なんでもくっつけられる」「素材は複数個つけられる」「素材は自由な場所につけられる」といった内容だ。


　ウィッシュリストは必須の条件ではないので，いったん保留扱いになり，まずはプランリストの項目で，問題の根源である「膨大な数」についてのさらなる分解にとりかかることになった。

　藤林氏としては，「素材は複数個つけられる」に，槍を3本4本とつなげて遠くから攻撃する，「素材は自由な場所につけられる」に，素材をつける角度によって違いを生むといった狙いを持っていたが，検証を進めてみると「槍を3本4本つなげると扱いづらくなる」「複数の種類の素材をつけると見た目から機能を想像しづらい」「見た目が機能を表すという点で，角度はあまり意味がない」といったことが分かり，ここについては修正が行われた。

角度については，むしろ固定したほうが機能が分かりやすくなるケースもあると気付いたそうだ

　一方で，「なんでもくっつけられる」については，推理実行を地でいく仕組みであると改めて確信したとのこと。また，武器の名前については「名前も機能を表す」ことが分かりやすいと気づき，元の武器の段階から機能を表す名前とすることをプランリストに追加することとなった。

　この結果をもとに，藤林氏は「やらないこと」を決めた。具体的には「“2つ以上のくっつけ”はやらない」「“つく場所が自在”はやらない」「“名前を一つ一つユニークに”はやらない」。もちろんこれだけではないが，大きなもとのしてはこの3つだったという。

プランリストが絞られた段階でウィッシュリストの見直しも行われ，翼＋盾は当初と異なる効果で実装された

　プランリストが更新されたことで，エンジニアは「2つ以上のくっつけをしないのであれば，なんとかなる」，ゲームデザイナーは「一定のルールに沿って名前をつければいけるのでは」といったように，スタッフの見解も変わった。

　とはいえ，新たな条件でも組み合わせは12万通りとなるため，とくにアーティストが行う見た目や名前をチェックする作業の負担は大きくなることが予想された。

「12万通り」問題の解決

　ここで廣瀬氏が登壇し，この「12万通り」の問題解決のため，ゲーム開発インフラチームが行った作業を紹介した。

　スクラビルドによって生まれる武器のチェック項目としては，主に見た目と名前がある。下の画像のように，剣と岩をくっつけたときは，剣の上に岩がのるのではなく，剣が岩に刺さったような形にする必要がある。

　また，名前については前述のように一定のルールを設けているものの，それが足りないと見た目と名前が合っていないものが発生してしまう。


　こういったところはアーティストやテスターをはじめとした担当者が目でチェックするしかない。また，一度チェックすれば終わりではなく，プロジェクトにおける重要な時期には全体的なチェックが行われ，元となる武器や素材に変更があればスクラビルド後のほうも再度確認する必要がある。つまりチェックの回数は12万どころではない。

　こうなると組み合わせの数を減らしてしまいたくなるが，廣瀬氏は「妥協して減らしてしまったら面白くなくなってしまいます」と断言。また，チェックのコストが高くなると，ブラッシュアップを躊躇することも出てくると指摘し，チェックの負担を減らすことが非常に重要だと話した。

　こういったチェックを行う場合，通常は開発機で起動したゲーム内でスクラビルドを行い，カメラを回して見た目を確認し，最後にポーチ画面で名前を確認という流れになる。だが，これで12万通りのチェックを行うと時間と手間がかかり過ぎるのは，誰もが分かることだろう。

　そこで廣瀬氏は，スクラビルド後の見た目を撮影した画像をWebブラウザで確認できる仕組みを考えた。これならゲームを起動せずにチェックできるというわけだ。

多面展開図やポーチ画面など，アイテムごとにまとめられた複数の画像を確認できる

　もちろん，画像が並んでいるだけではチェックしづらいので，「画像掲示板」によって整理することにした。さまざまな条件での絞り込みが可能で，一覧から画像をクリックすると詳細画面に飛び，気になる部分を見つけたなら，そこから修正のタスクを発行できる。
　また，ゲーム内で確認したい場合のために，画像掲示板からワンクリックで直接ゲーム上に生成できる機能も用意した。


　撮影の日付を履歴として残すようにしたおかげで，問題が発見されたときに「いつから発生していたのか」もすぐ分かったとのこと。この「いつ問題が起こったのか」の調査は，開発において大きな負担となるため，それを解消できたことは非常に大きかったという。

　この画像掲示板によって，チェック作業は現実的な負荷に落ち着いた。するとプロジェクト内で評判が広がり，防具や風による揺れの挙動の確認といったところでも活用されるようになったという。

準備のための準備はチーム文化の形成

　ここで再び藤林氏が登壇。さきほど話したスクラビルドの仕様作成に必要だった準備作業には，「チーム文化の形成」というさらなる準備，つまり「準備のための準備」が必要だったとし，そこにゲーム開発インフラチームが作った掲示板の仕組みが役立ったことを明かした。

　藤林氏は，スクラビルドを実装するために，チームメンバーが目指すところを共通の認識としてしっかり持つこと，つきつめると何を是とし，何を非とするのかというルールや認識合わせ，共通の辞書作りのようなものが必要だと語った。それがチーム文化だ。


　その形成に掲示板が役立ったのだが，その説明に移る前に藤林氏は「ゼルダの伝説 TotK」の制作フローを示した。それが下の画像となる。


　新たな仕様やシステムの内容説明が行われてメンバーがそれを理解し，実際に作って実装し，マイルストーンごとにメンバー全員がプレイして，そこで出された情報を集約し，主要メンバーが精査して，その改善策がメンバーに展開される……という流れを繰り返すことになる。

　そして，「チーム文化の形成」は，この開発サイクルをうまく回すために必要で，とくに「マイルプレイ」「情報の集約」「精査」では，膨大な情報の収集や整理を行うため，効率化が求められた。

　そこで使われたのが掲示板のシステムとなる。マイルプレイ中のメンバーが感じたことをリアルタイムで書き込む場所として，もともとあった掲示板に独自のカスタマイズを加えて作られた。


　投稿には，通し番号や投稿者名に加えて「よかった/気になった」の印象欄，具体的な内容を書き込むコメント欄，投稿者以外のメンバーがその内容に同意したときに押す「そうだね！」ボタン，リーダーたちが投稿内容を精査した結果を書き込む方針欄などが設けられている。「そうだね！」の数は「ゼルダの伝説」の世界で使われる通貨「ルピー」で表されるため，「ルピー掲示板」と呼ばれるようになった。


　これにより，同じような情報が複数のメンバーから出されて重複することが減り，どのような経緯で結論が出たのかをチームメンバー全員がダイレクトに把握できるようになったため，透明性や納得度も高くなって，開発サイクルがより円滑に回るようになったという。

　ただ，コメントが書き込める掲示板だけに，使い方を間違うとトラブルを招き，開発の進捗を阻害する危険性もある。そこで，掲示板の利用には以下のルールが定められた。


●意見ではなく情報を書く

　藤林氏によると，これが最も重要なルールとのこと。「トゲを食らってゲームオーバーになりました。理不尽です」では意見だが，「トゲを食らってゲームオーバーになるのは理不尽に感じた。右から見た時はトゲが見えていたのに，左からの時はトゲが見えず不意打ちになったから」と書けば情報になる。つまりは改良の手がかりがあるかないか，というところだ。



●認識が変わったら追記

　「最初は難しいと思っていたが，プレイを進めるうちに面白くなってきた」ということは，ゲーマーなら経験したことがあるだろう。プレイする中で印象が変わることは多々あるが，最初の段階で書いた情報をそのままにしておくと精度が低くなってしまうため，アップデートが必要になる。また，追記によって投稿者の思考の変遷も分かり，ゲームデザイナーが難度調整を行ううえで非常に有効だったとのこと。



●議論はやらないこととする

　掲示板には他人の投稿にコメントする機能が用意されていたが，そこでの議論は行わず，同じ事象に対して感じた別の情報は別途投稿することとされた。藤林氏は，議論がダメなのではなく，新しく情報として投稿する形の方がチーム文化の形成の促進につながると考えたそうだ。


　ルピー掲示板を3つのルールで運営したことにより，メンバー間での意識が統一されてチーム文化の形成が進み，開発サイクルがうまく回せるようになったという。

ルピー掲示板で「スクラビルドに必要な手順が多く使いにくい」という投稿があったことで担当者が奮起し，手順が圧縮されたとのこと

開発インフラチームにも準備のための準備があった

　廣瀬氏のゲーム開発インフラチームでも，準備のための準備があった。具体的には，画像掲示板をはじめとしたサービスを支えるものだ。

　ゲーム開発では悩み事や新たにやりたいことが多々発生するので，ゲーム開発インフラチームではそういった要望に応え，より便利に効率化していきたいが，直接解決するには限界があるとも感じているとのこと。
　そこで，「ゼルダの伝説 TotK」と同じように，開発者が自由に発明できる仕組みを作ることにしたという。


　その1つが，「データ収集分析」のシステムだ。これはもともとエンジニアから「バグの内容を分析したい」という相談を受けて用意したもので，開発機から出力されるエラー情報を投稿すると，よく起こるバグが一覧できるなど，エラー状況を可視化できる。


　仕組み自体はエラー情報に限ったものではないので，これがさまざまな場所で活用されるようになった。スケジュール管理担当者はタスクの進捗情報を入れてプロジェクトの進捗状況分析やタスクの完了時期予測を行う，最適化の担当者は，舞台となるハイラル各地での負荷データを入れて，ヒートマップを作るといった感じだ。このように，担当者ごとの新たな使い方が生まれ，利用の幅は広がっているという。

こういったサービスでは安定稼働が重要になるため，サーバーが数台停止しても問題なく稼働し，メンバーの数が増えて負荷が大きくなったら自動でサーバーの台数が増える仕組みが整えられている

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

　そんな中で成長したサービスに「開発機クラウド」がある。これはあらかじめ準備されている開発機の中から，必要な分をすぐに利用できる仕組みで，開発機を制御するための環境も同時に用意される。


　以前は「開発機が必要」という要望が寄せられると，開発機だけでなく制御用のPCを用意し，配線して初期設定……といった手間がかかっていたが，「開発機クラウド」によって，思い立ったらWebブラウザからすぐに利用手続きが行えるようになった。


　前述したように，画像掲示板はスクラビルドだけでなく，さまざまな用途で使われるようになったのだが，その対応には開発機クラウドが大いに役立ったとのこと。
　この仕組みは「ゼルダの伝説 TotK」以外のプロジェクトチームでも利用されるようになったが，開発機の“受け渡し”ボタン1つでスムーズに行える。物理的に用意しているときは返却も大変な作業になっていたが，それも不要になって，使われずに放置されている開発機も減ったそうだ。


　セッションの最後には再度藤林氏が登壇し，スクラビルドチームとゲーム開発インフラチームの双方に「準備のための準備」があったことに改めて触れたうえで，「今日お話ししたことは、スクラビルドができるまでのすべてではありませんが，効果を発揮した手法やインフラの概念や運用手法などは応用していただけるかと思います」とまとめた。

4Gamer「CEDEC 2024」記事一覧

「ゼルダの伝説　ティアーズ オブ ザ キングダム」公式サイト