「スプラトゥーン」リアルタイム画像解析ツール 「IkaLog」の裏側

（ver.1.3） Nov 26, 2015 ＠サイボウズさまオフィスにて Takeshi Hasegawa (@hasegaw)

本スライド中に登場するスプラトゥーン関連画像は任天堂株式会社の著作物からの引用です。

@hasegaw is 誰 長谷川　猛 (HASEGAWA Takeshi) twitter: @hasegaw Ø  もともと、インフラエンジニア(2004-2011)

SEとしてシステム構築、客先のシステム運用、提案 気付いたらプリセールス～PMを担当するインフラエンジニア （ざっくりデザイン、工数／導入物品見積もり、 　構築プロジェクトの管理、保守等の問い合わせ対応）

Ø  フラッシュストレージを軸とした、アプリケーション高速化を支援するセールスエンジニア(2011-2014)

Ø  ファブレス半導体ベンチャーでコンピュータ関連なんでも

2

著書／寄稿

3

記事紹介（？）

4

下記２本の記事(40ページ強)が まとめて収録されました。 ISBN: 978-4774177823 価格: 2,786円 •  Software Design 2014/10

第二特集 サーバの目利きになる方法 前編

•  Software Design 2014/11 第二特集 サーバの目利きになる方法 後編

はじめに

スプラトゥーン、そしてIkaLogとは

スプラトゥーンとは

