僕も小学生の頃はよくパソコンでゲームを作った。中でも一番友人に受けたのは、アスキーキャラで作った山岳地帯の中でロボットが戦う対戦ゲームだった。ロボットはジャンプとビーム発射が出来て、山岳地帯はランダムに作った障害物を横から見た物だった。
その時のテクニックではその程度しか作れなかったが、本当はマップも山岳地帯以外に色々あって、画面の外にもスクロールして行けるようにしてみたかった。今みたいにインターネットがあれば、ネット対戦も考えていたかもしれない。色は緑しか出なかったが、そのしょぼい画面から想像力はどんどん広がっていった。
さて、Croquet。システムも関わってる人数も大きいので何だか大変なのだが、大きく始めすぎなんじゃないかなと思っていた。そりゃ10年後を見越してビッグな事をやりたいという気持ちも分かるが、それまで成果が見えないのは辛いな。しょぼくても良いから、P2P で立体で、そう言う物が本当に(デモではなく、24時間)動いてるとどうなるのかを見てみたい。
例えば、今の僕なりに考えてみた。
P2P は沢山の人がやってるし、大変そうなので考えない。重要なのはネットワーク内で、3D モデルをどうやって作成し、転送し、キャッシュし、移動するかだ。このネットワークより上で、各ツールより下のレイヤが TeaParty だ(実際の実装はもっと汚いがアイデア的にはこう)。 物理的にデータを流す部分はあとから本物の P2P モジュールを組み合わせても良いし、今の Croquet の暫定 P2P でも良い。大事なのは、TeaParty が独立している事。なぜなら、ここだけが Croquet にしか無い部分だから。
極端な話、信号を実際に流すのは irc でも jabber でも HTTP でも良い。ユーザからみて重要なのは、他人の作った三次元の場所へ行けるという事なので、P2P である必要は無い。速度やスケーラビリティや怪しいデータをやり取りしたい状況では P2P の方が良いかも知れないけど、オープンソースの P2P まだしばらく使い物にならないと思う。だから TeaParty はその下部モジュールに依存していてはいけない。
TeaParty が本当に動けば、たとえ回線の問題で荒いワイヤフレームしか転送できなくても、そこで何が出来るのか考える事が出来る。むしろ豪華なモデルの表示に手間取って全体のパフォーマンスが落ちるより良いかも知れない。今のように開発者の卓上にある二台のパソコン程度の実験では何も生まれない。Croquet で「ぱどタウン」を作るほうがよっぽど生産的な気がする。
