UNIQLO_GRID
見知らぬ誰かと会話もせず時間を共有し、空間を共有し、目的を共有し、ただひたすらロゴをいじる按配が超ネットプリミティブなゲーム。
暗黙のうちにコラボる瞬間というのを体験すると自然に嬉しくなり気持ち良いって思えると思います。それは単に見てても自分でやってても。
詳細はnisshi.yugopを見てもらうとして(またかよ)、
Art Direction / Design / Programming: Yugo Nakamura @ tha ltd.
Design: Erica Sakai @ tha ltd.
Sound: Suguru Yamaguchi @ manual of errors.
Technical Direction / System: Keita Kitamura @ tha ltd.
以下、サーバを開発するまでにいたった僕のどーでもいい心模様。
それを技術的に解決すべく今回わたくしめはサーバ開発しました。
というのも、一番最初はFMSの使用を予定していたのですが、ロゴのログを保存する為にDBに接続したりしないといけないので、そうなった場合、FMSからHTTPで別のサーバに接続しないといけなく、何か速度でなそう、とかそういうイメージがありFMSは止めました。何か合った時にブラックボックス過ぎて何も手が出せないと言うのもあるし。後、他のFMSの実装例を見ているとどうしても速度が出そうな気がし無かったので。(実際のところは分かりません。自分でつくって試したことが無いので。)
そもそも、今回は快感さ、気持ち良さ、を感じさせるべくいかに速度が出てサクサクっとみんなの動きがアップデートされていくのかと言うのがポイントに見えたので速度・軽さは妥協したくなかったというが背景にあったりします。yugoさん自信もネットワークの遅延とかはUIレベルでも解決していくと最初から言っていましたし。
で、次にRed5(FMSのJava実装)の使用も検討したんですが、これが重量級のアプリケーションというか、どうやって使うんだこれ？みたいなアプリケーションでセットアップが兎に角面倒そうという壁にぶち当たり、そもそも、こんな機能テンコ盛りなアプリケーションは今回は必要なさそうだという事に。
最終的にライトウェイトな実装を自分でするのが一番良いんじゃねえかという結論に至り、自前のソケットサーバをつくったわけです。
プロトコルは、途中でいくらでも仕様が変わってもうろたえない様に、カチッとしたものをつくるのではなく、JSONをベースにして単に圧縮するだけって風に汎用的にしました。仕様が固まってればそれこそビット単位でデータの転送効率を上げるプロトコルにいくらでも出来ますが、このプロトコル設計の場合においてはどっちかと言うと、効率より柔軟性を重視して。短期間で制作している僕らにとって仕様の変更は日常茶飯事なもんで。(プロトコルだけAMFを使うというのも一応考えましたが・・・)
まあ、後は、ひたすらコード書きまくったと。
なんつっても取り越し苦労したのは、ロゴデータは全部記録するので、その矛盾を無くすこと。衝突判定を完璧にしてデータの一貫性を保持する。簡単そうだけど、これが意外とバグの温床になってた。最終的に問題なく出来たが。
そんな訳で、衝突判定を備えた特殊チャットサーバが出来たわけです。
なんか眠くなったきたから最後すっとばした。思いついたら後で追記していく。