2015年5月に発売された大人気ゲームスプラトゥーン、皆さんはプレイしていますか？ 著者のまわりでは多くのコンピュータエンジニアが楽しんでいます。私は、スプラトゥーンの動画をリアルタイムに分析するソフトウェアIkaLogを開発し、オープンソースとして公開しています。本連載では、IkaLogの開発秘話（？）や画像認識に使っているアルゴリズム、開発の過程などについて紹介します。

今回は連載第1回目として、私（たち）がどのようなきっかけからIkaLogを開発し始めたのかを紹介し、次回以降では具体的にどのような検討を経てIkaLogが実装されてきたかを説明します。

スプラトゥーンとの出会い

私がスプラトゥーンというゲームを知ったのは、発売が数日後に迫った日にインターネット上でトレイラームービーを見かけたときでした。スプラトゥーンは、三人称視点（TPS）でプレイヤーのインクリング（イカ人間）を操作し、ステージを自分のチーム色のインクで塗りつぶしてナワバリを広げていくゲームです。インターネットを介して国内ないしは全世界から8人のプレイヤーが集まり、ステージを塗り合う「ナワバリバトル」を繰り広げます。また、ステージ中のごく限られた一部に設定された「ガチエリア」の占有率を競ったり、目標物を相手チームの陣地に押し込む「ガチヤグラ」や「ガチホコバトル」と呼ばれるガチマッチモードも存在します。

見た瞬間に、「⁠これは絶対に面白いな」と思い、発売と当時に購入しました。

従来のFPSやTPSは実在兵器、もしくはSF的な武器が登場することが多いなか、スプラトゥーンではさまざまな色のインクが飛び出す「ブキ」を持って戦いに挑みます。そのブキも、シューターをはじめ、ローラー、バケツ、そして筆タイプなど多岐にわたります。

現実世界では殺傷力がなさそうなインクを使った対戦ゲームというのは、任天堂のWii U向けソフトらしいなと感じます。しかし、ガチマッチでは、おおまかにC、B、A、Sの4段階の「ウデマエ」と呼ばれるレーティングシステムでプレイヤーの強さが表されます。ウデマエは1回のゲームに勝てば上がり、負ければ容赦なく下がります。あなたの身近にいるスプラトゥーンプレイヤーも、より高いウデマエを目指して、さまざまな戦略や戦術、ブキの使い方を研究していることでしょう。

きっかけはモツ鍋

ゲーム発売から約2週間後のこと。

とあるIT業界のエンジニアとモツ鍋を食べていたところ、「⁠スプラトゥーンでの勝敗をすべてExcelのスプレッドシートとして残している」という話を聞いて衝撃を受けました。「⁠ゲームのためにそこまでのするのか」という思いのほか、「⁠とてもマメだな」と思いました。スプラトゥーンのプレイは1回あたり3～5分程度。全ゲームを記録するということは、3～5分ごとに試合結果をメモしていることになります。私にはとても真似できそうにありません。しかし、話によれば、ゲームの試合結果をたくさんメモしていくと、以下のような傾向が見えてくるのだそうです。

ステージの得意／不得意

• スプラトゥーンには戦いの舞台となる“⁠ステージ⁠”が合計14存在する。
• ステージごとに、自分の勝率の傾向が異なる。

ルールの得意／不得意

• ナワバリバトル／ガチエリア／ガチエリア／ガチホコバトルの各ルールで勝利条件が異なり、ゲーム中での立ち回り方にも違いがある。
• ルールごとにも、やはり、プレイヤーの勝率が変化する。

ブキ

• スプラトゥーンの世界では約70のブキがあり、自分の得意／不得意なブキ、一般的にステージで有利／不利と言われるブキがある。
• このため、やはり、自分が使用するブキによって勝率が変化する。

相手を倒した回数／倒された回数

• プレイヤーが操作するインクリングは、相手チームに“⁠倒される⁠”とタイムペナルティが与えられ、さらにスタート地点に戻される。その間、ステージを塗ったり敵を倒したりできなくなるため、劣勢となる。
• 相手を倒せばゲームを有利に進められ、倒されれば相手にゲームを有利に進められてしまう。

このほかにもいろいろなメトリックが考えられるのですが、おもにこのような情報を集計していき、自分の「勝ちパターン」を見つけ、スプラトゥーンの試合で勝率を上げることができるのではないか、というのです。後日、インターネット上でスプラトゥーンに関する情報を調べていると、このITエンジニアのほかにも、ゲームの戦績を記録しているプレイヤーがある程度いることもわかりました。