•  第三者視点(TPS）のシューティングゲームの一種

•  インクで自分たちのナワバリを広げないと進めない

•  シューティングが苦手でも バケツやローラータイプのブキで気軽に楽しめる

•  本気でやってる人たちは怖い

6

スプラトゥーンとは

（ビデオ：会場のみ）

7

IkaLog とは何か •  Wii U用ゲーム「スプラトゥーン」支援ソフト –  HDMIキャプチャを介して情報を自動取得

– 数値・文字列データとして認識

– お好みの方法で 蓄積、出力

8

IkaLog のイメージ

9

HDMIキャプチャ

IkaLog  実行用PC

IkaLog の画像認識例

10

IkaLog の画像認識例

11

IkaLog の画像認識例

12

IkaLog の画像認識例

13

各種ソフトウェアとの連携（デモビデオ）

14

(ビデオ：会場のみ)

プラガブルで様々な使い方に対応

15

録画ソフト 自動制御

AmaRecTV

カラーLED連動

Fluentd  転送

スプラトゥーン戦績記録SNS

CSV/JSONファイル保存 スクリーンショット保存

SNS投稿

IkaLog

Embeded IkaLog （ライブラリモード）

•  IkaLog 自体が Python モジュールとして実装されている

•  Python コードから IkaLog を実行して、情報を受け取れる

•  作ってみたアプリケーションの例

16

アプリケーション 説明

IkaRename.py スプラトゥーンのビデオを分析  ステージ／ルール／勝敗のついた  ファイル名にリネームする

IkaClips.py スプラトゥーンのビデオを分析  敵を倒した／倒されたシーンだけクリップし、  “忙しい人”向けのサマリムービーを生成

IkaLog が出力するデータの複雑化（１）

17

IkaLogの当初のスコープ  ・ステージ／ルール検出、勝敗（２択）  ・スクリーンショット保存

追加された検出内容  ・目標（ガチホコ／ガチヤグラ）の位置検出  ・プレイヤーの死因（凶器）検出  ・時系列のスコア検出  ・プレイヤーのランク、所持金などの数値検出  ・全プレイヤーの生死ステータスのモニタリング  ・ロビー（パブリック／プライベートタッグ）検出   今後追加する（かもしれない）検出  ・コミュニケーション検出（ナイス／カモン）  ・スペシャル蓄積・利用検出  ・目標に対するチームのイベント  

IkaLog が出力するデータの複雑化（２）

18

{'time': 1442394550, 'result': 'win', 'rule': 'ガチホコバトル', 'event': 'GameResult', 'map': 'モズク農園'}

{'rank_in_team': 2, 'weapon': 'デュアルスイーパーカスタム', 'result': 'win', 'kills': 1, 'time': 1444491154, 'cash_after': 1820744, 'players': [{'rank_in_team': 1, 'weapon': 'プライムシューター', 'kills': 2, 'deaths': 1, 'udemae_pre': 'B-', 'team': 1}, {'rank_in_team': 2, 'weapon': 'デュアルスイーパーカスタム', 'kills': 1, 'deaths': 0, 'udemae_pre': 'B', 'team': 1}, {'rank_in_team': 3, 'weapon': 'プライムシューター', 'kills': 1, 'deaths': 0, 'udemae_pre': 'C+', 'team': 1}, {'rank_in_team': 4, 'weapon': 'スプラシューターコラボ', 'kills': 1, 'deaths': 0, 'udemae_pre': 'B-', 'team': 1}, {'rank_in_team': 1, 'weapon': 'ジェットスイーパーカスタム', 'kills': 1, 'deaths': 2, 'udemae_pre': 'C', 'team': 2}, {'rank_in_team': 2, 'weapon': '3Kスコープ', 'kills': 0, 'deaths': 1, 'udemae_pre': 'B-', 'team': 2}, {'rank_in_team': 3, 'weapon': 'プロモデラーRG', 'kills': 0, 'deaths': 1, 'udemae_pre': 'B-', 'team': 2}, {'rank_in_team': 4, 'weapon': 'ダイナモローラーテスラ', 'kills': 0, 'deaths': 1, 'udemae_pre': 'B+', 'team': 2}], 'rule': 'ガチホコバトル', 'event': 'GameResult', 'deaths': 0, 'udemae_pre': 'B', 'map': 'アロワナモール', 'team': 1}

GitHub  イニシャルカット時の IkaLog  が出力した戦績ログ  (JSON)

近の IkaLog  が吐く戦績ログ  (JSON)    ※本当はもっと色々出せる

→  情報量の増加に伴い分析基盤の構築が必要

stat.ink (戦績SNS)

•  IkaLogユーザのひとり @fetus_hina さんが開発、運営する Web サイト

•  IkaLog からのプレイデータを受け取り、表示・集計する

19

20

21

stat.ink （全ユーザのプレイ結果からの統計）

22

ゲームルールによるK/Dと勝率の相関

23

stat.ink （ブキの統計）

24

ステージによって異なる KO勝ち／KO負け率

25

IkaLog + stat.ink のDAU、処理ゲーム数

26

データソース  hJps://stat.ink/enLre/users

【ピーク】  130ユーザ/日  

5,500ゲーム/日を分析

毎日 約70ユーザが利用  24時間あたり2000ゲーム前後を処理

エコシステム

27

ユーザー

開発者

hasegaw/IkaLog

stat.ink

ダウンロード

記録  送信

hasegaw

一部データ  (QA用)  

　開発、  　stat.inkデータに  　　よる機械学習

Windows版  実行ファイル生成

（本スライド中の画像の一部はイメージであり実際のものとは異なります。）

PR

モ  ツ  鍋

開発開始の経緯と 基本的なしくみ

IkaLog開発の経緯

•  スプラトゥーン プレイヤー同士で モツ鍋を食べていたら、戦績の統計の話に

•  ゲームには、戦績の統計機能は存在しない

•  手動でExcelを使い戦績を整理している人も

29

とあるイカの戦闘記録

30

とあるイカの戦闘記録

31

とあるイカの戦闘記録

32

0"

2"

4"

6"

8"

0" 1" 2" 3" 4" 5" 6" 7" 8" 9" 10"

Kill Win/Lose

Win" Lose"

0"

1"

2"

3"

4"

5"

1" 2" 3" 4" 5" 6" 7" 8" 9" 10" 11"

Death����Win/Lose"

Win" Lose"0.0%$2.0%$4.0%$6.0%$8.0%$10.0%$12.0%$14.0%$

*5$ *4$ *3$ *2$ *1$ 0$ 1$ 2$ 3$ 4$ 5$

K*D

スプラトゥーン プレイヤーにとっての 主なメトリック

•  どのステージが得意か？苦手か？

•  どのルールが得意か？苦手か？

•  どのブキが得意か？苦手か？

•  どのブキにやられやすいか？

•  どれぐらい突進していいのか？し過ぎなのか？

33

ツールを作ろう(検討編 1)

720p １プレイ分の動画を相手に検討開始

•  非圧縮 5分 → 20GB

OpenCV のテンプレートマッチングで試行錯誤

•  判ったこと：使えなそう – 誤検出が多い

– マッチングアルゴリズムが遅い

34

ツールを作ろう(検討編 2)

•  もっと単純な方法で画像をマッチングする – スプラトゥーンのシステムメッセージは ほとんどが、決まった位置に白色で表示される

– 文字部分だけが黒く、残りが白い画像を加算し、加算した後の画像のヒストグラムで判定する

– 基本的に足し算、引き算で実現できるため 非常に高速に処理できる

– 画面が真っ白なときに誤動作

→もともと白い画像は無視する 35

IkaLogの画像マッチング (第一世代)

36

ソース映像 マスク画像 加算画像

+ = =

正しいマスクを加算すると画像が真っ白になる

違うマスクを加算すると画像が真っ白にならない

IkaLogの画像マッチング (第二・三世代)

•  第二世代 –  「前景が白」だけでは他の場面で誤認識するケースが 増えてきた

–  「背景が黒」「背景が白以外」のどちらかを 指定して、条件以外のドットが多ければ False-Positiveと判断できるように拡張

•  第三世代 –  「前景がオレンジ」「前景が黄色」などを認識したい ケースがでてきた

–  前景・背景ごとにHSV色成分などをして条件通り・ 条件以外のドットを検出できるように拡張

37

入力画像から目的に色だけを取り出す

38

入力画像 黄色のみ

白のみ 黒のみ

ＲＧＢ色空間とHSV色空間

39

RGB色空間 HSV色空間

数字の認識と機械学習

数字の認識

•  ゲーム中で使われているフォントは２種類

•  画面上に現れる数字フォントは１種類

•  フォントが判っているのだから、 認識できるはず

•  試行錯誤の後、既存OCRエンジンの利用は断念

•  機械学習ベースの認識エンジンを実装 41

既存OCRでの問題点

•  Tesseract OCRを評価 – 認識率が安定しない

– もともと文章を読み取るためのもの

–  1～2文字の文字、数字の認識は苦手

–  0, 8, 3 などを間違えることがある

–  Python 3.x のスクリプト上から 利用しづらかった

•  既存の文章向けOCRエンジンよりも 単純で目的に適した認識方式を検討

42

文字として  認識されないことも

kNN(K近傍法)の考え方

43

● ● ●

●

■ ■

■ ■

? ▲

▲

▲

▲

?

?

?

?

とてもシンプルな機械学習    標本　　　　の傍にあるサンプルがどれかで    分類する。      K=1  の場合は 寄りのサンプルがある  クラスに分類される。      K=3  の場合は近くに3つのサンプルがある  クラスに分類される。

kNNによる図形マッチングの例(1/2)

•  GitHub にソースあり –  https://github.com/hasegaw/opencv_knn_example/

•  三つのパターン ○ △ □ で画像を生成し、 kNNで学習する

•  ランダムに ○ △ □ から画像を生成し、その画像の種類を判定する – KNN を用いてそれに近い画像を見つけ出す

– 見つけた画像の種類から、問題図形の種類を特定

44

kNNによる図形マッチングの例(2/2)

45

問題図形をランダムに生成

K近傍法を用いて、学習済みの  図形から、もっとも近い図形を調べる

仕分ける ○ △ □

○ 学習済み図形

○ △ □

KNNで見つけた「一番近い文字画像」で 画像を置き換え(1/2)

•  各日本語フォント文字をPNG形式に変換

•  上記データをKNNで学習

•  画像を入力しグレースケールに変換

•  画像を文字サイズにあわせて分割、KNNで各領域にもっとも近い文字フォントを調べる

•  画像を文字に置き換え

46

KNNで見つけた「一番近い文字画像」で 画像を置き換え(2/2)

47

48

kNN  による数値認識を実装後、はじめての  テスト結果。１０の位は文字画像の位置ズレで  誤認識が生じているが、１の位は１００％認識  できた

数字の認識 １）画面上の数字部分（位置固定）を切り抜き

２）縦・横のヒストグラムを生成し各文字の位置を特定

３）文字を検出用サンプルのサイズ（等幅）にリサイズ、 二値化

４）KNNにより既知の検出用サンプルと照らし合わせて 認識する

49

死因の認識

死因の認識

51

死因の認識

•  「数値が認識できているから、 　　死因もなんとかなるだろう」

•  数字認識との共通点 – 目的の情報が白色なので二値化しやすい

– 文字列の位置を特定し、切り抜きできる

•  数字認識との相違点 – アニメーションにより、常にサイズが変化

52

死因の認識（３） 死因のリスト

53

死因の認識（３） •  基本は数字の認識と一緒

–  1文字単位ではなく文字列を一組として処理

–  文字列は左寄せして処理（したほうがいいのかはよく判っていない）

•  認識率はそれほど高くないが、認識回数で精度を確保 –  IkaLogは現在毎秒10フレームほど解析している

–  下記例では、死因のメッセージ合計49fを解析し、 最多頻度は96gal_deco (18f, 36%) だった → 結果的に正解

54

votes={      'supershot':  6,    'carbon_deco':  1,    'bucketslosher':  1,  'octoshooter_replica':  1,      'splashshield':  1,  'sshooter_collabo':  5,  'hotblaster':  2,    'pablo':  1,    'nzap89':  6,      'sharp_neo':  3,  'hotblaster_custom':  2,  '96gal_deco':  18,  '52gal':  1,    'hokusai':  1  }

ブキの認識

スプラトゥーンのブキ

•  スプラトゥーンでは、５０種類を超えるブキから 好きなものを選んで利用できる

•  全体的にバランスが取れているゲームだが 戦略や戦術、ブキの選択で優劣が発生する

•  分析したい -> 画像認識

56

スプラトゥーンのブキ画像リスト

57

スプラトゥーンのブキ　５９種類（スライド作成当時）

画像判別においてのチャレンジ

•  ブキ画像が小さい（47x45ドット・外枠込み）

•  表示条件（背景・被る画像）が変わる

•  誤判定すると後の統計結果に多大な影響が出る

•  一回の判定に使えるのは画像１枚のみ

58

他の装備品が被っている 保護色（まだマシ） 保護色（マジつらい）

ブキ認識アルゴリズム（第１～３世代） 世代 特徴、利点 課題

-­‐ すべての正解画像を保持しておき、  入力画像を比較  

第三者著作物のデータをそのままデータに含めて配布する必要があった  

第1世代 画像の色相ヒストグラムを特徴量とした  統計的手法（のちにK近傍法へ切替）。  

認識率　８０％以下

第1.5世代 第一世代の特徴量のまま、分類アルゴリズムをKNNに切り替え  

認識率が若干悪化

第2世代  （現在）  

特徴量を色相ヒストグラムから”画像の複雑さ”に変更  ・ラプラシアンフィルタなどを通して画像の特徴量を算出  ・開発環境で９９．９９％〜の精度を実現  

ユーザの環境（デバイス、設定差異、設定ミス）により認識率が大幅低下

第3世代   CNN（畳み込みニューラルネットワーク）を利用した深層学習  stat.ink投稿データで９９．９７％以上の精度を実現

分類処理に要するCPU時間  学習データのサイズ、配布方法

59

第1, 1.5世代 色相ヒストグラムによるブキ特徴量の算出

60

（まだバグがあった頃のバージョンの表示なので色がずれているけども）  こんなかんじで特徴量を抽出していた

ブキ認識テストの様子（かなり初期）

61

第2世代 ラプラシアンフィルタを用いた特徴量の算出

62

入力画像 ラプラシアンフィルタ適用

グレー  スケール

輪郭情報 特徴量画像  （合計64ドット)  

