大規模開発のための Luminous Engine のログ分析と自動テスト

大規模開発のための LUMINOUS ENGINE のログ分析と自動テスト

株式会社 Luminous Productions 岩﨑浩自己紹介

• 岩﨑浩 Hiroshi Iwasaki

– Luminous Productions http://www.luminous-productions.com/ – プログラムセクションディレクター

• LUMINOUS ENGINE 紹介主に機能紹介 • ログ分析と自動テストの概要 • ログ分析 15分(目標) • プレイログ機械学習の話とか • 自動プレイ

キャラツールグラフィックステラインツール AI LUMINOUS ENGINEの構成

VFX アニメーション UI アセットブラウザ

アセットビルド

• どこでバグっているか見つけるのが大変。 – ほとんどの場合、原因を見つける方が、直すより大変です。 • バグを再現するのが大変。 – 再現性が低い、とか。 – 再現する手順が大変、とか。

繰り返し自動プレイ

パターンの網羅スクリプト実行

発生した原因の特定バージョンの特定

再現リプレイ

ログホストログサーバー Web サーバー

開発機スケジューラ

プレイログ

テストサーバーテストサーバーテストサーバーテストサーバーテストサーバーテストサーバー自動プレイ

ログホストログサーバー Web サーバー

開発機スケジューラ

プレイログ

テストサーバーテストサーバーテストサーバーテストサーバーテストサーバーテストサーバー自動プレイ

誰のSubmit?

Submitのコメント

テストが失敗した時に、どのSubmitからバグが起きるようになったか？がわかる。

パフォーマンススクショ(2D) クラッシュした場所

JIRAチケットの場所スクショ(パノラマ) 現在プレイされている場所

2019/6/15 2019/7/16 2019/8/5

すべてのログは、過去の情報も見られます。

Microsoft Teams での通知

前回と見た目が変わっていたら通知

influxdb

アプリケーション開発者が記述可能

定義ファイル Python (JSON)

自前カスタム Flask python JavaScript ブラウザ

定義ファイルカスタム (JSON) JavaScript

ブラウザ上で、編集し、確認が可能。

ログホストログサーバー Web サーバー

開発機スケジューラ

プレイログ

テストサーバーテストサーバーテストサーバーテストサーバーテストサーバーテストサーバー自動プレイ

• いろいろなテストを実行します。

C# C++ python C# with “Python for .NET” Visual Script

.NET Frameworkにアクセス可能な言語なら、 RPC 何でもOK

LM_FUNCと書くと、エンジンがサポートする全てのスクリプトからアクセス可能になります。

こんな感じで使える。

スクショを取って、前回の結果と比較の例

ログホストログサーバー Web サーバー

開発機スケジューラ

プレイログ

テストサーバーテストサーバーテストサーバーテストサーバーテストサーバーテストサーバー自動プレイ

• テストを実行するタイミング、条件などを制御します。 • どのマシンで実行するか?なども制御します。

バックエンドは Jekinsを使っています。

実行条件などは、自前のスクリプトです。

Test A 実行命令

Test B 実行命令

実行命令

マスター Job Test C 前半実行命令実行 Job テスト実行命令を実際に最小単位に分解テストを実行する

Test C 後半実行命令

例えば、デイリーテストを実行という命令に対して、・何のテストを、・どのプラットフォームで、・どのマシンでテストするか? を分解し、複数の実行Job に投げます。

• 複数のマシンがアサインされています。 • JenkinsのLabelを使って、実行するマシンの制御を行っています。

ログホストログサーバー Web サーバー

開発機スケジューラ

プレイログ

テストサーバーテストサーバーテストサーバーテストサーバーテストサーバーテストサーバー自動プレイ

• ログを永続的に記録します。

実機ログホスト実機 influxdb

Local Server

• 各種スクリプトにコードを仕込むことで、ログが記録されます。 • ログは、InfluxDB に永続的に記録されます。 – ある程度古いのは間引いて消しています。

Measurement(テーブル)の Performance.FPSに value, pos, angleというFieldで保存されます。

ログホストログサーバー Web サーバー

開発機スケジューラ

プレイログ

