機械学習ベースの自動プレイエージェントを用いたバランス設計効率化の追求

機械学習ベースの自動プレイエージェントを用いた  バランス設計効率化の追求  2019/09/06　福沢嘉琳　森田想平  © 大森藤ノ・SBクリエイティブ/ダンまち2製作委員会  

自己紹介  Karin Fukuzawa  福沢嘉琳    2016年に新卒入社。  アイドル系IPプロダクトにて運用や新規イベントの企画進行を経験し、WFSにて「アナザーエデン」や、「ダンまち〜メモリア・フレーゼ〜」のゲームデザイナーチームのリードを務める。 
  © 大森藤ノ・SBクリエイティブ/ダンまち2製作委員会  

自己紹介  Sohei Morita  森田想平    2009年入社。  データエンジニアとして働いたのち、現在は事業横断部門でデータ基盤 /
AIリサーチ / ビジネスアナリシスを担当するグループのマネージャーを務める。    本プロジェクトではプロジェクトマネジメントと一部の開発を担当。   

本発表の概要  ゲームコンテンツのバランス調整を効率化するために、自動プレイエージェントの導入を検証しているプロジェクトに関して    • 解決したい課題  • 開発検証しているシステムの構成  •
開発プロジェクトはどう進んできたか    をお話します 

本発表でお伝えしたいこと  G D  E N  P M  知見を言語化して伝える  それを 
理解する  プロジェクト全体の進行管理  それを  理解する  システムのロジックを説明する  システムが複雑になりすぎるのを防ぐ  言語化の補強をする 

目次  運用の課題  エージェントの開発/検証  プロジェクトは  どう進んだか  まとめ  ダンメモについて  現状のボスバトルの設計方法とその課題  自動プレイ環境/ルールベースエージェントの構築 
機械学習エージェントの構築  振り返り：GD・ENは何をしたのか  最初の失敗  システム開発の進め方  研究サーベイの進め方  振り返り：PMは何をしたのか 

目次  運用の課題  エージェントの開発/検証  プロジェクトは  どう進んだか  まとめ  15min  20min  15min 

2017年6月19日リリース（おかげさまで2周年！）    「ダンまち」初のスマートフォン向けゲームアプリ    原作者大森藤ノ先生完全監修のストーリー    総ワード数 85,000超の全編フルボイス 
    ダンまち〜メモリア・フレーゼ〜（以降ダンメモ）とは？  © 大森藤ノ・SBクリエイティブ/ダンまち2製作委員会  

自動でコマンド選択してバトルを進めてくれるオート機能  ここをON  シンプルなコマンドバトル  ダンメモのバトルって？  © 大森藤ノ・SBクリエイティブ/ダンまち2製作委員会  

ダンメモのバトルって？  その他、PvPバトルや、レイドイベントなど… ルールの異なるバトルコンテンツが複数存在  通常バトル（低難易度コンテンツ）  ボスバトル（高難易度コンテンツ） © 大森藤ノ・SBクリエイティブ/ダンまち2製作委員会  

ダンメモの運用  限られたリソースの中で          でコンテンツを提供し  お客様に楽しんでいただくこと  高品質  高頻度 

ダンメモの運用  限られたリソースの中でやった結果…      高品質  高頻度  © 大森藤ノ・SBクリエイティブ/ダンまち2製作委員会  

ダンメモの運用  限られたリソースの中でやった結果…  高頻度  高品質  © 大森藤ノ・SBクリエイティブ/ダンまち2製作委員会  

ダンメモの運用  継続的に両立させていくために  ボトルネックは取り除きたい  高品質  高頻度  限られたリソースの中で 

運用の課題  継続的に両立させていくために      バトルのバランス設計  を効率化したい  高品質  高頻度 

ダンメモのバトル  通常バトル（低難易度コンテンツ）  ボスバトル（高難易度コンテンツ） © 大森藤ノ・SBクリエイティブ/ダンまち2製作委員会   バランス設計を行う上で  それぞれの適切なバランス設計の指標を決めたい 

