ゲームプラットフォームとしてのSlack


この記事は、 Slack Advent Calendar の19日目です。

Slackは、ゲームプラットフォームだ

最近、よくSlackをチームのチャットツールだと誤解されている方をお見受けしますが、皆本質を見誤っていると言わざるを得ません。Slackがチャットツールではなく、ゲームプラットフォームだという理由は、次の点から明らかです。

  • Emojiという美麗なグラフィックのアセッツ、しかもどれだけ登録しても無料
  • Emojiのサイズが統一的で、ドットとしての役割も果たす
  • テキストベースの複雑なコマンドも入力可能なコントローラ
  • ユーザー識別も可能なので、複数のコントローラでマルチプレイも可能
  • 画面描写がシンプルなので、難しいことを考えずにただ更新前と更新後の画面を用意するだけ
  • あといろいろと

以上のように、Slackがゲームプラットフォームだということは疑いようのない事実ですが、その反面ゲームプラットフォームとしてはやや機能が不足していると思われる面も少なくありません

  • 音を鳴らせない
  • FPSが低い
  • Directなんとかとまではいかないものの、なんか微妙に不便でよくわからないAPI
  • あといろいろ

まあなんというか、Slackはゲームプラットフォームなのに割とゲームを作る能力としては低いです。むしろ最近は、副産物としてのチャットツールの方を成長させようと躍起になり、ゲームプラットフォームとしての本分を忘れ去っているように見えます。

Slack Game

そんなSlackを、ゲームプラットフォームとして活用するために足りないのは何かと考えたところ、どうやら啓蒙活動が足りないように思えました。そう、Slackをゲームプラットフォームとして便利に利用するフレームワークが無いのです。

そこで、作りました。

slack-game

Slack上でゲームを作ることを支援する、RubyGemです。

How to use

とりあえず、手っ取り早く説明するために、デフォルトでデモとして入っているライフゲームを動かします。

lifegame

なんとなく、雰囲気はつかめてもらえたのでは無いでしょうか?

次に、最も簡単なサンプルをGistに用意しました。SlackGameのgemの中に用意されている、Demoというゲームを解説するために、適当に作りました

コード自体はこんな感じ

 

簡単な解説も付け加えておきます

  • SlackGame::Controllerクラスを継承して、commandに識別子と正規表現を渡す
    • 正規表現にマッチするmessageが入力されると、識別子がControllerに記憶される
    • takeメソッドを使って、その識別子を取り出す
  • SlackGame::Canvasクラスを継承して、dotに識別子と、その識別子に対応するemojiを渡す
    • Canvasクラスは、NxMのドットマトリクスを持っていて、drawメソッドでemojiの文字列に変換できる
    • それを、Slackに書き出すことで、NxMのドットのキャンバスを作成する
    • ENV[‘DEFAULT_SPACE’]に設定したものが、デフォルトの空白emojiになる
  • 適当なクラス内で、先に作ったControllerとCanvasをインスタンス化する
    • main_loopメソッドで、Controller.takeを呼び出し、入力されたコマンドを得る
    • コマンドに対応し、Canvasを操作し、再描写する

このデモでは、l(left), r(right), u(up), d(down)の入力をSlackへの入力から取得し、キャラクターを動かして画面を再描写する簡単なゲームです

このように、SlackGameを使うことで、ドットを使った簡単なゲームを作成することが可能です。

免責

SlackGameは、基本的にSlackAPIを連打します。RateLimitに引っかかってなにか泣きを見ても、私は一切の責任を負いません。

言い訳

1ヶ月ほど前に、お酒を飲みながら作ったコードなので、いろいろと内部は綺麗ではありません。あまり参考になるコードは無いと思います。

これからは心を入れ替えて、真面目にコードを整備するので、いつの日かきちんとしたコードになると思います。

他の頭おかしい方々

Vim scriptによるゲームの新アーキテクチャの考察


カテゴリー: 未分類 | コメント / トラックバック: 0個

Deep learning で、全ニコ生番組をリアルタイムで監視するシステム作ってみた


この記事は、ドワンゴAdvent calendar(表)の15日目の記事です

ドワンゴでエンジニアをしている @kinoppyd です

