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

by gree_tech

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

ボスバトルの設計フロー  ステージ  設計  マスターデータ設定  ビルド  テスト  プレイ  バランス  調整  ①想定パーティの決定  ②敵の基本パラメータの決定  ③ユーザセグメント別のゴール設定 

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

ボスバトルの設計フロー  ステージ  設計  マスターデータ設定  ビルド  テスト  プレイ  バランス  調整  ①想定パーティの決定  ②敵の基本パラメータの決定  ③ユーザセグメント別のゴール設定  ①目標値の設定  ②実際にプレイする 

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

ボスバトル設計の中で挙げられる課題  手動でプレイ  時間がかかる  熟練のゲームデザイナー  でないと難しい  膨大な検証数  バトルのランダム要素  パーティを組む  コマンド選択  スムーズな  バランス調整  なんとかして欲しい！  © 大森藤ノ・SBクリエイティブ/ダンまち2製作委員会  

Slide 53

Slide 53 text

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

Slide 76

Slide 76 text

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

Slide 77

Slide 77 text

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

Slide 78

Slide 78 text

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

Slide 79

Slide 79 text

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

Slide 80

Slide 80 text

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

Slide 81

Slide 81 text

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

Slide 82

Slide 82 text

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

Slide 83

Slide 83 text

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

Slide 84

Slide 84 text

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

Slide 85

Slide 85 text

Slide 86

Slide 86 text

Slide 87

Slide 87 text

Slide 88

Slide 88 text

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

Slide 89

Slide 89 text

サーバーソケットインターフェース  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)    

Slide 90

Slide 90 text

Slide 91

Slide 91 text

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

Slide 92

Slide 92 text

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

Slide 93

Slide 93 text

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')   …  

Slide 94

Slide 94 text

Slide 95

Slide 95 text

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

Slide 96

Slide 96 text

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

Slide 97

Slide 97 text

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

Slide 98

Slide 98 text

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

Slide 99

Slide 99 text

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

Slide 100

Slide 100 text

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

Slide 101

Slide 101 text

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

Slide 102

Slide 102 text

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

Slide 103

Slide 103 text

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

Slide 104

Slide 104 text

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

Slide 105

Slide 105 text

Slide 106

Slide 106 text

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

Slide 107

Slide 107 text

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

Slide 108

Slide 108 text

Slide 109

Slide 109 text

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

Slide 110

Slide 110 text

協働でエージェントをデザインしていく  G D  E N  P M  知見を言語化して伝える  それを  理解する  プロジェクト全体の進行管理  それを  理解する  システムのロジックを説明する  システムが複雑になりすぎるのを防ぐ  言語化の補強をする 

Slide 111

Slide 111 text

Slide 112

Slide 112 text

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

Slide 113

Slide 113 text

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

Slide 114

Slide 114 text

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

Slide 115

Slide 115 text

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

Slide 116

Slide 116 text

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

Slide 117

Slide 117 text

開発プロセスの  再検討 

Slide 118

Slide 118 text

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

Slide 119

Slide 119 text

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

Slide 120

Slide 120 text

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

Slide 121

Slide 121 text

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

Slide 122

Slide 122 text

何か変えないと 

Slide 123

Slide 123 text

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

Slide 124

Slide 124 text

Slide 125

Slide 125 text

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

Slide 126

Slide 126 text

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

Slide 127

Slide 127 text

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

Slide 128

Slide 128 text

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

Slide 129

Slide 129 text

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

Slide 130

Slide 130 text

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

Slide 131

Slide 131 text

Slide 132

Slide 132 text

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

Slide 133

Slide 133 text

Slide 134

Slide 134 text

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

Slide 135

Slide 135 text

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

Slide 136

Slide 136 text

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

Slide 137

Slide 137 text

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

Slide 138

Slide 138 text

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

Slide 139

Slide 139 text

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

Slide 140

Slide 140 text

Slide 141

Slide 141 text

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

Slide 142

Slide 142 text

コミュニケーション可能な環境を用意する  G D  E N  P M  知見を言語化して伝える  それを  理解する  プロジェクト全体の進行管理  それを  理解する  システムのロジックを説明する  システムが複雑になりすぎるのを防ぐ  言語化の補強をする 

Slide 143

Slide 143 text

Slide 144

Slide 144 text

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

Slide 145

Slide 145 text

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

Slide 146

Slide 146 text

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

Slide 147

Slide 147 text

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

Slide 148

Slide 148 text

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