通常バトルの設計  シナリオに付随  世界観を楽しんでもらうためのコンテンツ      通常バトル（低難易度コンテンツ）  想定パーティーを用いてオートでクリア可能  ※想定パーティ = 表記難易度に対して適正な強さのパーティ 
攻略要素が必要など過剰に難しくしない  表記難易度に沿っていればOK  © 大森藤ノ・SBクリエイティブ/ダンまち2製作委員会  

通常バトルの設計〜CEDEC2018にて〜  高速且つ自動でオートプレイを行うシミュレーターを開発したことにより  通常バトルでのテストプレイ工数は大幅に軽減  オートプレイによる最適なパラメータシミュレーション  〜自動化時代のゲームフレームワークに求められること〜

バトルの設計  通常バトル（低難易度コンテンツ）  ボスバトル（高難易度コンテンツ） ?  オートプレイの  シミュレーターにより解決  © 大森藤ノ・SBクリエイティブ/ダンまち2製作委員会  

ボスバトルの設計  難易度：6段階  ターン制限：15ターン      ボスバトル（高難易度コンテンツ）　挑戦難易度  　生存ターン数  　与ダメージ量　  を最大化してハイスコアを取る 
    最適な行動を考える必要があるバトル  © 大森藤ノ・SBクリエイティブ/ダンまち2製作委員会  

ボスバトルでのスコア計算  合計ダメージ  生存ターンボーナス   難易度ボーナス  aaaa  最終スコア = 合計ダメージ ×
(1+生存ターンボーナス) × (1+難易度ボーナス)  覚えなくていいです  © 大森藤ノ・SBクリエイティブ/ダンまち2製作委員会  

　挑戦難易度  　生存ターン数  　与ダメージ量　  を最大化してハイスコアを取る      最適な行動を考える必要があるバトル  ボスバトルの設計  難易度：6段階  ターン制限：15ターン 
    ボスバトル（高難易度コンテンツ） © 大森藤ノ・SBクリエイティブ/ダンまち2製作委員会   想定パーティーを用いて最適行動でハイスコア獲得 

バトルの設計  想定パーティーを用いて  オートでクリア可能  想定パーティーを用いて  最適行動でハイスコア獲得  通常バトル（低難易度コンテンツ）  ボスバトル（高難易度コンテンツ）それぞれの適切なバランス設計の定義  © 大森藤ノ・SBクリエイティブ/ダンまち2製作委員会
 

バトルの設計  通常バトル（低難易度コンテンツ）  ボスバトル（高難易度コンテンツ）今の課題  オートプレイの  シミュレーターにより解決  © 大森藤ノ・SBクリエイティブ/ダンまち2製作委員会  

ボスバトルの設計フロー  ステージ  設計  マスターデータ設定  ビルド  テスト  プレイ  バランス  調整 

ボスバトルの設計フローと課題  ステージ  設計  マスターデータ設定  ビルド  テスト  プレイ  バランス  調整 
主にステージ設計、バランス調整において  ダンメモに詳しい熟練のゲームデザイナーでないと難しい    主にテストプレイにおいて  手動プレイである分、通常バトルよりも膨大な時間がかかる 

①想定パーティの決定  ②敵の基本パラメータの決定  ③ユーザセグメント別のゴール設定 

活躍させたいキャラクターを複数決定    　登場したばかりの新キャラクターの活用  　過去活躍する場面のなかった既存キャラクターを新たに活用  （通常バトルではキャラクターに関わらずレベル帯だけ一致していればOKだった）          ステージ設計
①想定パーティの決定  新しい遊びの提供  継続的なキャラクター育成欲求の形成    今回はこのあたりがいい   © 大森藤ノ・SBクリエイティブ/ダンまち2製作委員会  

活躍させたいキャラクターを複数決定    ステージ設計 ①想定パーティの決定  そのキャラクターを用いて  ハイスコアが出せるパーティを作る  ※パーティは一例です   ©
大森藤ノ・SBクリエイティブ/ダンまち2製作委員会  

活躍させたいキャラクターを複数決定    ステージ設計 ①想定パーティの決定  そのキャラクターを用いて  ハイスコアが出せるパーティを作る  ※パーティは一例です   ©
大森藤ノ・SBクリエイティブ/ダンまち2製作委員会   課題  ダンメモのキャラをすべて把握していないと  ベストなパーティを組むことが難しい 