TL;DR

ニコ生を監視し、新しく始まったユー生を定期的に視聴し続け、Deep learning Framework の Caffe を使って画像認識し、何が放送されているのかをリアルタイムに知るシステムを作りました。

注意:この記事の中で使っているニコ生へのアクセス方法に関しては、すべてGoogle検索で分かる範囲の情報を使っています。開発者として知っている情報は一切使っていないことを明言しておきます。また、そこそこの数のリクエストを飛ばすので、真似してニコ生側から垢BANされたとしても、一切の責任を負うことはできません。

何の話か

弊社では、なんか人工知能のラボが立ち上がるくらい、人工知能や Deep learning への関心を高めています。毎日サラッとみんなDLの話をしているのに、私自身はDLをまだ利用したことが無かったので、体験してみたくなって作ったという話です。

残念ながら、DLにあまり造詣が無いので、DLの仕組みやチューニングの話は、この記事ではトピックに上がりません。

ともあれ、DLといえば画像認識の話をよく聞きます。画像に何が映っているのかを、かなり高い精度で理解することが出来るデモを幾つか見たこともあります。そこで、生放送のようなリアルタイム性の高いサービスをリアルタイムに画像認識し、何が映っているのかをリアルタイムに認識させるのは面白いんじゃないか? そうだ、せっかくだし今やってる番組全部解析させてみればいいかな、と思ってこのシステムを作ってみました。

建前

画像認識を使ってニコ生の全放送を監視することによって、ニコ生では今何がトレンドで、どういう放送が人気を集めるかということを可視化して分析するツールが作りたかった。

本音

猫が出てくる生放送をすぐに知りたいんだよおおおおお仕事中に猫の映像を見てなごみたいんだよおおおおおお

構成

構成図は、なんかごちゃごちゃしてますがこんな感じです

niconama-watcher.001

流れとしては、ユーザーがブラウザで見るニコ生のストリームを直接CLIで受け取りながら、ffmpegを使ってストリームのスクリーンショットを取得し、それをCaffeで画像認識した結果を取得します。

各パーツはそれぞれ Docker で構築されていて、ストリーム監視とキャプチャ作成に関しては、WebAPIのリクエスト経由で、都度Dockerコンテナを立ち上げて処理をしています。

Docker

各部分は微妙にセットアップが曲者揃いのソフトウェアばかりなので、それぞれDockerを使ってセットアップしました。

このうち、Caffeとffmpegに関しては、すでにImageが提供されているので、docker pull してくるだけで利用できます。ストリームを取得してくる部分に関しては、Ubuntuの公式イメージをベースに、自作のスクリプトをGistに置いてDockerfileに取得してきたり、必要なツールを入れたりしたものをbuildしています。

Caffe

画像認識に特化したDeep learning framework と聞いています。正直、まだはじめて日が浅いため、全く見識はありません。

今回の画像認識は、リファレンスの学習済みモデルを使用しました。分類とかはかなりイマイチですが、他の学習済みモデルを入れて動作確認する時間が無かったこと、猫を探すだけならリファレンスでも足りるだろうということで、そのままです。

Dockerを使って、既に構築済みの Caffe 環境をそのまま手に入れられますが、なんか古いみたいでいろいろと手を入れる必要がありました。Yahoo!の記事をベースに参考にしつつ、そのサポートという形で複数の記事を参照しました。

Caffeで手軽に画像分類

Caffeで機械学習 -1- リファレンスモデルを使って画像をカテゴリ分類

『Caffeで手軽に画像分類』が手軽にできない。

OSX10.10でCaffeをインストール、リファレンスモデルで画像を分類

本当であれば、このすごいエントリを見て感化されたので Google Cloud Vision API を心の底から使いたかったのですが、一週間ほど前に利用申請を出しても今日の今日まで完全にガン無視されてしまったので、泣く泣く自前で Caffe のサーバーを立てて使います。Cloud Vision API を使ってみたかった……。Cloud Vision API を本当に使ってみたかったから、残念で仕方ない。悲しい。つらい。

ffmpeg