→  課題が浮かんできた  •  キャプチャデバイスの画質特性により特徴量が変化する  •  WiiUの出力解像度  (720p/1080p)  により、  

特徴量に差異が生じる  •  ユーザがキャプチャ関連ソフトでWiiU画像を間接取り込みし  

本来のWiiUの信号とは異なる解像度、オフセットで入力され、  特徴量が変化する  

Thanks  @itooon

新しい特徴量算出方法での分類結果（１）

63

新しい特徴量算出方法での分類結果（２）

64

テストデータは12000弱  正解の一覧は作っていないので目視で確認  

多分、分類できている  

想定通りの特徴量となるケース、 ならないケース

65

IkaLog内部処理フォーマット

ユーザが縮小した画像

720p

???

1080p

720p

ユーザから投稿されるデータの例 （解像度の違い）

66

第3世代 - 深層学習によるブキ判定

67

Thanks  @itooon

第3世代 ‒ 深層学習によるブキ判定

•  CNN を用いてブキ画像を学習(AlexNet, GoogleNet)

•  Caffeで動作確認後Chainerベースで再実装 –  IkaLogが使うPython3ではCaffeが利用できない

– WindowsでのCaffe利用が難しい

–  Chainer on Python3ではCaffeモデルが利用できず、 Chainer + Python3 で改めて実装、学習