テストサーバーテストサーバーテストサーバーテストサーバーテストサーバーテストサーバー自動プレイ

• ゲームをリアルタイムに記録する目的に特化したログです。 – 今まで紹介したInfluxDBで取るログとは別の仕組みです。(連携はできますが)

• コリジョンが抜けた。 • キャラが突然消えた。 • 扉を開けたら、いるはずのキャラがいなかった。 • 今、立つはずのないフラグが立っている。その瞬間、何が起きていたのかを知りたい！

色々なシステムプレイログプレイログ色々なシステムシステム

ポインタを自動で比較して、登録しておきます。変わった値を記録します。

• エンジンが認識できるゲームのプロパティ全部。 – Visual Scriptの実行履歴やプロパティの変化 – ゲームオブジェクトのプロパティ • 座標、ゲームステートなど。 • パッド入力 • パフォーマンス、プロファイル情報 – スパイクが起きたフレームを分析するため • ユーザーが指定したパラメータ

• この例では、カメラのView Matrix, Projection Matrixのリプレイログを取る、と言う指定です。 • あとは、エンジンが勝手に毎フレーム、差分を記録し続けます。

• 過去の値の確認 • 過去のフレームのプレビュー • 過去の任意のフレームからのリスタート • グラフによる履歴の可視化 • 保存/読み込み • 機械学習の入出力に使う (後述)

ログホストログサーバー Web サーバー

開発機スケジューラ

プレイログ

テストサーバーテストサーバーテストサーバーテストサーバーテストサーバーテストサーバー自動プレイ

自動で、今まで行われたことのないプレイをしてくれる。発見的自動プレイ

過去に、一度行ったプレイを、繰り返し実行してくれる。リプレイ的自動プレイ

今回はこちらの話

• パッド入力を記録 • スクリプトで制御

パッド、と言っていますが、もちろん、キーボードでもマウスでもタッチパネルでも同様です。

• 非常に高い汎用性 – ゲームの種類を問わず、入力を記録するリプレイは動作します。 • リプレイのデータを用意するのが直感的 – 普通にプレイしたのを記録すれば良い。 • そのリプレイで再現したバグは、必ずユーザーも再現可能 – リプレイで行われた操作はパッドのみなので。

• リプレイが安定しない – 何かの拍子に、少しでもずれると、使い物にならない。 • ⾧時間の通しプレイをパッド入力だけで、再現するには、相当の仕込みが必要。 – ランダム要素の排除、エンジンとしての、結果の安定性、など。

• ⾧時間の通しプレイも再現可能。 – 人力でスクリプトを組むので、がんばり次第で、何とでもなる。

• 作るのが直感的ではない。 – プログラマ的作業。 • スクリプト制御特有のバグが起こりえる。 – 実際のユーザーのプレイとは若干違う。 • メンテコストが高い。 • 汎用性が低い。

• 毎回、同じ結果にならないエンジン側の問題 • ランダム要素という、ゲーム側の問題

問題を取り除き、維持し続けるのは、難しい！

記録したパッド入力をそのまま再生したリプレイパッドリプレイ

マシンラーニングを使ったリプレイ

ラーニングリプレイ

以下、NN

• 何を学ばせるか?

色々なシステムプレイログプレイログ色々なシステムシステム

これを使います。

ゲームの状態を保存したデータ列・・・

フレーム番号 N-2 N-1 N N+1 N+2 N+3 この中にはパッド入力も含まれています。

時系列のデータ

・・・

N-1のパッド Nのパッド N+1のパッド N-1 の状態 N の状態 N+1 の状態

今回の目的はQA用途のリプレイなので。 NNの出力は、パッド入力であるべき。ここは？ここは、パッド入力

・・・

N-1のパッド Nのパッド N+1のパッド N-1 の状態 N の状態 N+1 の状態このゲームの状態を NNの入力に使います。

解釈を変える Nのパッド

Nのパッド N の状態 N+1 の状態 N の状態 NとN+1の差分

Nのゲーム状態と N+1への差分パッド入力

FPSが60の場合、１秒に６０個の学習データが作れます。プレイログ早回しをすればもっと作れます。

先ほどの動画は、約20万のデータを学習させたものですプレイにして１時間くらいの分量。