ニコ生は、Flashを使ったFLV形式で放送を配信しているので、それをキャプチャするためにffmpegを使いました。これも普通にセットアップするのは面倒ですが、Dockerを使ってコマンドを実行するごとにコンテナを立ち上げれば非常に簡単に使えました。

ひとつはまった点として、ドキュメントのとおりにキャプチャを作成すると、引数の順番の関係で一度flvを再エンコードしたうえでキャプチャを生成するので、非常に遅くなるということでした。下記のQiita記事を参考に、リアルタイムで切り抜けるようになりました。

FFmpegことはじめ

ニコ生を監視し続ける部分

ここに関しては、いくらGoogle検索で集められる情報とはいえ、あまりおおっぴらに書くものでも無いので割愛します。ただ、安定して動かなくて困ったという感想だけ。

Sinatra+Unicorn

それぞれのDockerを制御するために、WebAPIを用意しました。リクエストを受け取りDockerを起動させるものや、起動しているDockerの中でなにか処理をしたりと様々ですが、それぞれの受け口をすべてをSinatra+Unicornで手っ取り早く用意しました。Sinatraは、単一機能の簡単な処理をするAPIなどを作るときに、非常に簡単に記述できます。Unicornを使っているのは、複数のWorkerを手軽に立てたかったからです。

  • ニコ生番組のIDを受け取り、監視用のDockerを起動するAPI
  • ニコ生番組のIDと秒数を受け取り、ストリームの指定の秒数をキャプチャするDockerを起動するAPI
  • 画像を受け取り、Caffeで画像認識を行った結果を返すAPI

以上の3つを作成しました。番組の監視とキャプチャは、Dockerコンテナを起動することが目的なので、Dockerのホスト側で動かしています。それに対して、Caffeの画像認識は、既に起動しているDockerのコンテナ内で、画像を受け取り認識するために動作しています。

Ansible

各サーバーのプロビジョニングには、Ansibleを使用しました。基本的に、サーバー側での作業はDockerをインストールして、イメージをビルド、あとはUnicornを走らせる環境を用意するだけなので、シングルファイルのPlaybookで十分足ります

全生放送を監視する関係上、番組を監視する部分にトラフィックがかかるため、今回は10台の監視サーバーを用意しました。そしてそれに合わせて、毎秒大量の画像認識のクエリが発行されるため、Caffeのサーバーはコアとメモリの大きめのものを2台用意して、中で複数台のコンテナを立てて、画像を受け取り分析しています。

ConoHa

インフラストラクチャには、このはちゃんを使用しました。なんでかっていうと、このはちゃんのファンだからです。本来ならば、AWSのGPU付きサーバーを借りるのがベストだとは思いますが、トラフィックの料金の見積もりが微妙に心もとなかったのと、学習済みモデルを使うので別にGPU使うほどでは無いだろう、というのが理由です。ただ、やはり学習済みモデルを使っても、画像認識にはかなりの時間がかかったので、素直にAWS借りておけばよかったと後悔しました。

実行

実際には、このシステムで1日中ずっとニコ生に張り付き続けていると、普通に攻撃していると受け取られてBANされかねないので、30分だけ全番組監視システムを作動させてみました。また、毎秒のキャプチャを解析していると全然マシンリソースが足りないので、5秒に1回に設定しています。とはいえ、同時に数百の番組の1シーンを解析すると、それでも5秒程度のインターバルでは足りないと思いますが……

ニコ生では、だいたいピーク時間で2000番組前後のユーザー生放送が同時に放送されていますが、そのうちシステムを起動した時間以降にスタートした番組を監視します。

結果

大変悲しいことに、猫は見つかりませんでした……

一応、猫と判定された画像は2枚あったのですが、ポケモンのプレイ画面とFPSのやたらブレた画面で、一体何がどういう理由で猫と判定されたのかは不明です。

正直、1枚くらい猫が見つかってくれると思っていたので、悲しい気持ちでいっぱいです。

とはいえ、猫が見つからなかっただけでは結果としてアレなので、大量の画像認識の中で一体何が最も多く検知されたのかを見ていきたいと思います。

以下が、 Caffe のリファレンスモデルを使ってニコ生をリアルタイム監視した結果、最も多く得られたクラスの上位です