68

Thanks  @itooon

第3世代 ‒ 深層学習によるブキ判定

•  驚異的な正答率 – 様々なユーザが投稿した数万ブキ画像の クラスタリングでほとんどミスなし（3０件以下）

•  学習はGPGPU必須、マッチングはCPUも可 ~300ms(CPU)

~200ms(CPU w/Intel MKL)

~50ms(GPU) 程度

8枚の画像が3秒以内に認識できれば十分現実的

69

Thanks  @itooon

第3世代 （CNNベース) ユーザ環境への導入に向けての課題

•  モデルデータの肥大化が課題 400MB~ (AlexNet)

100MB (GoogleNet) ←→ 1MB (KNN)

配布方法は？コスト対効果は？

•  CPU性能が確保できない場合は？ – Core2世代などの非力なプロセッサの場合

– ストリーミングソフトウェア、 ソフトウェアビデオエンコーダとの共生

70

第3世代 （CNNベース) 機械学習への利用

•  CNNベースのほうがKNNベースより正答率が高い – KNNベースの教師有り学習は手作業での分類などに手間がかかる

– KNNの教師有り学習にCNNの分類結果を利用できれば手作業を減らすことができる

•  CNNでユーザーの投稿データを分析し、 KNNのモデル生成に活用することも検討

