ゲーム配信とゲーム受信のテストプログラム

ニコニコゲームとjgforceの話

前ニコニコゲームの企画ってのを考えた。
http://d.hatena.ne.jp/tsugehara/20130330/1364613227

これを説明するためにはjgforceという企画も説明しないといけないんだけど、まあざっくり言うとrmakeみたいなユーザ投稿型ゲームサイトってのを考えてる。
いくつか気が進まない理由のある企画で、そのうちの一つが普通のユーザ投稿型ゲームサイトではニワンゴが腰を上げた時点で負けるだろう、という予想。
ニコニコゲームの企画記事は、ではどういうものが出てくれば負けるのか、というのをシミュレートするために考えた。

で、その後俺は知らなかったんだけど以前ニコゲーってのがあったようで、ニワンゴはニコニコ動画にゲーム投稿サイトを結合するって仕組みをニコゲーで一度実施していて、しかも失敗してるらしいと。
すると、もしかしてニワンゴさんしばらくは動かないんじゃないの、という仮定が現実味を帯びてくるわけで*1、じゃあちょっとゲームプラットフォームっぽいのやってみてもいいかなという気になってる。

ニコニコゲーム企画の肝について

ユーザ投稿型ゲームサイトとして一番重要なのは、当然ユーザが作れる事、そしてユーザが遊べる事の二点なんだけど。
この二つだけでは実にありきたりなんだよな。

残念だけど、現状Webゲームはネイティブゲームにクォリティではとても勝てない。勝てるのは気楽さとマルチプラットフォーム対応出来るという望みが持てるという点くらい。
「作れるよ」「遊べるよ」だけでサイトを成り立たせるには、このクォリティしょぼい問題をユーザに受け入れてもらった上で、ユーザの反応が直に受けられますよとかの付加価値をつけないと正直厳しい。

で、ユーザ反応受ける機能とかだけど、これは正直当たり前の機能なんだよね。
rmakeもKEROCKETSも9leapもそんなのは当然実装してるし、特に9leapはユーザ数がそこそこいるので、ユーザ反応もらえやすい + マルチプラットフォーム + プログラムの学習が出来るって辺りの三本セットで、肝心のクォリティの低さを言葉は悪いけど上手く誤魔化して価値を持たせてる。

では、それらの機能を持つゲームプラットフォームに比べて、ニコニコゲームの企画で面白い機能は何かっていうと、配信が出来るってことじゃないのと。
もちろんニワンゴがやると、既にあるニコニコモンズが利用可能とか膨大なクリエイティブなユーザ層取り込めるとか別の意味も出てくるけど、「ニワンゴがやる」とか「ニコニコに結合する」という前提条件を取って企画単体で見ると、実は配信と視聴の二つくらいしか目新しいのは無い。

配信が出来るゲームサイトってそんな無いでしょ。
とりあえずそれが一個あれば、「作れるよ」「遊べるよ」のありきたりなサイトではなく、「作れて遊べて見れて配信出来るよ」ってなるので、「おっ、なんか変なの出てきたな」くらいのインパクトにはなりえるかなと。

てことで

配信と視聴が出来るもんを作ってみたよ。
http://tsuge.sub.jp/jgforce/demo/live/play.html

デモにアクセス後、出てきた「視聴用URL」というリンクを、Chromeの場合すばやく「新しいウィンドウで開く」をやれば配信者自分、視聴者自分、で見れる。
リンクを他の人に共有するのは、すまぬがポーズ機能の無いシューティングゲームなので上手くやらないとちょっときつい。

デモ見るのにテクニックがいるクソ仕様ので、一応YouTubeもおいときましょか。

デモは配信が終わった後、視聴側ウィンドウでF5を押すと、録画状態のものを何度でも見れる。
まあゲームはjgame.jsのサンプルシューティングの流用でしょぼいのと、デモとしてわかりづらくなりそうなので視聴側の映像を配信者側の3秒前まで進める、とかはやってないけどね。

アルゴリズムはニコニコゲームの企画で述べたように、操作状況だけ送受信してて、ラグは許容。
乱数をJavaScriptで書かれたMersenne Twisterを使っていて組み込みのMath.randomを使ってないとか、入力イベント制御をすべてメインループ内にしているとか、いくつかポイントはあるけど。
細かいことはさておき、このデモは「入力イベントの同期だけでゲームは配信出来る」という証明にはなっていると思う。

