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