ステージ設計 ②敵の基本パラメータの決定  想定パーティがハイスコアを取れるように  ボスのパラメータを決定する      ex)  パーティに火属性のキャラクターが多い　→　火属性耐性を下げる  活躍させたいキャラクターが物理攻撃デバフを持っている　→　物理攻撃が強いボスにする 
      物理攻撃のボスなので、  そのイメージにマッチするキャラクターの選定もします © 大森藤ノ・SBクリエイティブ/ダンまち2製作委員会  

ユーザセグメント別に  適正な難易度でハイスコアが出るようにする      ステージ設計 ③ユーザセグメント別の設計  ライト  ミ
ドル  なんとか15ターン  生き残りたい…  生き残るだけじゃなくもっと高い難易度に挑戦したい  ハイスコア狙うぞ！  ランキング上位にも入りたい！  継続的な成長欲求の形成    ヘビ   

パーティのレベル別に、適正難易度帯を設計する（赤のライン）  ステージ設計 ③ユーザセグメント別の設計  弱  強  ボスの強さ 
弱  強  パーティの強さ 

テストプレイの前に  ①想定パーティの決定    ③ユーザセグメント別の  　ゴール設定  ②敵の基本パラメータ  　の決定    © 大森藤ノ・SBクリエイティブ/ダンまち2製作委員会
 

テストプレイの前に  ①想定パーティの決定    ③ユーザセグメント別の  　ゴール設定  この情報だけでテストプレイを始めるのは途方もない… 　  テストプレイのための定量的な目標値を決めたい  ②敵の基本パラメータ  　の決定 
  © 大森藤ノ・SBクリエイティブ/ダンまち2製作委員会  

①想定パーティの決定  ②敵の基本パラメータの決定  ③ユーザセグメント別のゴール設定  ①目標値の設定  ②実際にプレイする 

      何ターン生き残るか          テストプレイ ①目標値の設定 
テストプレイの指標として、具体的な目標値を設定する  ※赤ラインは理想のハイスコア帯

      スコアを算出してみる          テストプレイ ①目標値の設定 
ついでにもう一つ指標ができました  ※赤ラインは理想のハイスコア帯 aaaa  最終スコア = 合計ダメージ × (1+生存ターンボーナス) × (1+難易度ボーナス)  1ターンあたりのダメージ量を実績ベースで出し、  目標生存ターン数を入れればざっくり最終スコアを算出できる 

定量的な目標値が決まったので、テストプレイを行っていきます  テストプレイ ②実際にプレイする  想定パーティで  ボスと戦って  どれくらいのスコアが出せるか  © 大森藤ノ・SBクリエイティブ/ダンまち2製作委員会  

定量的な目標値が決まったので、テストプレイを行っていきます  テストプレイ ②実際にプレイする  課題  ダンメモのバトルに慣れたゲームデザイナーでないとハイスコアを出せるコマンド選択ができない  想定パーティで  ボスと戦って  どれくらいのスコアが出せるか  ©
大森藤ノ・SBクリエイティブ/ダンまち2製作委員会  

テストプレイ ②実際にプレイする  想定パーティで  ボスと戦って  ハイスコアが出せた  定量的な目標値が決まったので、テストプレイを行っていきます  最適行動をしたときの  生存ターン数がわかる  © 大森藤ノ・SBクリエイティブ/ダンまち2製作委員会
 

テストプレイ ②実際にプレイする  課題  手動で膨大な数をプレイしなければならない  プレイ結果が目標値どおりになっているかを照らし合わせる 

テストプレイ ②実際にプレイする  課題  バトルにランダム要素があり1度でハイスコアを  出せないため、試行回数を増やす必要がある  プレイ結果が目標値どおりになっているかを照らし合わせる 

①想定パーティの決定  ②敵の基本パラメータの決定  ③ユーザセグメント別のゴール設定  ①目標値の設定と検証  ②実際にプレイする  テストプレイの結果をもとに、敵のパラメータや行動の調整を行う 

