『ベヨネッタ2』開発を陰から支えたオートプレイ機能とパフォーマンス計測 CEDEC＋KYUSHU2016

「仕事をしたくないでござる、コードを書きたくないでござる」。実は優秀なプログラマーに必須の資質だ。画面を点描で埋め尽くせと言われて、素直にマウスをクリックし続けるのがアーティスト。スクリプトを組んで作業を自動化するのがプログラマーだともいえる。

プラチナゲームズでQAエンジニアをつとめる森田和則氏も、「プログラムを極力書きたくないのでプログラムを必死に書き続ける」のだという。CEDEC2016で行った「『ベヨネッタ2』におけるゲーム品質を上げる為の自動化～オートプレイと継続的なパフォーマンス計測～」も、そうした森田氏ならでなの思想に裏打ちされたセッション。聴講者から高い評価を受け、「CEDEC＋KYUSHU2016」でも招待講演が行われた。

なお本セッションの講演資料はCEDECの資料サイト「CEDIL」で公開されている。CEDILはメールアドレスを登録すれば誰でも無料で活用できるので、ぜひ本記事で関心が高まれば、こちらもチェックしてみて欲しい。

オートプレイでデバッグ作業を効率化

はじめに森田氏の講演をまるっとまとめると、「継続周回プレイなど人間が手作業で行うには単調すぎるバグチェックをオートプレイで自動化すると共に、CPUやメモリなどのパフォーマンスを計測して記録し、デバッグに役立てる」というものだ。もっとも講演で強調されたのは、これだけでデバッグは完結しないということ。『ベヨネッタ2』でもデバッグ会社との協業で品質管理が行われた。その中で「機械にできることは機械に任せよう」と、作業が切り出されたわけだ。

前半パートで説明されたのが「オートプレイの実装」だ。デバッグでは、およそ人間が考えつくあらゆる特殊なプレイが試される。その一つが「延々と周回プレイを行う」というもので、実際にメモリ解放などの処理が甘いと、致命的なバグを引き起こす。この手のデバッグで厄介なのは、一度バグが発生すると、再現度とデバッグ完了の確認も必要になるということだ。この手の単純作業を機械化したいという欲求は、プログラマーならずとも覚えるのではないだろうか。

森田氏も「『ベヨネッタ1』のデバッグで、通しプレイのチェックとバグ再現チェックを、眠気を抑えつつ続けることに違和感を覚えて、『2』でオートプレイ機能を作ることにした」と語った。実装に要した時間は、本業のかたわらで2～3週間ほど。開発終了まであわせると、全体で3人月程度とのことだ。本機能はタイトルを越えて使用できるように汎用性をもたせてあり、費用対コストは総じて高かったといえるだろう。

オートプレイの考え方は比較的シンプルで、はじめにゲーム内ツールから3D空間（マップ上）にコーン（位置情報）を配置していく。次に各コーンで主人公（ベヨネッタ）に行わせたいアクションを割り振っていく。アクションには移動・攻撃・ループ処理などがあり、アクションゲージが溜まったら、状況に応じて特殊攻撃なども自動で繰り出せる。これを最後まで延々と繰り返して設定し、実行するだけだ。いわばバッチ処理などの考え方に近いだろう。

戦闘中の挙動については、『ベヨネッタ2』で搭載された「イージーオートマチック」機能がベースとなった。アクションゲーム初心者でもボタン連打で楽に敵を倒せる仕組みで、これをもとに思考ルーチンを加えたという。もっとも、「AIというほど高度なものでもない。ゲームごとに様々な実装方法があるはず」という。それでも効果は絶大で、森田氏は何十周も連続プレイした結果、致命的なバグが見つかったこともあったとあかした。

一方で実装に一番頭をひねったのがループ処理だった。前述の通り、特定のシチュエーションでバグが発生した場合、それを何度も再現するのは面倒だ。そこでループ処理が必要になるが、特定コーンに設定されたアクションだけでなく、コーンを複数またいだループ設定になると、実装が複雑になる。「リセット処理のタイミングに3日ほど悩んだ結果、風呂場で閃いた」（森田氏）。ほかにスクリーンショットの撮影やファイル読み込みといった、デバッグに役立つ機能も盛り込んでいる。

