BIOHAZARD RE:2の開発中のプレイログを収集した成果と過程

BIOHAZARD RE:2 開発中 の プレイログ 収集した成果と過程 株式会社カプコン ／ 関野優樹

自己紹介 関野 優樹 技術研究開発部 (2009年入社) 普段は RE ENGINE を開発 縁あって序盤から BIOHAZARD RE:2 開発に プレイログ 収集業務に挑戦したのは今回初 [CEDEC 2017] RE ENGINEでのゲーム開発を支えるMacro(Plug-in)機能の紹介 https://cedil.cesa.or.jp/cedil_sessions/view/1683 2

• https://cedil.cesa.or.jp/cedil_sessions/view/1683

BIOHAZARD RE:2 とは • 2019年 1月25日 発売 • サバイバルホラー • TPS • シングルプレイ • メトロイドヴァニア スタイル • マルチプラットフォーム • PlayStation 4 • Xbox One • Steam • RE ENGINE によって開発 • ふたりの主人公、ふたつの物語 3

本セッションが指す『プレイログ』 • 製品に含まれない機能でDebug目的のデータ収集 • ゲーム内パラメータ、実行速度などを収集 • 開発時の “通しチェック” にて収集 • 運営タイトルのログイン・課金情報の収集ではない • 表・図・グラフなどで可視化 • 結果を得て、開発中のゲームに反映する 4

本セッションで伝えたいこと • プレイログは製品のクオリティアップに役立つ • 集めるのは簡単、何を可視化するかが ポイント • 今回の発表を通して、少しでも盛り上がれば幸い • 収集事例・発表が少ない • 尚、この資料は後日、アップロードいたします • https://www.slideshare.net/capcom_rd/ スライドシェア カプコン 検索 5

• https://www.slideshare.net/capcom_rd/

もくじ • プレイログ を導入した『いきさつ』と『成果』 • 送信内容・タイミング・データの加工 • 実装スケジュール と 時期ごとの注意点 • プレイログ を導入しても『叶えられないこと』 • まとめにかえて、啓蒙活動 6

プレイログ を導入した 『いきさつ』と『成果』 BIOHAZARD RE:2 開発中の プレイログ 7

事の発端は、タイトル開発 序盤 レベルデザイナ『プレイヤ データの収集と分析方法を研究したいね』 プログラマ『開発終盤の ゲーム動作の高速化対応がいつも大変』 プレイヤの移動軌跡、HP、処理速度などを収集してみた 8

レベルデザイナ が得た恩恵 • 調整とユーザーの観察に役立った • 通しプレイした人の動きを自席で確認できる • 従来は、プレイ後のアンケートや聞き取りで対応 • 移動の軌跡が見えるため、何処で迷ったかが分かる • 動画と異なり、プレイログの内容でフィルタリング可 9

プログラマ が得た恩恵 • 処理負荷の軽減、最適化に役立った • チェックの結果を自席で確認できる • 従来は問題が発生した環境に居合わせることが必須 • 製品に近い状態の処理負荷が見えた • ヒートマップで可視化した 10

プレイヤ移動の軌跡を閲覧 (少しだけゲーム内容が含まれます、序盤のネタバレになりますがご容赦ください) 11

プレイヤが敵へ攻撃した方法を集計 (ネタバレ区間は終了しました) 13

プレイヤが敵へ攻撃した方法を集計 1/3 14

プレイヤが敵へ攻撃した方法を集計 2/3 圧倒的に、”頭” への攻撃回数が多い “足” へ攻撃すると 男性ゾンビは ホフク状態になる 次点で、”足” への攻撃回数が多い 姿勢面で有利に戦える為 狙われていると予想できる 15

プレイヤが敵へ攻撃した方法を集計 3/3 ”頭” ダメージ量 “足” は “頭” に比べて 与えるダメージ量が小さい ”足”ダメージ量 姿勢面で有利にできるが 致命には至りづらい 16