バランス調整  テストプレイの結果をもとに、敵のパラメータや行動の調整を行う    ex)　  目標の生存ターン数：10ターン  テストプレイ結果：8ターン      © 大森藤ノ・SBクリエイティブ/ダンまち2製作委員会
  敵の攻撃力を下げてみる  攻撃の回数を減らしてみる  課題  ダンメモの調整に慣れたゲームデザイナーでないと  スムーズに調整を行うことができない 

①想定パーティの決定  ②敵の基本パラメータの決定  ③ユーザセグメント別のゴール設定  ①目標値の設定と検証  ②実際にプレイする  テストプレイの結果をもとに、敵のパラメータや行動の調整を行う 

ボスバトルの設計  テストプレイの結果と  ボスバトルのバランス調整は終了！  目標値が全ステージで一致すれば  © 大森藤ノ・SBクリエイティブ/ダンまち2製作委員会  

ボスバトル設計の中で挙げられる課題  手動でプレイ  時間がかかる  熟練のゲームデザイナー  でないと難しい  膨大な検証数  バトルのランダム要素  パーティを組む  コマンド選択  スムーズな 
バランス調整 

バランス調整  なんとかして欲しい！  © 大森藤ノ・SBクリエイティブ/ダンまち2製作委員会  

バランス調整  自動プレイエージェントの導入 

一番ざっくりしたシステム構成図  自動プレイエージェント自動プレイ環境バトル 

自動プレイエージェントは２種類を検証中  ルールベースエージェント機械学習エージェントと  それぞれの詳細は後ほど 

まず自動プレイ環境について 

自動プレイ環境  実運用のための環境と、検証のための環境、２つを用意している  検証環境  • 基本的にエンジニアが使う環境  • 各エージェントのデバッグ・検証や機械学習エージェントの学習に使う  実運用環境 
• 基本的にゲームデザイナーが使う環境  • ルールベースエージェントの利用が可能  • （機械学習エージェントの推論モードの利用を想定） 

実運用向け自動プレイ環境  ルール(Pythonスクリプト)等の設定  結果のサマリ  バトル結果  シミュレーター実行  結果の分析  ルールAI等のスクリプト設定の反映  シミュレーター

検証向け自動プレイ環境  操作  ソケット通信  （バトル）  Gym対応エージェントスクリプトサーバーソケットインターフェース OpenAI Gym
ラッパー起動  起動  シミュレーター

自動プレイ環境  Gym対応エージェントスクリプトサーバーソケットインターフェース OpenAI Gym ラッパールールAI等のスクリプト
実運用の環境  検証用の環境  シミュレーターシミュレーター

シミュレーターが呼び出すスクリプト  検証用環境のサーバーソケットインターフェースや、実運用環境のルールベースエージェントの実装は、共通の仕組みを使っています  詳細は後ほど 

開発システムのコンポーネント  • ゲーム本体  • シミュレーター  • シミュレーターが呼び出すスクリプト  ◦ 共通仕様  ◦
ルールベースエージェント  ◦ サーバーソケットインタフェース  • OpenAI Gymラッパー  • Gym対応エージェントスクリプト  ◦ ルールベースエージェント  ◦ 機械学習モデルの学習用エージェント  ◦ 機械学習モデルの推論検証用エージェント   

シミュレーター  ゲーム開発のためのエディター(Macアプリ)をラップしたもので、ゲーム本体をほぼそのまま実行するもの    シミュレーターゲーム本体 © 大森藤ノ・SBクリエイティブ/ダンまち2製作委員会  

シミュレーターシミュレーター  利点：ゲームロジックを忠実に再現  欠点：実行速度が大きく制限される    ゲーム本体 © 大森藤ノ・SBクリエイティブ/ダンまち2製作委員会  

シミュレーター  #if defined(SIM)でエディターに必要なコードを挿入し、シミュレーターとしてビルドする  エージェントプレイ以外に、オートモードでのプレイにも対応している  ボスバトル以外のコンテンツにも対応している 

シミュレーターが呼び出すスクリプト  エージェントがプレイする設定の場合、シミュレーターは  path/to/external_script < input.json > output.json を毎ターン実行する  external_scriptは設定に応じて切り替えることができる  •
ルールベースエージェント  • サーバーソケットインターフェース  といった種類がある 