課題など

長時間配信の問題

これはまた別に詳しく書くけど、jgforceで課題だと思っているセーブ・ロードの問題とも共通する。
現在配信者側の内容に追いつこうと思うと、画面描画をすっ飛ばして内部処理を高速に動かして追いつくしかない。

短い時間なら十分追いつける。が。
いくら動画よりは軽いといっても、未圧縮の状態でデータ量は3分程度の配信でも200kb超えする。
1/60秒更新を目指すフレームワークを使っているので、1秒のデータ量がざっと60個。1分で3600、3分で10800。1データ20バイトとしても200kb行ってしまうわけだ。

もちろん、フレーム数を落とすことは出来るし、30fpsでもそれなりに成立はするけど、どの道ゲーム配信なんて○時間かかるのが当たり前の話。雑談しながらやったら尚更。

データ量が増える事自体は大したことじゃないけど、"画面描画をすっ飛ばして内部処理を高速に動かして追いつく"実装には限界があって、例えば3時間12MB分の処理をゲーム内で処理するのにはそれなりに時間がかかる。つまり長時間配信の動画を見るのは、視聴開始まで結構な時間がかかってしまい、結果としてライブ感が失われやすい。

多分どっかでスナップショットの機構が必要だとは思うんだよな。
でもjsで動いてるゲームのスナップショットって正直かなりしんどいので、これが一番でかい問題。
例えば60時間プレーのゲームがあったとして、スナップショットなしでセーブロードしようものなら死んじゃう。

コメントとか

後はシューティングじゃなくてもうちょいまったり系のにして、画面同期入れて、コメント表示できるようにすれば大分ニコニコゲームっぽくはなる。
でもこのコメントは正直悩みどころ。

ゲームプレー中の画面にオーバーレイでコメント流す事は、技術的にさして難しいことはでないのだけど、ぶっちゃけ邪魔じゃね？って。
ネタばれコメントうざくね？とか。過去の時間帯に送られたコメントをライブではどうすんの？とか。
諸々悩みどころが多い。
コメントは必要なんだよどう考えても。必要なだけに難しい。

フレームワーク制約問題

この配信はjgame.js、またはjgame.jsと同じようにシード指定可能な乱数エンジンを持っていて、かつ入力操作がすべてメインループ内で制御できて、かつその入力操作とメインループの時間経過が横取り出来て、その横取りした情報を元に再生できるタイプのフレームワークであれば可能なんだけど、そんなんあるんかいなと。

当初jgforceはenchant.jsとかもサポートしようと思ってたんだけど、配信生かすには現実的にはjgame.js限定にならざるを得ない。
jgame.js限定になってしまうとwebglとかも使えない。
jgame.jsでwebglとかもサポートしようと思うとフレームワークの保守コストがやばくなって手が回らなくなる。
結果製作可能なゲームの自由度が薄れてしょぼくなるよね、と。

視聴・配信機能入れても、ニコニコ文化圏外で、マイクサポート出来るかどうかもわからない状態で、このちょっと「おっ」と思える程度の機能で、どんなフレームワークでも作れますよって長所を殺す意味あんのかっていうと難しいとこっすねということで。

マイクと音声

ニコニコゲームの企画でも述べた気がするけど、サーバが手配出来ないと音声配信はきつい。きついっつーか無理。
そんな金無いので、自力解決の道を模索する気はない。どっかのサービスに寄生するしかないんじゃないかな。

まとめ

操作の同期でゲーム配信出来ることは証明した、でもこれが面白いかどうかは別問題で、実運用するためにはいくつかクリティカルな課題あり、ということで。
なんか面白い事出来ると思うけど、その面白さはそこそこ程度であって、すんげー面白いわけでもねーよなというのが微妙なところ。

いっそオンラインゲーム前提にした方が楽しいかもしれんけど、そういうクリティカルな操作にはソケットが必要なんで、マイクの問題と同じく初期投資0前提だと無理なんで。
まあ、もうちょい考える。次はWebツクールをテストしてみるかな。

*1:まああの会社はそういう人の予想を裏切るのが好きな気もするけど