位置毎の処理負荷計測 結果 17

位置毎の処理負荷計測 結果 1/5 18

位置毎の処理負荷計測 結果 2/5 19

位置毎の処理負荷計測 結果 3/5 データ色 内容 フレームレート 灰色 処理が安定している 40～60 468 橙色 処理落ちしつつある 30～40 43 赤色 処理落ちしている ～30 45 - - - 観測数 計 556 20

位置毎の処理負荷計測 結果 4/5 瞬間的な処理落ち 処理速度の分布 (ミリ秒) 21

位置毎の処理負荷計測 結果 5/5 2018/05/11 ver. 2018/08/31 ver. 22

プレイログ の 収集時期 • タイトル 中盤： • 約3ヶ月に1度 開発者による通しチェック • ゲーム的な進行不能状態、調整不足もあり得る • タイトル 終盤： • 毎日 ＱＡスタッフによる通しチェック • 製品相当の環境でチェックが行われる 23

これらを元にした作業 (レベルデザイナ) • タイトル中盤の、通しプレイ の 行動記録を閲覧 • プレイヤが死亡した場所の閲覧 • ボスの強さ、ゲームのテンポは妥当か • 内部値の推移をグラフで閲覧 • 値の妥当性、意図しない挙動への気付き・修正 24

これらを元にした作業 (プログラマ) • タイトル終盤は毎日、QAチェックの結果を閲覧 • 機材・日時・ゲーム内状況 毎の動作結果を確認 • 処理落ちが発生した場所、条件の絞り込みを行う • 閲覧した内容を元に状況を理解 • 問題の修正方法を考え反映し、修正後の結果を待つ 25

この取り組みで得られた大きな事例 当初、ナイフに耐久値はなかった ナイフによる、”頭” への攻撃が想定より多い 敵をホフク状態にし “頭” へナイフで攻撃と予想 “アイテムを管理する” 企画意図に反している ナイフに耐久値が設定された ナイフによる ”頭” への過剰な攻撃はなくなった 26

送信内容・タイミング データの加工 BIOHAZARD RE:2 開発中の プレイログ 27

プレイログ で収集する データのフロー ゲーム内で データ収集機能を実装 データ をサーバーに送信 サーバー上のデータ を可視化しやすい形に “加工” 加工後のデータ を 可視化 28

[実行環境①] プレイログ 送信方法を考察 • 開発環境によって異なる • メリット・デメリットを理解して実装 実行環境 内へ File出力 外部サーバー への 送信 社内サーバー への 送信 • 実装が簡単、File IOに時間がかかる? • 社の内外からアクセス可能 • 社内で完結する • 出力結果を収集する仕組みが必要 • 開発情報が外部に出る • 逆に、社外からはアクセス不可 • Global 時間が不明 • サーバーに時間を問い合わせ可 • サーバーに時間を問い合わせ可 29

[実行環境②] 可視化 環境 • “Tableau” というツール利用 • 分析・可視化 専門ツール • 柔軟に可視化環境をカスタマイズ 30

データを送信するタイミング • 挙動毎に、プレイヤ主体のデータを送信 Move! ※ 3m 以上移動 Attack! Damage! これら以外にも、あらゆるプレイヤ挙動を送信 31

不必要なデータを過剰に収集しない設計 • ゲーム仕様 に着目 • BIOHAZARD RE:2 の 終了条件 • エンディング / ゲームオーバー • ユーザーが “ゲーム終了” を選択した時 • 安全な場所で棒立ちでも “ゲームは終わらない” • 可視化に必要な情報 (今回は、プレイヤ挙動) のみを収集 32

収集するべきデータ か 否か • 送信するデータは厳選すること • 必要があるデータだけを送信する • 闇雲にデータ送信しても、ノイズになる • どんな グラフ・図 が見たいのかを想像 • そのために どんなデータ が必要か • 想像できない グラフ・図 は、誰も作れない 33