また、開発開始のきっかけとなった2015年6月は、INTEROPのカンファレンスでChainerが発表されたタイミングでもありました。

Deep Learning のフレームワーク Chainerを公開しました | Preferred Research

https://research.preferred.jp/2015/06/deep-learning-chainer/

カンファレンス会場でChainerを用いたデモを見ていたことから「同様に、ゲーム中のインクリングを“⁠自動操作⁠”できないだろうか？」ということも考えましたが、自分でチャレンジするには流石にハードルが高すぎます。このため、直近で実際に行われている“⁠プレイ記録を残す⁠”部分をソフトウェアで解決できないか検討することにしました。

その日のビールグラスとモツ鍋は、このExcelシートの話などをしているうちに、空っぽになりました。このスプラトゥーン談義から、彼が戦績として残していた情報をできるだけ自動的に記録するプログラムの検討を始めました。

IkaLog、誕生

この夜からさっそく、アルゴリズムの検討を始めました。作成したいプログラムは、「⁠何らかのしくみでゲームの場面を追跡して、目的の情報をログとして残す」という仕組みになります。

スプラトゥーンはネットワーク対戦ゲームのひとつですから、サードパーティーのツールを作成するには、ゲームのTCP/IP通信をキャプチャして解析する方法が考えられます。その他の手段として、狙ったタイミングでうまいことHDMI出力映像のスクリーンショットが保存できれば十分、という考え方もあります。

私自身、10年ほど前にUltima Onlineの通信パケットやデータ構造をひととおり把握し、個人的に追加情報が得られるサードパーティツールを作成していたことがあります。しかし、この方法では、ゲームプレイ時にプレイヤーが目と耳で受け取る情報よりもたくさんの情報が含まれており、ゲームの公平性が失われる可能性があります。また、通信ゲームではチートを防ぐためにペイロードも暗号化されているのが普通です。

2015年、任天堂はGitHub上のプロジェクトに同社の知的財産が含まれていたことを理由にプロジェクト削除依頼を出し、実際に削除されたプロジェクトがあります。同じようなリスクは抱えたくないため、本来ゲーム内にあって見えないデータやコードを探らなければいけないような設計は避けたいと考えました。また、「⁠ツールを作成してほかのプレイヤーに対して有利になりたい」という気持ちもまったくありませんでした。

開発を思いついたタイミングで、手元にはWii Uのプレイ映像をコンピュータ上にデータとして取り込める「HDMIキャプチャボード」がありました。これを使って、映像としてスプラトゥーンの状態を入力し、目的のシーンが表示されたらその静止画像をファイルとして保存する、という程度であれば、それほど難しくなさそうです。「⁠いまならOpenCVなどの画像処理ライブラリがあるから、それほど難しくないのでは？」と安易に考え、「⁠ゲームの画像を認識して、情報を取得する」というアプローチでアルゴリズムや仕組みの検討を始めました。

プレイヤーがふだん目にしている画像に対して処理をしている限りは、コンピュータで分析しても、公平性を保てるはずです。また、動画に対して処理が可能なら、YouTubeやニコニコ動画に投稿された“⁠ほかのプレイヤーのゲーム⁠”を分析対象とすることも視野に入れられます。

開発を思いついてから2ヶ月後、GitHub上でIkaLogプロジェクトを発表しました。

IkaLogの現状

最初のリビジョンのIkaLogを利用したユーザは1～2人だと思いますが、現在では毎日200人以上、ゲーム内のお祭りイベントである「フェス」が開催される週末には1日あたり300人以上が利用するソフトウェアになりました。毎日4000ゲーム以上を分析していることがIkaLogユーザーによる投稿からわかっており、これらの情報から、ステージやルール、ブキの組み合わせでの特徴などに関して非公式な統計情報も得られるようになっています。

また、IkaLogはオープンソースとして公開しており、これまでに14名の方からのPull Requestがありました。

その他にも、IkaLogを利用したスプラトゥーン支援ツールがいくつか作られていたり、IkaLogを使って作られたコンテンツが投稿されたりもしています。

次回予告

今回は、IkaLogの開発を始めたきっかけ、これまでの経緯について、かんたんに紹介しました。

次回以降では、IkaLogの開発過程でどのような学びがあったかを振り返りながら、どのような試行錯誤があったか、どのようなアルゴリズムを検討・利用しているかについて、説明していきたいと思います。お楽しみに。