普段のプレイログは使わず、学習用の専用のプレイセットを用意しています。

・・・

学習済みNNが既にあるとして。

N-1 の状態 N の状態 N+1 の状態これが、今回のリプレイで保存＆再生につかうデータです。

フレームNを再生する場合

フレームNのパッド入力を求める保存されたN+1 と、の状態の状態の差分

• 入力 • 出力 – キャラの座標 – スティックの傾き (4個) – キャラの早さ – ボタンの押し具合 (8個) – カメラの向きなど

• 3層で、ノード数は64の全結合。 • Dropoutは0.2 • 正則化はL2 (0.001) • 活性化関数は、ReLU • 入力データは事前に正規化。

横軸：実際の値縦軸：予測値

横軸：予測値と実際の値との差分縦軸：数

青が、実際のデータオレンジが、予測値弱い入力は改善の余地あり

青が、実際のデータオレンジが、予測値

プレイログプレイの巻き戻し

パッドリプレイプレイログゲームシステムラーニングリプレイ

全部、プレイログのシステム経由で行います。・ゲームの値を取得して、NNに渡す・NN結果をゲームに反映するなど。

プレイログプレイの巻き戻し

パッドリプレイプレイログゲームシステムラーニングリプレイ

一般化させるため、値の意味を知った上での学習は、極力排除しています。

向き(角度) sin(θ)とcos(θ)

ビットフラグ各ビットばらばらに

ハッシュ値連番に

• 0度と360度が同じ、とニューラルネットワークは、理解してくれないっぽい。 – 剰余算はうまく、学習してくれない印象。 – 良い方法があるのかも知れませんが･･･教えて偉い人！

• 「距離」を元に、最も近い近隣フレームに自動で補正

ここで言う「距離」とは、３Dの座標の距離のことではないです。多次元ベクトル間の、距離のことです。また、直値で比較するのではなく、正規化された値で「距離」を計算しています。

この値、全体の距離です。

• リプレイが、正しく再生されているか?の判定にも使えます。

正常な再生何かあったけど、復活した失敗

距離のグラフ

・・・

リプレイデータには、パッド入力の情報も含まれていますので、パッドリプレイラーニングリプレイフレーム番号 N-2 N-1 N N+1 N+2 N+3 をシームレスに切り替えられます。

時系列のデータ

サーバーの自動テストの結果を確認。

自動プレイが、ずれているのを発見！

ずれている、一部のリプレイを撮り直す。自動化したくない？

できるだけ、一般化を維持するため、

最終出力は、パッド入力ゲームの内容に依存する処理は極力しない。

• Actor-Critic (DDPG)を使っています。 • 出力された値をそのまま、パッド入力として使っています。 • 毎フレ評価しています。

ある状態(state)で、ある行動(action)をした時に、どんな状態(next state)になって、どんな報酬(reward)がもらえるか？を学習していく

学習後ある状態(state)でどんな行動(action)を取るのが良いか？を教えてくれるようになる

良い結果になったら、それまでの過程の行動も、良かったと覚えるよ！

これがポイント

状態ゲーム状態 (state)

行動パッド入力 (action)

報酬？ (reward)

• まずは、ゴールを決める。

これがゴール

現実理想の位置

これがゴール

理想

現実