送信する データ の階層 プレイヤ 挙動 階層 ゲーム システム 階層 エンジン 階層 • 移動した、攻撃した • ダメージを受けた • プレイヤ位置、名前、HP • 動作中の敵数 • CPU / GPU 処理速度 • VRAM、Memory 34

送信内容とタイミング 例① • このタイミングで データ 収取 Move! プレイヤ 挙動 ゲーム システム エンジン • 移動した • プレイヤ位置、名前、HP • 動作中の敵数 • CPU/GPU処理速度 • VRAM、Memory 発生時間と 共に送信 35

送信内容とタイミング 例② • このタイミングで データ 収取 Attack! プレイヤ 挙動 ゲーム システム エンジン • 攻撃した • 使用武器 • プレイヤ位置、名前、HP • 動作中の敵数 • CPU/GPU処理速度 • VRAM、Memory 発生時間と 共に送信 36

まずは、データを『そのまま』送る • 送信速度は 当面は気にしない • 1挙動ごとに、2～3K Byteの情報を送信していた • Debug用情報であることをポジティブに捉える • “可視化のし易さ” は考えない • それは “保守し易いデータ” と相反する • 開発中のゲームは仕様が変わり続ける 37

保守し易いデータ と 可視化し易いデータ
• 保守し易いデータ

• 可視化し易いデータ

JsonやXmlなどの階層構造

送信・加工

Time

Type

CPU GPU

Equip

Attack Location

2019
03/30
17:00

Move

60

55

Knife

-

R.P.D

2019
03/30 Attack
17:01

59

59

Knife

Knife

R.P.D

…

“PlayLog_List":[{
"ActionType": "Move",
"ActionInfo": {
“PlayerStatus": { ... },
},
"GameInfo": { … },
"SystemInfo":
{
"CPU": { ... }, "GPU": { ... }
},
"Time": "2019-03-30 17:00:00"
},
…]

エクセルや、データベースなどの表構造

38

Try & Error しながら充実 • “見たい情報” は可視化されてから増える • 収集するデータの内容・形は追加される • その間に、ゲームの仕様変更にも追従する 39

追加された機能：マップ別 処理速度 閲覧 “警察署 ホール1F” の課題 沢山の “部屋” に隣接している 図形 意味 平均フレームレート 45未満 プレイヤの移動でシームレスに背景 のロード・アンロードが発生。 とても 処理落ち しやすい 平均フレームレート 45以上 40

実装スケジュールと 時期ごとの注意点 BIOHAZARD RE:2 開発中の プレイログ 41

プレイログ の実装スケジュール タイトル序盤： ゲーム仕様が変わる時期 データ収集機能 作成・検証 可視化環境を仮構築 タイトル中盤： ゲーム仕様が固まる時期 ゲーム仕様変更に追従 見たいデータの追加 可視化環境を向上 タイトル終盤： ゲーム動作を安定させる時期 処理の高速化 約3ヶ月に1度 開発者達 の 通しチェック 不具合修正 毎日 QAスタッフ の 通しチェック 42

タイトル 序盤 プレイログの送信状態 の作業 切り替え機能 43

基本機能の実装 • プレイログ を “送信しない” モードを用意 • “送信しない” 状態で不具合が発生 → ゲームの不具合 • 問題の切り分けに利用 • “送信状態” を確認できる機能は必須 • プレイログ 送信状態 が、動作中のゲームで確認可 44

基本的に プレイログ は送信する • サーバーに対して送信可能であれば送信する • 該当環境での送信結果が分かる • 後述するエラーデータの調査に利用できる • 但し、送信元情報を記載 • 開発機材の固有ID (PC名 or IPアドレス など) • 通しチェック 用環境 or 開発環境 を区別する情報 45

タイトル 中盤 チェック環境作成 の注意点 エラーデータの対応 46