シミュレーターが呼び出すスクリプト  input.json  • シミュレーターからスクリプトに渡る情報  • 味方の現HP、最大HP、現ターン数、必殺技ゲージの値、敵味方のバフ/デバフ状況  output.json  • スクリプトからシミュレーターに渡る情報 
• 各PCの行動 

開発システムのコンポーネント  • ゲーム本体  • シミュレーター  • シミュレーターが呼び出すスクリプト  ◦ 共通仕様  ▪
バフ/デバフ特徴量  ◦ ルールベースエージェント  ◦ サーバーソケットインタフェース  • OpenAI Gymラッパー  • Gym対応エージェントスクリプト  ◦ ルールベースエージェント  ◦ 機械学習モデルの学習用エージェント  ◦ 機械学習モデルの推論検証用エージェント   

バフ/デバフ特徴量  多数のバフ/デバフがあるが、コマンド選択に対して特に重要な50種類程度のバフ/デバフを選別して、入力として利用している 

バフ/デバフ特徴量の取得  画面に表示される状態変化の文言を取得し、それを受け渡す  キャラクタの長押しで表示されます  © 大森藤ノ・SBクリエイティブ/ダンまち2製作委員会  

検証してるエージェントのうちの１つ  ルールベースエージェント機械学習エージェントと 

ルールベースエージェント  ゲームデザイナーがシンプルな行動ルールを考え、それをそのままコードにする。ダンメモにおいてはそれなりに強い  if PC_ID_XXX in status.keys():   if
status[PC_ID_XXX]['effect']['buff']['attack']['_strength'][1] > 0:   commands[PC_ID_XXX] = 'SKILL3'     ルールの例  ルールベースエージェント

実際にゲームデザイナーが作成したルール 

ルールベースエージェントの性能    • ゲームデザイナーの出すハイスコアにかなり近い結果が出た    • 汎用的なルールが作成できれば、パーティ毎のスコアの比較検証に使用できそう 

　全体を通してある程度なだらかなスコアが出た  ルールベースエージェントの性能  　スコアが想定値から大きくはずれるステージがないかの検証に　使用できそう 

ルールベースエージェントの課題  • 熟練ゲームデザイナーでないとルール作成が難しい    • ステージ数が少ない場合は手動で戦った方が早い　    • 汎用的なルール作成は複雑で難しい  •
同じパーティとボスでも、難易度により行動が変化する  • あらゆる情報を複合的に判断している  • 現ターン数、バフ残ターン数、生存キャラなど  • 過去の経験から未来を予測をする  • 人間は数回プレイをし、ボスの行動を記憶している 

課題を解決する  エージェントが必要 

目次  運用の課題  エージェントの開発/検証  プロジェクトは  どう進んだか  まとめ  ダンメモのバトルについて  現状のボスバトルの設計方法とその課題  自動プレイ環境/ルールベースエージェントの構築 

その前に、  機械学習エージェントの  学習環境について  （検証向け自動プレイ環境） 

検証向け自動プレイ環境  操作  ソケット通信  （バトル）  Gym対応エージェントスクリプトサーバーソケットインターフェース OpenAI Gym
ラッパー起動  起動  シミュレーター

サーバーソケットインターフェース  文字通り、クライアントからのソケット通信を待ち受ける機能を持つ  特に学習時は、機械学習エージェントのプロセスを、シミュレーターのプロセスより長生きさせたいので、シミュレーターのプロセスと、エージェントのプロセスを分離して、ソケット通信する構成にした  • 推論時は、推論モデルのプロセスのライフスパンは短くて構わない 

サーバーソケットインターフェース  input_data = json.load(sys.stdin)   with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
  finish = False  s.bind((BIND_IP, BIND_PORT))   s.listen(1)  while not finish:  conn, addr = s.accept()   with conn:  while True:   data = conn.recv(MESSAGE_SIZE)   if data.decode('utf-8') == 'state':   conn.send(json.dumps(input_data).encode('utf-8'))   elif 'action' in json.loads(data.decode('utf-8')):   action = json.loads(data.decode('utf-8'))['action']   finish = True   ...  json.dump(output_data, sys.stdout, indent = 4, ensure_ascii = False)    