420 web site, website, internet site, site
370 scoreboard
166 bubble
110 toyshop
107 television, television system

1位の Web Site というのは、だいたいデスクトップをキャプチャした放送や、ゲーム配信で多く見られました。どうやら、画面を操作するためのアイコンがやメニューが並んでいる様子が、ブラウザに見えるようです。

2位の Scoreboard も同様に、ゲームのリザルト画面や、普通のゲームの画面のがチョイスされていました。おそらく、数字が規則的に並んでいるためにスコアボードと判定されたのだと思います。面白いところでは、麻雀のゲーム画面がスコアボードと判定されていました。

3位の Bubble はなんだかよくわかりませんでしたが、なんか丸っぽい線が多く現れている画像に多かったです。PS4の配信禁止中の画像なんかは、だいたいこれに引っかかっていました。

4位以下は、正直もうなんだかよくわかりません。

また、 Caffe は画像認識をした結果、マッチ率のようなものを%で出してくれるのですが、これもほぼ頻出上位とかぶっていて、微妙でした。

感想

ニコ生を Deep learning してみた結果、とりあえずゲーム配信がすごく多いというのはわかりました。キャプチャした画像を並べて観ているだけで、ああゲームばっかりだ、という感じです。PS4配信などで簡単にニコ生で放送できる手軽さが影響しているのかも知れないし、もともとそうだったのかも知れませんがよくわかりません。

技術的な感想。

大量のコンテナを立ててみたけれど、やっぱり Caffe で画像認識するところがものすごい詰まります。このボトルネックに引っ張られて、数百番組のリアルタイムの監視とは程遠い速度でした。数十程度ならリアルタイムで監視出来ると思うので、実用的には Caffe を動かすマシンに GPU を使い、もっと後ろに大量に並べるべきかなと思います。また、ニコ生を監視する部分も全然足りてませんでした。1サーバー数十番組くらいイケるかと思いましたが、裏の画像認識部分が詰まっていたので、引っ張られて監視部分も完全に詰まってました。

Ansible+Docker構成なので、横にブン並べるだけであれば札束で殴ることも可能です。ですが、そうすると今度は全体を制御する部分にものすごい負荷がかかります。今回は、各APIをコントロールしていたのは手元のホストマシンで、Rubyで書いたスクリプトで大量のスレッドを生成して各監視サーバーにクエリを投げて回してました。実際に数百番組を同時に監視するのであれば、やはりメッセージキューイング等の非同期クラスタで本格的な対応が必要だと思います。

膨大な情報量に対して、多少こちらの準備が甘かったため、やや残念な結果に終わってしまいましたが、まともなジョブ管理と札束があれば、意外と実用的に全ニコ生監視システムが作れそうな実感はありました。

ソース類に関しては、4日ほどで作ったためかなり荒削りなところが多いことと、普通に公開するとやっぱり怒られそうな気がするので、ある程度整備したうえで問題なければ後日に公開しようと思います。

ひとまず、 Deep learning に触れてみるという目的を達成したので、満足しました。


カテゴリー: Debian, Linux, Ruby, プログラミング, ポエム | コメント: 2 件

劇場版ガールズ&パンツァーを観てきた


神だった

これはすごい、最初から全力の、最後まで総力戦って感じだ。もう1回、いやもう何度か観なくては……


カテゴリー: 未分類 | コメント / トラックバック: 0個

Spectre 007 を観てきた


James Bond が大好き

ジェームズボンドシリーズがとにかく大好きで、しかもリブート後初のスペクター登場ということで楽しみにしていた。

とりあえず、観た感想としては、これはロジャームーア時代の007クオリティだわ、って感じだった。さすがに、ロジャームーア以降最高の駄作ダイアナザーデイを超えることは無かったけど、クレイグボンドでは最下位の出来。

楽しめたところとダメだろと思ったところが半々くらいで、まあこんなこともあるよね、って感じの普通の007映画。

とりあえず、車のエンジンが唸る音はもっと聞かせて欲しかった。せっかくのアストンマーチンDB10なのだから。

 とりあえず、あと1回くらい観に行こうかな

007そのものの大ファンなので。

ほんの少しだけネタバレ感想