データは正しく送信されなくなる事がある • “チェック環境” を作成する直前によく発生 他のプログラマが、ゲームの不具合を直す ゲームは正しく動作した しかし、プレイログのデータ が 正しく送信されなくなった プレイログのデータ を収集 ようやく “エラーデータ” と認識できた 47

エラーデータ はどこで生まれる ゲーム内で “データ” 収集機能を実装 “データ” をサーバーに送信 “サーバー上のデータ” を可視化しやすい形に “加工” “加工後のデータ” を可視化 48

改めて、送信する データ階層 を眺める プレイヤ 挙動 階層 ゲーム システム 階層 エンジン 階層 • 移動した、攻撃した • ダメージを受けた 拡張情報 仕様変更の 影響が大きい • プレイヤ位置、HP • 動作中の敵数 • CPU / GPU 処理速度 • VRAM、Memory 基本情報 仕様変更の 影響が少ない 49

定期的に、拡張情報を閲覧する • 異常な状態になっていないかを調査 • 使用できないハズのアイテムが ”使用された” • アイテムを使用する処理が変更された • 長期間、誰も攻撃していない • 攻撃処理に不具合が発生している • ダメージ量が大きすぎる • 開発者用の機能が利用されている可能性 50

開発者機能が起因した エラーデータ • いわゆる、Debugフラグ が利用される • 敵が強すぎる • アイテムが少ない・取れない • 開発者機能を使って… • 弾・体力を無限に • 1Shot Kill • アイテムを生成 51

開発者機能自体は悪ではない • 通しチェックを行う上では必須機能 • BIOHAZARD RE:2 での対策 • 開発者機能を利用した際、その旨を記録しデータ送信 • 該当する開発機材のプレイログは、参考にしない • ゲームのセーブデータに影響している可能性を考慮 52

最終的に 生データ と 対峙 • 問題の切りわけ • データそのものが エラー？ • データの加工時の エラー？ • “保守しやすいデータ” 形式の利点 • Json形式ならば まだ内容が “分かる” • エラーデータ を目視する 53

タイトル終盤 の注意点 処理速度の向上 54

品質チェック時の注意点 • より製品に近い環境で通しチェックが行われる • BIOHAZARD RE:2 で発生した問題 • プレイログ の送信を有効にした状態で “のみ” • 特定の武器を利用すると処理負荷が高まる 55

問題ない場合：ハンドガン Shot! Hit! プレイヤ Total 2 0 Log 1 Total Log 敵 56

問題がある場合：ミニガン Hit! Shot! Shot! Hit! Hit! Shot! プレイヤ Total たくさん Total 0 Log 敵 57

送信負荷が高い状況を回避 • 短時間で連続した攻撃を行う武器は危険 • 火炎放射機・ショットガン・ミニガン • 開発PCではギリギリ問題なく動作していた • 品質チェック時に知りたいことだけ送信する • データ送信の内容・頻度を一部制限する 58

送信量を減らしてミニガンの問題を回避 Hit! Shot! Shot! Hit! Hit! Shot! プレイヤ 2 Total 0 Log Total Log 敵 59

新たな課題: 正確に “処理落ち” 検出する • データ送信時に CPU、GPU のFrame Rateを計測 • 定期的なデータ送信では “処理落ち” を見逃す恐れ • 送信内容、計測するデータを工夫して回避 60

瞬間的な “処理落ち” の例 Frame Rate 70 60 FPS 50 40 30 20 10 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 Frame 61

“処理落ち” を見落とす データ 送信 50 Frame Rate 70 51 60 FPS 50 デ 40 ー 30 タ デ ー タ 20 送 送 10 信 信 0 10 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 Frame 62

“処理落ち” を見落とさない データ送信 前回～今回の送信までの間 Frame Rate 70 最高値、最低値を計測しておく その後、一緒に送信する 60 FPS 50 デ 40 ー 30 タ デ ー タ 20 送 送 10 信 信 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 Frame 63