OpenAI Gymラッパー  Gymは様々なゲーム環境の統一インタフェースを提供するプロジェクト。強化学習ライブラリに対する標準的なインタフェースとなっているが、強化学習以外の用途で使っても勿論良い。  本プロジェクトでは、待ち受けているソケットにクライアントとして接続する、という機能を持たせている  Gymの仕様に沿ってゲームをラップすると、既存の強化学習ライブラリ等で簡単にゲームプレイできるようになる 

OpenAI Gymラッパーの役割  Gym ラッパーシミュレーターゲーム本体サーバーソケットインタフェース whileループでconnect()  起動 
ターンごとに起動  Gym対応エージェントスクリプト操作 

OpenAI Gymラッパー  def reset(self): #シミュレーターを起動するために呼び出す   …   while True: 
with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:   s.connect((SIM_IP, SIM_PORT + PARALLEL_PARAM))   s.send('state'.encode('utf-8'))   observation = json.loads(s.recv(MESSAGE_SIZE).decode('utf-8'))   …     def step(self, action): #1ターン進めるために呼び出す   …  with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:   s.connect((SIM_IP, SIM_PORT + PARALLEL_PARAM))   s.send(json.dumps({'action': action}).encode('utf-8')   …  

機械学習モデルを学習する仕組み  教師あり学習強化学習

機械学習モデルを学習する仕組み  教師あり学習の役割  強化学習を効率的に実施するため、様々なパーティLvや難易度設定に共通の機械学習モデルを学習する  強化学習の役割  様々なパーティLvや難易度設定ごとに、教師あり学習で学習したモデルを個別最適化していく 

教師あり学習のシステム構成  Gym ラッパーシミュレーターゲーム本体サーバーソケットインタフェース whileループでconnect()  起動  ターンごとに起動 
ルールベースエージェント操作  機械学習モデルプレイログ教師あり学習 

教師あり学習  いくつかの設定でのルールベースエージェントのプレイログを足し合わせて学習している  与えられたデータを用いてモデルを学習する手法  プレイログ機械学習モデル（ニューラルネット）読み込んで学習 

プレイログ  学習データ  • 味方のHP％、現ターン数、必殺技ゲージの値、敵味方のバフ/デバフ状況  １ターン１行  ラベル  • ルールベースエージェントが選択したコマンド 

機械学習モデル  浅いニューラルネットワーク、回帰モデル  学習対象/出力  • 各コマンドの選択確率を計算するためのスコア 

機械学習モデルを学習する仕組み  教師あり学習  強化学習 

強化学習のシステム構成  Gym ラッパーシミュレーターゲーム本体サーバーソケットインタフェース whileループでconnect()  起動  ターンごとに起動 
強化学習エージェント操作  機械学習モデル

強化学習  エージェントが環境から報酬と状態を受け取り、行動を環境に送るというイテレーションを繰り返すことによって行動選択モデルを学習する手法  エージェント  環境（ゲーム）  報酬・状態  行動 

強化学習  本システムではルールの微調整に使うイメージ  • プレイスコアを報酬とみなし、スコアが高くなるよう学習していく    機械学習  モデル  ゲームデザイナー  設定ルール 
模倣  自動プレイ  による微調整 

ところで、なぜ強化学習なのか  強化学習が再現性や過学習や学習速度の面で課題が多いというのは広く知られている  • 実際僕らはまだ実運用できていない  例えばユーザーのプレイログからの教師あり学習の方が筋が良いのでは？？ 

ユーザーのプレイログを利用することの懸念  新しい遊びの提供  継続的なキャラクター育成欲求の形成    新機能を追加し、バトルのルールが変わる  新キャラを追加し、新スキルが登場する  過去ログからの学習が不適切になる事があり  強化学習的な仕組みが必須