あのすげえタフな悪役、ジョーズじゃねえのかよ


カテゴリー: ポエム | コメント / トラックバック: 0個

serial experiments lain を観た


動機

先週、一連のキルミーベイベー騒動で、AmazonビデオのDL済みコンテンツすらリモートで削除されたという話を聞いた。

デジタルメディアの購入者は作品を所有することができず、ただ観る権利を与えられているだけであり、その権利はいつ剥奪されてもおかしくない。そういうことを改めて再認識すると、いま手元に所有していない作品はいつの日か突然触れることができなくなってもおかしくない、という焦燥が浮かんできた。

なので、せっかくの祝日だから、今まで観たいと思っていたけど観れていなかった作品を観ようと思い、ずっと観たいと思っていた serial experiments lainを観た。

https://youtu.be/Bb1bXNI4mUQ(バンダイチャンネルで公開されている無料の1話目)

購入

バンダイチャンネルで全話パックを購入し、その日のうちに全部観た。

感想は、最高だった。

現実とワイヤードの区別がつかなくなるタイプのSFだという予備知識はあったので、その設定の時点で絶対に外れないとは思っていたけれど、最高に良い。

以下ネタバレ

映像

作品の時代設定はいつなのかわからないけど、高度にネットワーク化された世界観と、スマホ(っぽいもの)を使ってどこからでもアクセスできるという現代に近い未来を、1998年の時点でよく見通していたな、と感心する。

映像も良い。攻殻機動隊から影響を受けているのか、それとも90年台のアニメ制作技術が全体的にそうなのかは知らないけど、白飛びするほど強烈に光を強調した画面や、異様に暗い画面が多くて、サスペンスやホラーの雰囲気を匂わせる世界観とよくあっている。しつこすぎるほどに何度も繰り返される映像や、電柱や電線が暗喩するネットワーク、ワイヤードのイメージが強烈に頭に残っている。

あと、これも攻殻機動隊っぽいなと思ったのは、やたらと窓を強調する。真っ暗な部屋に、明るすぎるほどの光が窓からだけ入り込む構図が多くて、自室で目覚めた少佐の姿が頭の片隅にずっと浮かんでいた。

おそらく、作画の都合等の面も大きいのだろうけど、人物の顔がアップで長時間カメラが回されるシーンが多くて、それもまたサスペンス的怖さを観ている側に打ち込んでくる。背景もかなり簡素化されている場面が多くて、奇怪な印象が更にストーリーを不気味に感じさせられ、予算の都合をここまでうまく演出として使い切る、ものすごく良く出来ていると思った。

ストーリー

どこにでも偏在する私、誰かの記憶の中で生まれて、それが現実に受肉する、という根底の設定が最高に良い。

個人を個人たらしめるものは、ただ記憶だけであるっていうテーマが大好きで、それを巧みに宇宙人とかドラッグとかの話でミスリードさせながら、最後はきちんと後味悪く完結するというスタイルにとても満足した。

イノセンスの5年も前に、全く同じとまではいかずともかなりの部分で共通している、しかもよく出来ているアニメがあるとは思わなかった。

そこそこ説得力があるけどオカルトな学説とかを多用して、いかにもな雰囲気をつくり上げるところも、気分が高揚してくるくらい楽しい。

そういえば、もっと押井守的攻殻の世界の影響を受けた作品だと思ってたけど、なんか意外とAKIRAっぽかった。

あと、制作スタッフがものすごいパソコンオタクだというのが伝わってくる。多分、このアニメをもっと早く見ていたら、もう少し早く自分はエンジニアを目指そうとしていたと思う。それくらい、コンピュータ愛が伝わってくる作品で、もっと昔に観れなかったことを、今更ながらかなり後悔した。

あと玲音かわいい。アリスも可愛い。玲音かわいいよ玲音。

疑問

玲音の部屋おかしいでしょ、なにがどうなったらああなるんだ

視聴して

良かった。最高。また近いうちにもう一回観直したい。

本当にこれは、円盤が欲しいけど、残念ながらプレミア価格。画集も欲しいけど、こっちももう売ってない。悲しい。課金したい。


カテゴリー: アニメ, ポエム | コメント / トラックバック: 0個