• Actor – ４層。16ノード – 活性化関数は、LeakyReLU • ReLUだと、dying ReLUが多発したので。 – 出力層の活性化に、sigmoid • linearにしていたら、出力(パッド入力）が数百、数千にすぐに行ってしまい、その後、値が張り付いて動かないこと多発。 • 試しにsigmoidにしたら、改善したので、そのまま利用。 – 出力が0-1になるので、これを-1 ~ 1に変換して利用しています。

• Critic – ４層。32ノード – 活性化関数は、LeakyReLU

• 入力 • 出力 – キャラの座標 – スティックの傾き (4個) – キャラの早さ – ボタンの押し具合 (8個) – カメラの向き (連続値) – キャラの向きラーニングリプレイと同じ

• ゴールしたときにのみ報酬(reward)を与える

途中経過を評価しないとダメ。

• 「距離」を報酬に利用 • 近くなったら、プラス報酬(reward) 遠くなったら、マイナス報酬(reward) • 毎フレ、「距離」に応じて、少しずつマイナス評価

• 序盤は良さげですが、最終的には、ひたすら壁に向かって歩き続けると言う結果になりました。

他の事例を見るに、もっとうまくいきそう？？一度、シンプルな例で検証

• actionは、パッド入力ではなく、「上下左右の４方向移動のみ(離散値)」 • ４方向、固定量、必ず移動する(壁との衝突は取ります) • 速度、加速、アニメーションなどは無視 • DQNで学習。

パッド入力は、細かい入力の切り替えだと、移動方向が変わらない。

乱数を60フレームに１回のみ更新するように。

• 乱数を60フレームに１回のみ更新。(モデルの実行は毎フレーム)

• かなり改善。 • ゴールに到達できたので、一旦OKではありますが、壁に向かって移動している時間が⾧いです。 • 何回か試しましたが、うまくいくか、うまくいかないかは、ランダム。 • もっと複雑な例だと、厳しそう。

壁に当たった時に減点したい。

古新

壁にぶつかっていないとき

時間的に近い物は、時間的に遠い物は、距離的にも近い距離的にも遠い

壁にぶつかっているとき

時間的に近い物も時間的に遠い物も全部近い

過去３０フレームの状況(status)が同じ同じって何？壁にぶつかったり、立ち止まったり、何か、無駄なことをしている。

減点対象

直近の３０フレーム分ただの、数字の配列。「同じかどうか？」の閾値を何にすれば良い？

一般化されたデータで、・・・その閾値を決めるのは危険。

どっちのデータの方が近いか？の比較なら、データに依存せず可能。

壁にぶつかっていないけど、減点対象になってしまうケース。

こういったケースも、減点してしまって良いと判断。

• 近い過去に同じ状況(status)があれば、減点

• 壁に向かって歩く時間が減って、最終結果は改善。 • 学習時間は延びました。 • でも、最適化前でも、２０万ステップで、１時間くらいなので、OK。

横軸:エピソード数(1エピソードはおよそ1000ステップ) 縦軸:エピソードの報酬(reward)

• 学習した強化学習のモデル自体をリプレイでは利用しません。 • 利用するには、もっと学習を収束させないと使えないので。 • たまたまのラッキーでも、とにかくゴールに１度でも到達できれば、そのプレイを記録すれば十分です。 • ただ、あまりに遠回りだと微妙なので、一度ゴールに到達しても、しばらくは、学習を継続しています。

• ゴールにたどり着いたら、スコア(累計の報酬reward)を評価。 • 最高スコアを更新していたら、リプレイを更新。

• 出力は「パッド入力」なので、応用範囲が広いです。 • ある程度ずれてても補正されます。 • 一部だけ、撮り直すと言うことができます。 • 状況が変わっても、ある程度は自動で復旧できます。

• リプレイが【だいたい】再現できている、という感じなので、厳密な動作を要求する場合は、現状、難しいです。 – 細い綱渡りをする場面、とか。 – もっとたくさんデータを集めて、もっと適切なモデルで学習させれば、もっと良くなると思います。 – ある場面だけ、パッドリプレイに切り替える、のもOK • 学習させるデータにはコツが必要。 – AIトレーニングを担当する人が必要かも。

QA AI トレーナーテストの内容を決める。色々な、お手本プレイを再現できるよう、お手本プレイを作る。 AI を学習させる人

自動プレイシステム

ゲームのジャンルを問わず、共通化された仕組み。

ログホストログサーバー Web サーバー

開発機スケジューラ

プレイログ

テストサーバーテストサーバーテストサーバーテストサーバーテストサーバーテストサーバー自動プレイ

©2019 Luminous Productions CO.,LTD. • Microsoft Teams はMicrosoft Corporationの商標または登録商標です。 • INFLUXDBはインフラックスデータインクの商標または登録商標です。 • MAYAはオートデスクインコーポレイテッドの商標または登録商標です。 • その他掲載されている会社名、商品名は、各社の商標または登録商標です。

大規模開発のための Luminous Engine の ログ分析と自動テスト

大規模開発のための Luminous Engine のログ分析と自動テスト