GD・ENは何をしたのか/すべきなのか  ゲームデザイナー  • 自分がどうやってゲームをプレイしているか、を言語化した  ◦ ルールの作成、特徴量の選定  • ルールベースエージェントの課題を言語化した  エンジニア  •
ゲームデザイナーの話を理解してコード化した  • 実装しているモデルの仕組みを丁寧に説明した  ◦ ユーザーログを利用した教師あり学習と強化学習の違い 

協働でエージェントをデザインしていく  G D  E N  P M  知見を言語化して伝える  それを 

PvBにおけるボス性能の検証    現状シミュレータはインタラクティブな操作に非対応  各キャラクターの行動×15ターン分をあらかじめ選択して結果を取得          ベイズ最適化を使って最適な行動を探索  パーティはプランナーが選定した強そうなもので固定 
(1ターンあたりの行動可能パターン)^15の探索空間を持つ  ブラックボックス最適化問題  CEDEC2018での発表

結果  コマンド選択の探索を行うことでスコアは大幅に向上  初期スコア：933,480  最適化後スコア：15,199,704  人間の最高スコア： 24,278,700  (人の壁は厚い)    PvBにおけるコマンド選択の探索はかなり成功   
ターン毎の状況判断、強化学習の検証等は今後の課題  ※有限時間で探索を打ち切っているので、大域的な最適解には至っていない  CEDEC2018での発表

最初の失敗  ゲームデザイナーが知らない間に、ある日プレイエージェントができてました、みたいなのを目指した  ゲーム開発運用チームと、エージェント開発チームを疎結合にしようとした  • ゲームの開発運用チームに負荷を与えたくない  • アカデミック界隈では、事前知識を使わずにゲームをプレイするエージェントが流行っていた 

ドメイン知識を使わないで頑張る日々  A3C等の強化学習アルゴリズムの適用  ベイズ最適化の適用  UDB1等の多腕バンディットアルゴリズムの適用 

ドメイン知識を使わないで頑張る日々  A3C等の強化学習アルゴリズムの適用  ベイズ最適化の適用  UDB1等の多腕バンディットアルゴリズムの適用  学習にかかる時間が長く、  結果的に改善イテレーションも長い... 

開発プロセスの  再検討 

プロジェクトの位置付けの再確認  他プロダクト展開を前提にした投資案件  • 単体施策として開発コスト回収とかはあまり気にしない  • 非機能要件のバランスに関する知見を貯めたい 

開発システムの非機能要件  強さ  • 熟練ゲームデザイナーと同程度のスコア  学習速度  • テストプレイに許される日数の制約  汎用性  • 様々なパーティ設定・ボス設定に対応 
複雑さ  • できるだけシンプルにしたい 

非機能要件のバランス  難解・複雑なアリゴリズムやシステム構成にすることで、どのくらい強さ・速さ・汎用性が向上するか  汎用的  はやい  強い  運用しやすい  VS 

知見を貯めるために  引き続き難解・複雑なアルゴリズムを検証することも必要  ただ１つ問題があって、それは、検証するとそれをプロダクションで使いたくなること 

何か変えないと 

対応策：２つのプロジェクトに分離  プロジェクト  プロジェクトの位置付け  システム開発  • メインの開発プロジェクト  研究サーベイ  • サイドプロジェクト  •
高度なアルゴリズムに関する知見を貯める 

開発プロセスの全体像  自動プレイ環境  の整備  ルールベース  エージェント  特徴量  エンジニアリング  機械学習  エージェント 

Rules of MLとの出会い  Rules of Machine Learningという、Googleが公開している機械学習プロジェクトのベストプラクティス集を知った  その時、漠然と考えていたことを裏付けてくれるような
内容だったので、以降はこのRules of MLに沿って開発を進めた  • ドメイン知識をムッチャ使う進め方  https://developers.google.com/machine-learning/guides/rules-of-ml/

Rules of ML の主張（意訳）  性能の継続的改善のため、まずパイプラインやモニタリングシステムを整備しよう  性能改善には、アルゴリズムより特徴量が重要な場合がほとんどだ  簡単に性能解析できるベースラインのモデルを作ろう  システムはできるだけシンプルさを保つようにしよう 