目的ごとに データ送信量 を変更した レベルデザイナ向け • 沢山データを送信： プログラマ向け • 開発PCで快適な処理速度： 品質チェック向け • 製品に近い処理速度： 多 プレイヤ行動の閲覧 (タイトル 中盤) 敵の命中部位、ゲーム内パラメータ 処理速度の測定 (タイトル 中～終盤) データ 送信量 動作中の敵情報、攻撃情報 チェック内容の計測 (タイトル 終盤) 少 トロフィー取得、コレクター要素、武器利用、オプション設定 64

プレイログを導入しても 『叶えられないこと』 BIOHAZARD RE:2 開発中の プレイログ 65

もとい、課題 • BIOHAZARD RE:2 での 残課題 • 事例として紹介 • 現状ではどのように解決すればよいか分からない • いつか似た事例を解決できるかもしれない 66

プレイログ が “可視化できること” • 可視化できるのは “ゲーム内の事実” • “現実世界のユーザー” の状態までは可視化できない 67

計測の難易度 面白さ 計測 処理負荷 計測 難しい どうすれば面白いか 推測する 頑張れば出来る 位置情報と状況から 推測する デバッグ・品質チェック 易しい・効果が出やすい 裏づけ ひたすら事実を 収集する 68

レベルデザイナ に聞きました • “プレイログ で 知りたいこと” は何ですか？ • 下手な人が、上手になっていった “経緯” を知りたい 69

そもそも、 • BIOHAZARD RE:2 の 上手・下手って？ • 銃をうまく狙える • ダメージを受けない・死なない • 効率よくアイテムを集める・使う 70

“メトロイドヴァニア スタイル” について • データ を収集できる区間を考える ゲ ー ム 開 始 • それぞれの区間を 1プレイ として収集している ゲ ー ム 終 了 ニューゲーム 後 ゲームオーバー コンテニュー 後 セーブ・終了 ロード 後 ゲームクリア 71

ここから見える課題 • “その場所に辿り着いた” 状態が一定ではない • 別の目的で訪れる • 別の敵が設置される • ゲームのプレイ開始と終了は ユーザーの任意 • ゲームの状態は セーブされ、ロードされる • 何度目のプレイか、分からない 72

アイテムの取得について考えてみる • 配置されたアイテムが… • 何回、取得されたかは分かる • 何%の人が意図通りに、取得したかは分からない • そもそも • アイテムを後で拾う人 • 縛りプレイで拾わない人 73

レベルデザインの課題を俯瞰するのは困難 • 俯瞰したデータを見ても “面白さ” は分からない • 効果的に問題点を見つけることは出来ていない • 総合的に “何が問題なのか” は可視化できていない • どう見せるか、何を収集すべきか、まだ誰も知らない 74

まとめにかえて、 啓蒙活動 BIOHAZARD RE:2 開発中の プレイログ 75

今回の成果と、ふりかえり • プレイヤ挙動を収集して可視化して • 従来、感覚・経験でカバーされていた情報が見えた • 可視化することで、連鎖的に収集内容が充実した • 一方で、１人で作業を行うのに限界も感じた 76

新たな課題 • 実装面での課題 • 挙動データを送信する機能をゲームに仕込んで保守する • 複数人で、アイデアを出し合った方がより発展する • レベルデザインの課題を俯瞰する手法の模索 77

“次の作業を教えてくれるデータ”の可能性 • 開発中のゲームがもつ課題とタスク管理を自動化 • “通しチェック” から “タイトルの課題を明確化” • ゲームの安定度 • 敵の強弱、アイテムの配置 • 作業タスクを自動的に作成・割り振りができるのでは？ • 適切な敵の強さ、アイテム量の自動調整 • 通しチェックの 完全自動化 78

質疑応答 時間に入ります • 資料で話したこと • プレイログ を導入した『いきさつ』と『成果』 • 送信内容・タイミング・データの加工 • 実装スケジュール と 時期ごとの注意点 • プレイログ を導入しても『叶えられないこと』 79

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