71

Webcam サポート

※ ソースコードは GitHub にありますが、現在開発中の 　 機能であり、一般ユーザー向けには提供していません。

Webcamサポート

•  HDMIキャプチャデバイスを持っている人は少ない – ゲーム実況をするニコ生主などなら 持っているが…

– 新たに購入しようとすると、約２万円の投資

•  HDMIキャプチャの代わりにWebカメラを利用できないか?

73

Webcam サポート（イメージ）

74

1)  TV、ディスプレイに  Webcam  を向ける  2)  WiiU  のホーム画面を表示  

3)  IkaLog  で  Webcam  を介して　　ワープ キャリブレーション  4)  以後 IkaLog  は画面と認識した範囲に対して処理を行う  

Webcam経由の動画サンプル

（会場のみ）

75

OpenCVサンプル　find_obj.py (1)

76

OpenCVサンプル　find_obj.py (2)

77

HDMIキャプチャと間接キャプチャの比較

78

HDMIキャプチャ  (H264録画) Webcamによる間接キャプチャ  雑なカラーコレクション適用済み

Webcam経由の入力状況

•  「既知の画像」（WiiU ホーム画面）を 画面上に出して、キャリブレーション

•  720p (1280x720) の画面を ±5pxぐらいの精度で取り込める

•  白色が (255,255,255) にならないため 何らかの対策が必要 – カラーバランス、ガンマ調整

–  IkaLog 内の画像検出のスレッショルド変更 79

Webcam 対応の課題点と これまでに得られた知見

•  もし、このような「変な使い方」をするときは 自動調整機能をオフにできるWebcamがオススメ – カラーバランスが固定できること

– コントラストが固定できること

– オートフォーカスをオフにできること

•  プラズマTVは明るすぎて Webcam の ダイナミックレンジが追いつかない？ EL液晶は？

•  新しめのスマートフォンのカメラも非常に優秀

80

よさそうな WebCam の一例

81

Logicool  の  Webcam  はカラーバランス、コントラスト、フォーカスを  固定できるのでこのような用途に向いている（アキヨドで試して購入した）  

 ただし上記の固定機能は  Windows  専用。  Mac  では実装されていない（怒

まとめ

82

画像処理のノウハウ •  OpenCV 3.0で高速に

マスク処理、スコア算出 •  スプラトゥーンの画面は

検出しやすい （ほぼ位置固定・白色文字）

機械学習すごい •  K近傍法は簡単に使える •  特徴量の計算方法が ポイントになる

そのほか •  情報の見える化、大事 •  一人では全部できない •  スプラトゥーン楽しい

質問タイム？

83

らぴす  (2000-­‐2014)

マンメンミ！ (ありがとうございました）