自動でプレイするオートプレイシステムを作成
2016年8月24日〜26日の3日間、パシフィコ横浜で開催された、日本最大級のコンピュータエンターテインメント開発者向けカンファレンス“CEDEC 2016”。3日目に開催されたセッション「『ベヨネッタ2』におけるゲーム品質を上げる為の自動化 〜オートプレイと継続的なパフォーマンス計測〜」のリポートをお届けしよう。
本セッションで講演を行うのは、プラチナゲームズ 開発本部 技術戦略グループ QAエンジニアの森田和則氏。森田氏が『ベヨネッタ2』開発中に実装したオートプレイと、パフォーマンス計測について紹介する内容だ。ちなみにこのオートプレイは、“Bayonetta2 開発ブログ”にて以前に紹介されていたもの（参考⇒https://www.platinumgames.co.jp/dev-bayonetta2/article/881（⇒こちら））。本公演では、より詳細な解説が行われた。では、さっそく見ていこう。
まず、ここでいうオートプレイとは、「ゲーム内で自動操作を行い、くり返し何かを行う機能」のこと。デバッグ目的であるから、パッドを操作したように実行する仕組みで動作している。
そもそも森田氏がオートプレイを思いついたのは、前作『BAYONETTA（ベヨネッタ）』の開発終盤。「最初から最後まで通しでクリアーできるかのチェックプレイ、特定条件下で発生するバグを確認するため同じ行動を何度もくり返す、という作業に疑問を覚えた」ことがきっかけだそうだ。
というわけで、『ベヨネッタ2』開発時にシステムを作成し、実装。ほかの仕事と平行しつつ2〜3週間でベースを作成したそうで、最終的な開発コストは「3人月ほどになるのでは」と森田氏。
オートプレイシステムの実績は、なんと40周連続で通しプレイを実現。しかも40周でストップしたわけではなく、「たしか三連休前の夜に設定し、連休後に出社したら40周ほどクリアーした状態だった」とのことだ。バグチェック中は古いビルドで検証を続けても意味がないため、そのときは40周で打ち切ったそうだ。
続いて、実装方法の紹介。ゲーム内ツールから位置情報を持つコーンを設置して、そのコーンには、行いたいアクションを設定できるようにする。すると、主人公がコーンでアクションを行い、実行し終わったらつぎのコーンへ移る、という流れになる。これをくり返して、ゲームを最後までクリアーできるように設定していくそうだ。
コーンで行えるアクションは、移動やワープ、戦闘終了待ち、ループといった内容。またデバッグ系のアクションとして、スクリーンショット撮影やメモリダンプ、オブジェクト生成なども実装した。
まず移動についてだが、コーンの位置情報を参照して移動する。具体的には、真上から見た状態でつぎのコーンの方向を調べ、そちらに向かってパッドの信号を入力する、という仕組みだそうだ。目的地へ向かうというコードを書くわけではないが、「だいたいこれでいける」と森田氏。「無理だった場合は、向きを変えたときにカメラリセットアクションを入れる」そうだ。
ループアクションは、指定した回数をくり返すように作成。たとえば何度か殴ると壊れる壁があり、そこを通るギミックの場合。“壁が壊れたかどうかを判断する”ような機能は実装せず、パンチを行う回数をなんとなく設定して対処するそうだ。
この“なんとなく”設定は、ゲームスタート時やキャラクター選択時、難度設定時などでも有効。たとえばゲームスタート時は、「STARTボタンを押してからなんとなく3秒くらい待って、Aボタンを押すように設定」するとのこと。たとえばキャラクター選択画面になったときか、アクションシーンに移行した、という判断プログラムを作成せずにオートプレイを実現しているわけだが、その理由は「それで十分！」と森田氏。たとえ開発が進んでUIが変更されても、デメリットはオートプレイが動かなくなるだけ。「そのとき改めて設定し直せばいい」（森田氏）。
ただし、不特定のタイミングで現れるメニュー画面、たとえば初めてアイテムを獲得したときの画面や、チュートリアルの操作説明画面の場合は、この方法では対処できない。そのため、こちらは“メニュー画面が表示されているか判断する仕組み”をUI担当者に作成してもらったそうだ。
アイテム画面が出ないようにするデバッグ機能もあったそうだが、「そちらを行ったのでは（デバッグする）意味がない」とのこと。ユーザーと同じ環境でテストプレイを続けることに意味があるわけだ。
またオートプレイは、特定のタイミングで発生するバグの、“特定のタイミング”がいつなのかを調べるのにも威力を発揮。たとえばイベントシーンが終わったフレーム（『ベヨネッタ2』は60フレーム動作のため、1/60秒）でのみボタンを押すと、発生するバグがあった場合。手動で再現を狙うのは大変だが、オートプレイはフレーム単位で入力のタイミングを指定できるため、毎回確実に再現できる。そのため、発生条件が厳しいバグなども対処しやすい。
戦闘に関しては、『ベヨネッタ2』にはボタン連打だけで戦闘をほとんど行ってくれる“イージー・オートマチック”モードがあるため、そちらを活用。ゲージが溜まったときは、状況に応じて“トーチャーアタック”や“魔力解放”といった特殊アクションを行うよう、設定したそうだ。このようなバトルアシスト機能がない作品の場合は、バトル時に敵を全滅させるデバッグコマンドを実行するなど、何かしらの対応策を見つければいいと森田氏。
ムービーシーンは逆に、スキップはしない設定にしたそうだ。これは、人間によるテストプレイのとき、どうしても開発中盤以降はムービーをスキップしてしまうため、“スキップしない”チェックが減ってしまうことが理由。スキップするチェックは人間のテストプレイに任せて、スキップしないほうをオートプレイに任せよう、という狙いだ。
また、異なるタイプのゲームで実装するときのアドバイスも。たとえばオープンワールドタイプのゲームでは、サブクエストだけをやり続けるオートプレイ、メインクエストだけを行い続けるオートプレイをやっておくといいそうだ。「オートプレイの目的はクリアーではなく、同じ行動をくり返して、その間に発生するバグをなくすこと」と森田氏。
パフォーマンス情報をWebブラウザで視覚的に表示
続いて、パフォーマンス計測について言及。開発中はCPUやGPU、メモリー不足、ゲーム内エラーが頻発するため、それをデータベース化して修正を容易にしよう、というのが狙いだそうだ。
このようなチェックは各社で当然行っていると思われるが、専用ツールでチェックできるのは、プログラマーなど一部の人間に限られ、アーティストなどはなかなかチェックできない。そもそも、データを見て、と言っても見てくれない、見かたがわかない場合は、「“見える化”していないことが原因」と森田氏。
そこで、Webブラウザで表示されるシステムを作成し、使用メモリー量や表示ポリゴン数の変化を、視覚的に判別できるシステムを作成したそうだ。開発終盤では、各セクションのスタッフを集め、こちらのデータを元に、パフォーマンスが悪い部分をどうやって解決するか相談しあうなど、開発に役だったとのこと。
ちなみにこのページを実装したとき、グラフが視覚的に動くのがうっとうしい、という意見が上がったそうだ。だが、このような意見を上げたのは、もとからこのようなデータをしっかりとチェックしてくれている人。普段チェックしないアーティストなどは、ページを開いた瞬間にグラフが伸びていくことで喜びを感じ、先日の修正が反映されるワクワク感で、楽しく見てくれたとのこと。
まとめとして、今回紹介したツールはどちらも難しい技術ではないので、各社で作成して実装することを推奨し、その結果を開発者かユーザーに戻して欲しいと語った。
森田氏は「このようなツールを使うことで、調査や確認の時間を減らすことができ、クリエイティブなことに使える時間が増えるはずです。すべては、おもしろいゲームをユーザーに届けるため！」と締めくくり、盛況のうちにセッションは幕を閉じた。
テストプレイは大変だが、ユーザーとしては、フリーズはあってはならないバグ。今回の講演を通じて、世の中から少しでもバグが減ることを願いたい。
