2020年9月2日～4日まで、CEDEC公式サイトのオンライン上にて開催された日本最大のコンピュータエンターテインメント開発者向けのカンファレンス“CEDEC 2020”。開催3日目となる9月4日、『リングフィット アドベンチャー』を手掛けた任天堂・企画制作部の稲葉翔氏が登壇し、同作向けに開発されたログ収集ツールの制作過程とその活用法を説明した。

　稲葉氏たちは、『リングフィット アドベンチャー』の制作に際して、ゲーム制作用のログを大量に呼び出せる“printf（プリントエフ）”に着目。このC言語を用いて収集したデータを効率よく分析することが、ゲーム開発を円滑に進めるためのカギであると考えた。

　そこで、“ゲーム開発のためのprintf”をツールとして独自に制作。本作の開発環境の向上に大きく貢献したのだ。今回の講演では、その“ゲーム開発のためのprintf”をどのように制作し、いかに活用していったのか説明がなされたのでリポートしていこう。

　なお、稲葉氏は講演に先立ち、「言葉の定義として、printf自体はC言語におけるログ出力のメソッドですが、本日のお話は特定の開発言語に依存しない内容になっています。その都度“ログ出力のメソッド”と呼ぶのも回りくどいので、このセッションではたんにprintfと呼ばせていただきます」と前置きしていた。本稿もこの前提に沿って、printfという用語を使用していくので了承願いたい。

　また記者は、ゲームのプログラミングに関する知識が極めて乏しい。実態にそぐわない表現や、用語の使いかたが異なる記述が存在する可能性があるので、それも踏まえたうえで読み進めてほしい。

遺物ともいうべきprintfに特大の利用価値が

　そもそもprintfは、実行中のプログラムの内部状態を確認したり、デバッグを進めるときなどに用いられるもの。「とくに気になる部分にprintfを仕込んでデバッグする手法を、“printfデバッグ”と呼ぶことが多い」と、稲葉氏。

　ところが、ゲーム開発者にとってprintfは、「いまさら？」と感じるくらいネガティブなイメージを感じさせるものらしい。初歩的あるいは原始的と思う人もいれば、古臭さや泥臭さを連想する人も多いようだ。実際に稲葉氏も「私が生まれる前から存在するメソッドですから、古代の遺物と思ってしまうのもうなずけます」と述べ、そのように考える人たちに同情的だった。

　とはいえ、開発現場でprintfを用いたデバッグを行ったことがある人は「きっと多いはず」。稲葉氏の話によると、ゲーム画面に描画する必要がなかったり、そもそも誰でも使えるものであったりすることから、いまでもprintf自体の需要はあるようなのだ。

　しかしながら、大規模タイトルの開発現場ではあまりにも膨大なログを扱うため、printfはやや扱いづらい。そこで開発環境班のリーダーである稲葉氏は、新規IPである『リングフィット アドベンチャー』はゲームとしてのノウハウが今後継続的に蓄積されていくだろうと考え、printfのやりかたそのものを作り直すことにしたのだ。

　具体的に何を成そうとしたのかというと、開発者がログを直接読み込む手間を省くべく、専用の収集ツールを作成。ゲームとスタッフのあいだを繋ぐ架け橋を設けたのだ。

　だが先述の通り、本作でその役割を担うためには、ログの大規模化に対応しうる性能が求められる。それらの課題をどのように解決していったのだろうか。まずは稲葉氏らスタッフによる、ログの大規模化を実現するための取り組みから見ていこう。

ログの大規模化への対応

　大規模プロジェクトのスタッフが存分にログを出力できるようにするためには、ログの大規模化への対応が不可欠。稲葉氏は、それをクリアーするための条件として3つの課題を挙げたうえで、それぞれの解決法を述べていった。

課題1 読みづらさの解消

ビューワを制作。収集した大量のログをカテゴリー別に分け、さらにそれを階層化することで手軽にデータを閲覧できるようにした。

課題2 処理コストの軽減

ゲーム内の負荷を高めがちな処理を、PCの側へ逃がすことでコストを軽減。

課題3 データサイズの削減

ファイルを圧縮することで対応。

　上記の3条件をまとめてクリアーするべく、稲葉氏たちは専用のツールを開発。データのやり取りを行いやすく、かつ見やすくした結果、開発スタッフのログに対する見かたがガラリと変わったのだ。

