【ITニュース解説】Optimizing the Ever-Growing Balance in the War Robots Project

War Robotsプロジェクトでは、ゲームの長期運営に伴い「バランス」と呼ばれる設定データが肥大化し、様々な問題を引き起こしていた。この問題への対応は、多くのITプロジェクトで直面するデータ管理と最適化の課題を理解する良い事例となる。

まず、「バランス」とは何かを初心者向けに解説する。これは、ゲーム内のロボットや武器の性能、価格、マップ情報など、ゲームの挙動を制御するための多岐にわたる設定情報の集合を指す。War Robotsのように11年間も運営されている大規模なゲームでは、95種類のロボット、175種類の武器など膨大なコンテンツが追加されてきたため、それらに関する「バランス」データも膨大になるのは自然なことだ。

War Robotsのプロジェクトでは、ゲームを大きく「メタゲーム」と「コアゲームプレイ」の二つに分けて考えている。「メタゲーム」とは、アイテムの購入やアップグレード、イベント参加といった、直接的な戦闘以外のゲーム活動を指す。一方「コアゲームプレイ」とは、ロボット同士のバトルなど、ゲームの中心となる繰り返しの行動のことである。これら二つに加え、期間限定で特殊なルールが適用される「Skirmishモード」も存在するため、合計で4種類の「バランス」データが存在することになる。

これらの「バランス」データがどれほど巨大になったかというと、プレイヤーがダウンロードする必要のあるデータ量は、一回の更新で44.6MBにも達していた。これは、スマートフォンゲームのデータとしてはかなり大きい部類に入る。War Robotsは3億人もの登録ユーザーを抱え、毎月470万人がプレイする大規模なゲームであるため、このデータ量を全プレイヤーに配信するコスト、つまり「コンテンツ配信ネットワーク（CDN）」にかかる費用も膨大になる。さらに、プレイヤーにとっても大きなデータを毎回ダウンロードするのは手間であり、ユーザー体験を損ねる要因にもなりかねない。

この問題に対処するため、プロジェクトチームはまず、何がデータの大部分を占めているのかを特定する必要があった。手作業で膨大なデータを調べるのは非現実的であるため、彼らは分析ツールを開発した。このツールは、データ構造を解析する「リフレクション」という技術を使い、各データ型がどれくらいのスペースを使っているかを自動で集計した。分析の結果、特に「文字列」が圧倒的に多くのスペースを消費していることが判明した。さらに調査を進めると、多くの文字列が何度も重複して使われていることが分かった。中には数万回も繰り返されている文字列もあったという。これがデータ肥大化の最大の原因だったのだ。

問題が特定された後、次は解決策の実行に移った。文字列そのものをなくすことはできない。なぜなら、ローカライズキー（ゲーム内のテキストを多言語に対応させるための識別子）や各種IDなど、文字列はゲームの動作に不可欠だからだ。そこで彼らが取った方法は、「文字列の重複をなくす」ことだった。

具体的なアプローチはシンプルだが効果的だ。まず、各「バランス」データに含まれるすべてのユニークな文字列を集め、それを「StringStorage」という専用の保存領域にリストとしてまとめる。そして、元のデータ構造では、文字列そのものを直接持つ代わりに、その文字列が「StringStorage」内のどこにあるかを示す「インデックス」（番号）を持つように変更したのだ。例えば、以前は「Id」という文字列を直接持っていたフィールドが、最適化後には「Id」という文字列がStringStorageの何番目にあるかを示す「StringIdx」という整数値を持つようになった。これにより、データ構造の中では文字列の代わりに小さな整数値だけが伝送されることになり、データサイズを劇的に削減できた。

さらに彼らは、データをシリアライズ（データ構造を通信や保存に適した形式に変換すること）およびデシリアライズ（その逆）するための「MessagePack」というプロトコルの見直しも行った。「MessagePack」は、データをコンパクトに送受信するための形式で、JSONよりも効率的だとされている。当初はJSONのように文字列をキーとして使っていたが、これを数値キーに変更することで、さらにデータサイズを削減した。また、空のリストや配列などの「コレクション」は、何もデータがないにもかかわらず存在を示す情報が伝送されてしまうため、これらを「null値」として扱うように変更することで、無駄なデータを送らないようにした。

これらの変更をゲームに導入する際には、「トグル」という仕組みを採用した。これは、新しい機能を有効にしたり無効にしたりできるスイッチのようなもので、問題が発生した場合にすぐに以前の状態に戻せるようにするためのものだ。また、新しい最適化された「バランス」データと、従来の「バランス」データが、内容的には完全に一致することを確認する必要があった。そのためには、膨大な数の「単体テスト」を作成し、両バージョンのデータを比較検証した。最初は各フィールドを一つずつ比較していたが、これは効率が悪く、バランスデータが少しでも変更されるとテストも修正しなければならないという問題があった。そこで彼らは、再び「リフレクション」の技術を応用し、データ構造のフィールド数、名前、値を自動的に比較する汎用的なテストツールを開発した。これにより、テスト作成の手間を大幅に削減し、開発効率を向上させた。

これらの最適化努力の結果は目覚ましかった。まず、ネットワーク経由で送信されるファイルのサイズは80%以上も削減された。これにより、プレイヤーはより小さなデータをダウンロードするだけで済むようになり、プロジェクト側もCDNにかかるコストを大幅に削減できた。また、クライアント側での「デシリアライズ」時間（受け取ったデータをゲームが使える形式に変換する時間）も短縮され、ゲーム起動時などの待ち時間が減った。さらに、ゲームが実行中に必要とするメモリ量も削減され、全体的なパフォーマンス向上につながった。

このプロジェクトが教えてくれる重要な教訓は、データを扱う際には、何を送信し、何を送信しないかに細心の注意を払うべきだということだ。特に、文字列のようなデータは重複が多くなりがちであり、これをユニークなストレージに集約し、インデックスで参照するようにするアプローチは非常に効果的である。これは、ゲーム内の価格やステータスなど、他の繰り返し発生するデータにも応用できる考え方だ。このようなデータの最適化は、単にファイルサイズを小さくするだけでなく、コスト削減やユーザー体験の向上にも直結する、システムエンジニアにとって非常に重要なスキルと視点であることを示している。