グリー<3632>は、8月22日～24日の期間、パシフィコ横浜で開催中の「CEDEC 2018」において、初日（22日）に「オートプレイによる最適なパラメータシミュレーション～自動化時代のゲームフレームワークに求められること～」と題したセッションを行った。
ゲームの運用において、日々リリースされるエネミーやステージなどの新要素のデザイン、パラメータ設定は、ゲームの面白さに直結する重要な仕事の1つと言える。しかし、エントリープレイヤーからヘビープレイヤーまで幅広い層が楽しめるよう適切にデザイン、パラメータ設定を行うことは、熟練のゲームプランナーにとっても容易ではない。
そこで、本セッションでは『ダンまち～メモリア・フレーゼ～』運用チームに導入されている、オートプレイにより最適なパラメータシミュレーションを行う枠組みについて、グリーの尾崎嘉彦氏（開発本部 エンジニア）と細谷伊佐武氏（Wright Flyer Studios事業本部 シニアゲームデザイナー）が紹介。さらに、プロジェクトを通じて認識した自動化時代のゲームフレームワークに求められることについても話が及んだ。
▲尾崎嘉彦氏（左）と細谷伊佐武氏（右）。
『ダンまち～メモリア・フレーゼ～』は1年以上運営しているとのことだが、「運営中の課題はいくつもある」と切り出したのは細谷氏。限られた時間の中で、高い品質でのリリースが求められ続けるわけだが、「どれだけ効率的に低い品質を減らし品質を高めることに時間をかけられるか」が課題とし、本作におけるシミュレータ導入について語っていった。
まず始めに、ステージタイプ（バトルorボス）とステージ難易度に合わせてエネミーをデザインした"ステージバトル"におけるエネミーの検証について。
ステージバトルにおけるエネミー検証では、ステージデザイン（wave数やエネミー配置数、どのようなスキルにするのか）等をデザインしたデータをマスターデータとして設定する。その後、ビルドを経て、開発者ツールでテストプレイ（各ステージごとに適性パーティでテストプレイ）を行う。それを各ステージ毎に何度も実施するわけだが、そのテストプレイが、業務時間の70％を占めてしまい、「いくら熟練した開発者でも時間がかかってしまう」（細谷）という問題に直面していた。
これについて尾崎氏は、"プランナー作業のボトルネックはテストプレイにかかる時間"にあると現状分析しつつ、"ステージバトルのユーザープレイデータは既に膨大に蓄積"されているという点に着目し、「多くのユーザーのプレイデータを活用しない手はない」と、機械学習によるアプローチでテストプレイの高速化を狙った。
パーティやステージ情報の入力、結果を出力とし学習することで、未知の入力に対する結果を予測。実際にプレイせずに結果を得られ、プランナーの負担軽減、劇的な高速化。そしてデータ有効活用のための技術検証とノウハウ蓄積によって、テストプレイの高速化を図った。
しかし、機械学習向きのログ設計や強いドメイン知識が必要だったことや、精度面での不満などの問題点が、やってみてわかった。その結果として、機械学習による予測を用いた高速プレイは検証に止めたという。
機械学習を用いてステージのプレイ結果を得る方針は失敗したが、そこで今度は開発者ツールを改造。自動でプレイを行うシミュレータを開発し、アプローチを試みた。
▲シミュレータによる自動プレイの動画も紹介。
▲シミュレータの実装方針。
結果的に、プランナーが手動でテストする必要がなく、負担は大幅軽減し、シミュレーションを行っている間に別の作業ができるなどのメリットはあったが、ゲーム本体の変更の影響を受ける、Macでしか動作しないといった残る課題点についても触れていた。
また、シミュレータ導入後のパラメータ調整サイクルや、ステージバトルシミュレータへの入力（シミュレーションしたいステージID入力、難易度毎に作成した想定パーティの指定）と出力（負けたパーティに色付けして視覚化することで明らかにおかしなバランスを発見できる）の実例なども紹介された。
シミュレータ導入について、細谷氏は「ステージ難易度に対して想定より強いパーティが負けていたり、ステージに対して想定より弱いパーティで勝っているなど、こういう部分については後程要調査する必要がある」とし、「シミュレータは答えを教えてはくれないが、バランス調整において参考になる」と続けた。
ステージバトルにおけるエネミー検証に付随した話として、自動でコマンド選択してバトルを進めるオートバトルに関する"オートバトルロジックの変更検証"についても触れられた。変更検証フローは、変更前と変更後のステージバトルシミュレータを用意し、それぞれにステージデータとパーティデータでプレイ。そこでバトルの勝敗結果の変化や、バトル勝利時の経過ターン数の変化をチェック。ステージバトルにおけるエネミー検証と共通しているのは、出力に対してどう考えるかが重要であるとのことだ。
続いて、"PvPにおける新キャラ性能検証”（※PvPのみで新キャラ性能を検証しているわけではない）。フローは、キャラ性能デザイン⇒マスターデータ入力⇒ビルド⇒開発者ツールとテストプレイという流れ。これは小さな運要素で勝敗が左右されるため数回繰り返すし、複数種類のトレンドパーティでも同じく繰り返しテストするというものだが、ステージバトル同様テストプレイに時間がかかるが、調整サイクルが可能。
PvPシミュレータへの入力と出力について、出力はピボットテーブルを用いて総当たり戦の勝率をヒートマップで視覚化。全ての対戦相手に対して勝率100％のパーティが存在していないか、パーティ3はパーティ2への対策パーティなので高確率で勝利できているか、などを確認できる。しかし、対戦相手のパーティ設定において、パーティはその時点の環境に依存しているため、毎回作り直しが必要（※新装備追加やキャラの能力上限突破など）。また、冒険者、アシスト、武器・防具など設定項目が膨大で時間がかかるという課題も。
これについて尾崎氏は、検証に必要なパーティのレパートリーが膨大（PvPランキングから有望なパーティ編成を取得可能に）、ユーザーデータ生成には開発者ツールの操作が必要（本作の開発者ツールの操作はGUI前提）と現状分析。
そこで最初に試したのがAppiumでのツール操作。OpenCVで画像認識、Appiumでマウスなどを動かして操作する形を考えたが、"リアルタイム画像認識に使うにはスクリーンキャプチャが遅い"、"シミュレーションを並列化できない"、"UI変更があると画像認識による自動操作は全てがダメになる"などの問題点があるとした。
そこで、CocosConsoleによる操作というアプローチを試してみたところ、"CUIベースにしたことで動作トラブルが劇的に減少"、"マウスカーソル等を使わないため並列化も可能"、"UI変更の影響を一切受けずトータルメンテナンスコストが低い"といった結果が得られたそうだ。
3つ目のケースとして紹介されたのが、"PvBにおけるボス性能の検証"。検証フローは、ボス性能デザイン（想定パーティはひとつに固定）⇒マスターデータ入力⇒ビルド⇒開発者ツールでテストプレイという流れで、最適なコマンド入力でプランナーが手動プレイする必要があった。
ボス性能検証の自動化については、現状シミュレータはインタラクティブな操作に非対応のため、各キャラクターの行動×15ターン分をあらかじめ選択して結果を取得、ベイズ最適化を使って最適な行動を探索、パーティはプランナーが選定した強そうなもので固定といった手法をとった。
最適化前は、回復行動などを行わずにボスにバタバタと倒されていたが、最適化後は、効果的な行動をとるようになったという。しかし、まだまだスコアを伸ばせる行動もあり、そこが考慮されているかどうか突き詰める必要もあるそうだ。
最後に、今回セッションで語られた技術スタックのまとめを公開。尾崎氏は、自動化時代のゲームフレームワークに求められることに対して、「最適な学習機能、最適化や自動操作が機能するために適切なユースケースの設定が、そして自動化時代のゲームフレークワークでは技術フレンドリーな設計が必要です」とまとめた。
また細谷氏は、プランナーに向けて「自動化による出力は意味まで語らないので、その結果からどう考え、対応するかが重要です。独自の品質の上げかたが求められるため、プランナーの仕事が重要になってきます」とコメントした。
■『ダンジョンに出会いを求めるのは間違っているだろうか～メモリア・フレーゼ～』
(c) 大森藤ノ・SBクリエイティブ/ソード・オラトリア製作委員会
(c) Wright Flyer Studios