　以前は「ログが多すぎるので減らしてほしい」とデータの多さを嘆く内部の意見が目立ったが、現在は「みんながログを出してくれたので、バグの調査がしやすいです」とログの増大を歓迎する声がかなり増えたとのこと。

　実際、これまでバグを再現し、デバッガーを動員するなどして数時間かけて調べていたような案件が、ログのチェックだけで解決するケースが増加したという。稲葉氏によれば「ときには数分で終わるケースも」というほど劇的な効率化が図られた。

　その稲葉氏ご自身も「ログを減らしてほしいという従来の意見が、ログをどんどん出そうという方向に変わった」と周囲の変化ぶりを実感。「こうしたケースを積み重ねることで、最終的にゲームの質の向上に貢献できたと感じています」と胸を張った。

大量のデータを正しく分析するために

　データの大量収集・分析が可能になったことで、デバッグやバランス調整の効率が大幅にアップ。『リングフィット アドベンチャー』に関して一例を挙げると、フィットネスで得られたポイントと、ゲーム的な要素として排出されたポイントの双方が比較可能になったことで、バランス調整の判断材料が増えたりした。

　このツールは、デバッグやQA（Quality Assuranceの略。品質保証）にも活用されている。たとえば、特定の機能が何日間で合計何回利用されたのかをグラフで表示できるので、極端な数値の変動からトラブルや課題の有無を浮き上がらせられる。しかも、チーム内のすべてのスタッフの実行回数が集計されているため、そのデータの信頼度は極めて高い。

　では、このログ分析の機能はどのようにして実装されたのだろうか。下の画像が示す通り、先述のログ収集ツールを分析対象（ゲーム）とデータベースのあいだに配置することで、最下流に存在する分析ツールがそれを参照できるようにした。要は、ゲームのログをスムーズにデータベースに乗せられるよう、ツールを中間に置いたのだ。

　ポイントとして稲葉氏は、分析の対象となるログの構造に着目。一般的なテキストログはさまざまなフォーマットで書かれているため、個々の開発者の読みやすさは確保されているものの、データベースなどでは扱いにくい。

　そこで、フォーマットを統一するための仕組みとして、構造化ログを導入。「あらかじめ決められた方式でデータを受け渡します」と決めておくことで、データのやり取りを容易にした。

　もうひとつのポイントとして同氏が挙げたのが、ログの流れの構築。先ほど説明した通り、集められたログはゲーム、ロギングツール、データベース、分析ツールの順番で受け渡されていくのだが、これら4つの流れを階層化することで、目的に応じた使い分けを可能にした。

　合わせて、データ収集ツールからビューワの機能を分離し、ログ中継ツールとして独立。そのうえで、ログ中継ツールの中でログの抽出、加工、出力を行う、ETLと呼ばれるシステムを構築した。

　これにより、バグの発見やゲームバランスの調整はもちろん、プレイ時間の累計や処理落ちの頻度も一覧で確認できるように。自動的にまとめられた各データをそれぞれの担当者が分析することで、ゲームのさらなるクオリティーアップが図られたという。

新たなツールの力で「ログが資産に」！

　稲葉氏たちが開発したツールは、『リングフィット アドベンチャー』のデータ収集や分析だけでなく、そのほかの目的にも活用できる。実際、同作のチーム内で使われたログ収集ツールは任天堂の社内でも共有されているとのこと。

　またネットワークを使うタイプのタイトルであれば、このツールを用いて通信の送信側と受信側を横並びで確認することもできるとか。通信データ量の分析も可能なので、稲葉氏いわく「どこかのタイミングで通信データ量が増えすぎているのではないか」といった調査も行える。

　稲葉氏は、今回紹介した取り組みを通じて「ツールの力によってログが資産になった」と説明。また「開発中のログには、ノウハウが詰まっていると考えています。フィードバックが終わった時点でログを消してしまうのは、開発時のノウハウを残せていないことになるのではないでしょうか」とも述べ、膨大なログの中にこそ宝が隠されている点を強調した。

　この日の講演で発表された内容は以上の通り。現役プログラマー向けの歯ごたえ満点のセッションだったが、見逃しがちな部分にこそ本当の価値が秘められているという稲葉氏の指摘は、ゲーム開発以外の仕事にも活かせる点があるように感じた。ここまで読んでくれた読者たちの身の周りにも、ちょっとした工夫で拾い上げられる貴重なニーズや情報があるのではないだろうか。もしそれに気づいたら、printfというキーワードを思い出してみるといいかもしれない。