IkaLog (イカログ) は、任天堂の Wii U 向け塗りシューティングゲーム「スプラトゥーン」の画面を、 HDMI キャプチャデバイス越しに監視して様々なことをするソフトです。ゲーム開始・終了やゲーム中の状況画面認識して、数値や文字列として扱えるようにする認識処理、そして、その認識結果を CSV, JSON, Twitter, Slack, Fluentd, またスプラトゥーン戦績専用 SNS とも言える stat.ink に投稿する機能などをプラガブルに実装できます。
IkaLog 開発開始のきっかけは INTEROP の会場で知人と会ったことでした。帰りに秋葉原付近で夕飯を食べている際に世間話をしていたらスプラトゥーンに興味を持っていたことがわかり、
「これはもうアキヨドで WiiU とスプラトゥーンを買って帰るしかないですね」
「えっ... それは.... でもまだプレイする判らないし。」
「でも判ってからでは間に合わないかもしれないですよ！」
「プリフェッチですか！間に合わないのはまずいですね、、、。」
という会話でスプラトゥーンにはめ、後日のモツ鍋では
「スプラトゥーン、その後どうですか？」
「がんばってます。全試合記録を取ってるんですよ (Excel ファイルドヤァ)」
「ｗｗｗｗｗｗｗ」
という会話からスプラトゥーンの機械学習や画面認識を話だけで鍋がからっぽになり、その日から開発の検討をはじめました。最初はゲーム開始・終了時のフレームを各一枚認識する程度でしたが、いまではゲームの進行がある程度リアルタイムに解析できるようなものになってきました。
今回、プレゼンテーション枠をもらったときに何も話をしようか悩んだのですが（Fluent-bitまわりの話をしようかとも思った）、プライベートプロジェクトとしてはいちばん時間をとっているのが IkaLog だし、 IkaLog の紹介をすることにしました。
ただ、ささみの会は、経験上ITインフラエンジニア、ネットワークエンジニア、セキュリティエンジニアなどが参加していることが多いのです。今回ははせがわようすけさんというガチエンジニアが登壇するというものの、突然ゲームの画像認識の話をして外してしまうのもアレなので、画像認識のしくみやアルゴリズムの話に寄せることにしました。結果として、セッション中に眠くなってしまった人たちを、突然の機械学習の話とデモでたたき起こして最後まで突っ走ることができました。
IkaLog の画面認識は、それほど難しいことはしていません。フォアグラウンド、バックグラウンドを白・黒にわけた画像ファイルと、フォアグラウンドとバックグラウンドがどのような色であるか、という情報をもたせておいて、期待値にどれだけ近いかでマッチングしているのがほとんどです。文字（列）、ブキ画像の認識には機械学習を使っていますが、使っているのはK近傍法と呼ばれる、機械学習のなかでもいちばんシンプルなアルゴリズムで十分実現できています。画面認識とか機械学習とかにまじめに取り組んでいる方からすればお粗末な内容ですが、まあ、こんなやり方もあるんだよ、と、知らない人に知ってもらえたなら、それでいいかなと思っています。
はてなブックマークや Twitter などで見つけたコメントにちょっと思ったことを書いてみると
ただのモツ鍋の人ではなかったのか @hasegaw …すごすぎ（震
ワタシ、イカログ チョットツクレル
環境構築がめんどくさい
当初 IkaLog は GitHub から拾ってきて Python3 環境で実行するしか利用する手段はありませんでした。HDMI キャプチャデバイスに加えて Python3, OpenCV 、そのほか Python モジュールを揃えるというのはエンジニアでない人にとっては無理に等しいかと思います。もともと IkaLog は完全にコンソールアプリケーション（しかも設定は Python 直書き）だったのでユーザが大変限られていました。
そこで、敷居を下げるために wxPython を利用した GUI フロントエンドを追加して、設定を yaml ベースで保存・読み込みできるようにして、 py2exe で Windows アプリケーションの形態にすることで多少敷居を下げる努力をしました。その際には、正直、わたし自身としてはまったくもって不要な機能ですが、 py2exe すると requests モジュールが壊れて使えなくなるのを密かにパッチして対応していたり、 OpenCV のビデオキャプチャ機能がタコなので、 OpenCV の機能を使わずにキャプチャデバイスを列挙するためのライブラリを別途準備して DLL 化し同梱したり、といった対応を行っています。
これでもまだめんどくさいようで、自分の努力がまだまだ足りないんだなと思っています。（嫌味とかではないです。仕組みなど的に、中々ハードルを下げきれないな、と。）
OCR ではスプラトゥーンの独特のフォントを誤認識するのか
手元のテストではスプラトゥーンの独自のフォントをベースに OCR ソフトをトレーニングした状態で評価を行ってきました。しかし、文字数が少ないデータを処理すると、 OCR ソフトが文字の大きさや向きなどの検出に失敗して読み取れなかったり、3と8と0を間違えたり、1と7を間違えたりする現象が多発しました。大きめの文字ならよいのですが、画面上に（K/Dで）出てくるもっとも小さい数字の認識率は相当低く実用的だとは考えられませんでした。
もうすこし OCR まわりの背景について説明すると、 TesseractOCR 自体に手を入れるかどうか悩みましたが、三つの理由でその方針はやめました。ひとつ目は、１〜２桁の数字がそのまま読み取れなかった事です。経験上、数字の列を確実に見つけて読み取らせるには最低限４桁必要であることが、試行錯誤の結果としてわかっていました。しかし、読み取り率を上げるための事前処理で桁数を増やした画像を作って、読み取り結果から不要な情報を省く処理を毎回するのはコードの維持的にかなり厳しいです。
二つ目は、ガチなOCRエンジンに対して私が手を出したところで、今後認識率の問題に遭遇したときに私が問題に対処し続けられるかどうかというと自信がなかったからです。三つ目は、Python3 で書かれている IkaLog から tesseract を呼ぼうとすると自分で binding を整備するか、子プロセス呼び出しで頑張るしかなく、現在エンジンがシングルスレッドで動作している IkaLog にとっては OCR エンジンとやりとりしている時間がもったいないのです。これらの理由から TesseractOCR にこだわらずに別に OCR エンジンを探してみたり、 OCR 関係のアルゴリズムを色々あさったりしていました。電車の中でペーパー検索したりとか。
はせごーさんの本気を見た、、、
今回のネタは楽しみながら本気を出しました。私がこれ以前に Windows 向けでソフトを公開したのは 2002年、まだ Windows 向けに iTunes がなかったころに自分で iTunesDB や MPEG1.0 Layer 3 、ID3などを解析して、ドラッグアンドドロップで iPod に曲を転送できる dogpod というツールを作っていました。それ以来の新作ってかんじなので約 12 年ぶりぐらいに、公開して使ってもらえるようなソフトウェアを書いて、表に出してるのですが、楽しみながらやっています。
しょーもない事に必死になるエンジニア ワロタ。 ただ、湧きだすモチベーションをしっかりと形に落す事は重要。 このノウハウが色々なプロジェクトに活用できる。イカ恐るべし
しょーもない事に時間を費やしてしまって、すみません。けっこう時間をかけて作ってしまいました。
先述のとおり、ささみの会の参加者はいわゆるSI系のITエンジニアが多いわけです。その人たちに50分に及んでスプラトゥーンの話をしても業務に役立ててもらえないだろう、という葛藤もありました。実際、会場にはスプラトゥーンのプレイヤーは私を除くと２人しかいませんでした。そういう状況でも時間を割いてくださったエンジニアの方々に楽しんでもらえるよう、機械学習やOpenCVの話をスライドに盛り込みました。なので、どちらかというとアルゴリズム的な話に時間を割いています。結果として機械学習などへのとっかかりとなってもらえれば幸いです。
ところで、ささみの会ではオーディエンス＋運営スタッフ＋スピーカーで合計60名前後の時間を各50分いただきました。つまりは0.3人月ぶんの時間をこのプレゼンテーションでリアルタイムに奪ってしまったことになります。さらに Slideshare へのアクセスは最初の 24 時間で 35000 を超えてしまいました。合計70枚のスライドを秒速1秒でめくり続けたとして0.4人月、でも、さすがにそれほど速くは読めないでしょうから、スライドあたり２秒かけたとして少なくとも0.8人月の時間を、公開から24時間の Slideshare アクセスで閲覧者から奪ってしまったことになります。
結果として、このしょーもないプレゼンから24時間で1人月以上の時間を奪ってしまいました。私が IkaLog にかけた時間よりも多くの時間を費やしてプレゼンをご覧いただいた皆様には大変感謝しておりつつ、こんな内容で人の時間を奪うことに責任を感じています。
それではみなさん、よいスプラトゥーンライフを。
