つぶやく
本稿で取り上げるのは，ネクソンゲームズ Magnum Studioプログラミング部門エンジンチームのカン・ジャンフン氏による講演だ。氏はレンダリングパイプラインを中心に6年の経験を持つエンジンプログラマーで，現在は同作で使うUnreal Engineの保守・アップグレード，パフォーマンスやグラフィックスクラッシュの対応を担当している。
 |
パフォーマンス問題を再現・分析するには，同じ条件で繰り返しテストし，比較可能なデータを得る環境が必要だ。だがエンジンチームには2つの壁があった。
1つめは組み合わせ爆発。グラフィックスオプションはPS5に7種，XBOX Series X|Sに7種（機種は2つで14），PCは多数あり，絞っても合計約30通り。これをビルドごとに手動テストするのは非現実的だ。
2つめにプラットフォームの制約。PS/XBOXといったコンソールは閉じた環境ゆえ外部の自動化ツールを取り付けにくく，自動化はパッケージされたゲーム自体に組み込むしかなかった。これが設計全体を左右する制約になった。
そこでカン氏が出した結論が，「自分が本業に集中している間，システムにテストを回させる」こと。ボットが実際にゲームをプレイしてパフォーマンスを計測する自動テストツール「M1 APT（Auto Play Test）」である。そして開発を通じて至った核心の設計思想が，「完璧な再現性を追うのではなく，何があっても止まらずデータを集め続けるテストを目指す」ことだった。変数の多いゲームで完全な再現は難しいならば「止まらないこと」を最優先にする，という発想である。
 |
その思想を支えるのが4つのパイプラインだ。
1つめは経路探索。複雑なレベルではNavMeshだけでは限界があるため，3段階のフォールバックを設計した。まず通常のナビゲーション，失敗すれば詰まりやすいエリアのコストを無限大にして迂回させる，それでもダメならZ軸の高さ変化を排除して最も安全な経路を探す。3段階の安全網でも失敗すれば，最後はテレポートさせる。
ただしNavMesh上は通行可能でも，コリジョンで実際には詰まることがある。そこでキャラクターのコンポーネントデータを分析し，「加速度はあるのに，実際の水平移動速度（Velocity）が毎秒10cm未満」という状態で詰まりを検知する。だがスキル使用中や意図的な停止を誤検知しないよう，2つのタイマー（入力はあるが移動速度がない時間／移動しているが目標に近づけていない時間）を毎Tick計測し，両方が同時にしきい値を超えたときだけ「本当に詰まった」と確定してテレポートさせる仕組みにした。
 |
2つめは戦闘。最大で数十〜100体ほどの敵が出現する環境で，毎Tick全方位スキャンするとTickTimeやフレームドロップを招く。そこでカン氏は，モンスターがアグロに従ってプレイヤーへ近づく点に着目。キャッシュが空のときだけ全スキャンを行い，最も近い5体だけをキャッシュ配列に格納，以降は次のTickからその5体だけ距離を更新し，優先度順に並べ替えて攻撃する。これで不要なベクトル走査を排除し，大量の敵やエフェクトが出ていてもフレームドロップなく戦えるようになった。
3つめはミッション種別の判定。ゲーム内データを統合する際，人間が手入力する以上どうしても起きるタイポ（誤字）が単純な文字列比較を壊してしまう。そこでレーベンシュタイン（Levenshtein）距離による類似度マッチングを導入し，編集距離の類似度が75％以上なら同じ種別とみなす。Assassination・Defense・Interactionはいずれも80%以上で通過し，まったく別のSupplyは0%で弾かれる。これで「データが編集されてもボットは止まらず仕事を続けられる」。
4つめは，これら独立したパイプラインを束ねるパイロット（オーケストレーター）だ。グラフィックス設定は，プリセットやレイトレ，13の詳細スケーラビリティ，アップスケーラー，各種テクスチャまでを単一のコマンドラインに収め，Windowsでも同様に対応して組み合わせ爆発の壁を越えた。アーキテクチャは，最上位Actorにオーケストレーターを置き，その下に単一責任の4サブマネージャー（ログイン，メモリプロファイリング，ミッション実行など）を配置。マネージャー間の直接通信を禁じて依存を排除し，テストサイクルごとにデータをリセットするインターフェースで信頼性を担保した。
 |
成果として，繰り返しの再現性データ収集や長時間テストといった「人の時間を食う作業」を吸収できた。一方で限界も率直に語られた。ライティングの不具合や遅延して現れるテキストストリーミングといった視覚的な問題は検知できない。本ツールの主眼は「置き換え（replacement）」であり，退屈なデータ収集はツールに任せ，人はより高次の意思決定に時間を使う，それが正しい自動化のかたちだとした。視覚面の限界に対しては，将来追加され得る3つの選択肢（確定ロードマップではない）も提示された。
結びにカン氏は，本ツール導入後の最大の変化を「データ駆動の最適化体制が確立されたこと」と述べる。だがそれ以上に価値ある学びは「とにかくやってみよう」というマインドセットだったという。「最初は半信半疑だったが，完璧な設計に固執せず擬似コードを書いて走らせ，反復するうちに，気づけばボットが自分でマップを巡りデータを集めていた。新しいシステム導入を考える人にとって，本日共有した試行錯誤が小さな武器になれば」と語り，講演を終えた。
 |
Q&Aでは，ログインやゲーム入場のステップが省かれて見える点を問われ，「ログインもグラフィックオプション同様に条件設定可能にし，フィールドへ即移動するロジックも作った。4つの核心技術に比べ実装が軽微だったため割愛した。テスト環境ではチートで該当地点へ直接飛び，そこから自動化が走る」と回答。QAが自前で自動化する余地については，「QAは通常QAチームが担うが，本ツールは“自分のチームが多忙で個別依頼しきれない”からこそ作った。攻撃パターンなどはクライアントチームの実装を参照しつつ，コストをさらに下げられないかと考えて開発した」と説明した。