Rules of MLの推奨開発プロセス（意訳）  ヒューリスティクスをベースにしたシステムの導入 / パイプライン整備  ヒューリスティクス追加による性能改善  複雑化し、メンテコストが大きくなったら機械学習での置き換えを検討  機械学習の為のパイプラインの整備  シンプルな目的関数、特徴量、アルゴリズムで構成するベースモデルの導入 
特徴量エンジニアリング（特徴量の追加）による性能改善  より高度なアルゴリズムの導入による性能改善 

本システム開発との対応表  自動プレイ環境  の整備  ルールベース  エージェント  特徴量  エンジニアリング  パイプライン  の整備  ヒューリスティクスの導
入  ヒューリスティクスの追加  自動プレイエージェント  Rules of ML  機械学習での  置き換え  機械学習  エージェント 

Rules of MLに従う事で気付けた事  最低限動くものや、単純なモデルがあれば会話が弾み、新しい発想が出てくる  ゲームデザイナーのドメイン知識で性能が改善する  これらは、プロダクト開発の定石だとも思いますが、機械学習プロジェクト全般でも定石は変わらない、という事に気付けたのが大きいです  複雑なシステムも差分として実装すれば、まだ実装・説明しやす
い 

研究サーベイのプロセス  強化学習  エンジニアリング  サンプル効率化 

研究サーベイ  メインプロジェクトに導入されなくても達成感を持てる目標を設定する事が一番大切 

研究サーベイの進め方  サイドプロジェクトでも締め切りがズルズルしないように  外部発表をマイルストーンに設定する    明確な出口を設定することでシステム導入の誘惑が減るように  サーベイ結果が形式知（ドキュメント）として積み上がるように   

マイルストーンにした外部発表  第42回ゲーム情報学研究発表会  グリー開発本部 Meetup #2 

グリー開発本部 Meetup #2  発表資料は弊社SlideShareにあります    自社開催は、マイルストーン設定的には嬉しい  • 時期も内容も自由に決められる  • これは2019/01開催 

ゲーム情報学研究発表会  大学生、大学院生の発表が多く、企業からの発表は（多分）珍しい  情報処理学会の研究会で、その名の通りゲームを題材にした研究を取り扱う。査読なし。  2019/07開催の第42回研究発表会に参加 

発表内容の概要  自社ゲームでなくAI研究に使われるシミュレータを利用  マスターデータの埋め込みによる入力次元の削減や、ゲームの特徴に合わせてネットワーク構造を小さくする事により、学習が効率化する事を確認  強化学習のサンプル効率化（高速化）がテーマ 

PMは何をしたのか/すべきだったのか  システムが必要最低限の複雑さで収まるようコントロール  • 複雑なシステムはコミュニケーションを阻害する  • 技術検証は技術検証で明確に分離  ゲームデザイナーの言語化の支援  • 何を明確にすればエンジニアリングに繋がるかを伝える 

コミュニケーション可能な環境を用意する  G D  E N  P M  知見を言語化して伝える  それを 

運用の課題  手動でプレイ  時間がかかる  熟練のゲームデザイナー  でないと難しい  膨大な検証数  バトルのランダム要素  パーティを組む  コマンド選択  スムーズな 
バランス調整  時間がかかる  熟練のゲームデザイナー  でないと難しい 

エージェントの開発/検証  • ゲーム本体  • シミュレーター  • シミュレーターが呼び出すスクリプト  ◦ 共通仕様  ◦

プロジェクトはどう進んだか  自動プレイ環境  の整備  ルールベース  エージェント  特徴量  エンジニアリング  自動プレイエージェント  研究サーベイ  機械学習 
エージェント  強化学習  エンジニアリング  サンプル効率化 

　エンジニアとゲームデザイナー  　お互いに自身の知識や作業内容を言語化し、理解し合う    　プロジェクトマネージャー  　コミュニケーションが成立する環境を用意する  協働でエージェントをデザインしていく  G D  E N 
P M 

ご静聴  ありがとうございました 

機械学習ベースの自動プレイエージェントを用いたバランス設計効率化の追求

機械学習ベースの自動プレイエージェントを用いたバランス設計効率化の追求

More Decks by gree_tech

Other Decks in Technology

Featured

Transcript