ちなみにアイテムの初取得画面や、チュートリアルなどの操作説明の一枚絵が表示されたら「問答無用でAボタンを連打」。QTE系が出たら「問答無用でアイコンに応じたボタンを実行」。ただしカットシーンやムービーはスキップせずに再生させたという。再生時のみに発生するレアなバグなどが紛れ込む恐れがあるからだ。これらは社内でのデバッグでは「ついスキップしがちで、バグが見過ごされがち」なところ。こういった点も確認できるのが機械に任せるメリットだとされた。

また、いわゆる「1フレーム問題」の発見にも有効だという。画面上にUIが表示されるとき、画面の切り替わりのタイミングなど、実際は表示されていないが、入力受付が可能なタイミングがある。この時に偶然、特定のボタンが押されると、エラーが発生することもあるという。このように人間の目では視認できない状況でも、機械なら即座に対応できる。オートプレイを活用することで、こうしたトラブルも未然に対処できた。

なお、移動に際して「主人公（ベヨネッタ）に目的地に向かえというコードは書かなかった」という。別のゲーム開発にも対応できるようにするためだ。そのため「俯瞰視点のカメラから主人公を見下ろし、次のコーンの位置を逆計算してパッドの移動入力を行う」やり方が採用された。その上で、実装が大変ならコーン間をワープで移動させるのもアリとのこと。これをベースとしつつ、ビーストウィズインの水中におけるヘビの操作など、タイトル固有の移動モードも追加されている。

このほか、ナビゲーションメッシュ（キャラクターが移動可能な経路など、マップ情報を簡潔に記述した情報のこと。経路探索などに使用される）を活用したコーンの自動配置機能も組み込まれた。もっとも、最後は手作業での修正が必要になった。前述の通り「オートクリアではなく、決められた行動を繰り返させることで、安定性と再現性を高める」ことが目的だったからだ。そのため地形情報が確定するまではナビゲーションメッシュを使用し、後半から手作業で調整していったという。

計測結果を「共有」させるために必要なこと

後半パートではパフォーマンス計測の工夫が明かされた。ゲーム制作では開発中に処理落ちやメモリ不足などのエラーが頻発する。そのためCPU・GPU・メモリなどの利用状況を計測し、データベース化しておけば、デバッグや最適化処理が容易になる。『ベヨネッタ2』の開発においても、GPU負荷に関連する処理（影・背景物・VFXなど）について、オンオフの差分で負荷を計測、メモリ状況を分類してダンプする、などが構築された。

もっとも森田氏は「データベースといいつつ、実際は毎日XMLデータに保存して、サーバに格納しているだけ」と明かした。なまじデータベースを構築すると、メンテナンスコストが必要になるからだ。開発ではその都度、必要なデータがあればいいわけで、過去のデータと比較検証する必要性もそれほど高くない。そのため、必要に応じてXMLデータにアクセスし、JavaScriptライブラリのjQueruyとグラフ作成プラグインのjqPlotを使用して、ブラウザ上で表示する仕組みが作られた。

むしろ重要だったのは、計測データの活用方法だった。開発チームにデータを参照するように通達しても、参照頻度が低かったのだ。「どこそこにデータがあるといっても、言われた方も忙しい。データの見方や保存場所がわからない人もいた」（森田氏）。ポイントは「データの見える化」を推進して、開発チームが毎日見たくなるようなページを作ること。そして、サイトの閲覧を開発サイクルに埋め込むことだった。

そのため、処理負荷の改善結果が全員で共有できる仕組みが作られた。実装が終わると役職に関係なく、開発チーム全員が集まって処理負荷のワースト10ポイントを発表。数値を全員で確認した上で、対策に効果がありそうな箇所を抽出し、必要な作業をタスク化。実装が終わった時点で、全員で再び結果を共有し……というサイクルを恒例行事にしたのだ。そのためグラフの表示なども、あえてアニメーション効果を加えて、視覚面で訴えかける内容にしたという。

森田氏は「オートクリア機能もパフォーマンス計測も、難しい技術が使われているわけではないので、ぜひ各社で工夫して実装して欲しい」いう。実際、バグチェック・パフォーマンス計測・処理負荷の改善は、いずれも時間がかかる作業だ。そのため調査・確認に必要な時間を短縮すれば、より開発効率が向上し、ゲームの完成度が高まるという。人と機械で作業の切り分けをして、結果を共有することが、何よりも重要だと言うわけだ。

「すべてはおもしろいゲームをユーザーに届けるためです」と語る森田氏。日々の開発業務で忙しいかもしれないが、できるところから手をつけて、少しずつ成果を積み上げて欲しいと呼びかけた。