複数のクライアントからユーザーがログインして、それぞれが移動できるようになった。
それぞれのクライアントで、マウスをクリックした位置に自分を移動できます。
もちろん他人が移動した様子を見ることができます。
今後の予定
ログインの処理
今、地図データをクライアントが保持しているが、サーバーから転送できるようにする。
ユーザーのキャラクタが1種類なので、それぞれのユーザーが違ったキャラクタを選べるようにする。
チャットの処理
データの送受信はできているが、その表示部分が無いので、チャットデータの表示部分の作成
当たり判定
現在、壁を抜けます。というのは、当たり判定をしていないからです。
このあたり判定が曲者で、ネットワークによる時差によって当たり判定がおかしくなる可能性があります。これを回避する部分を考えなければなりません。
表示の処理
現在、家具が置けません。家具を置くと家具の置いてある部分の背景が黒くなってしまいます。家具の背景はちゃんと背景で描画しなければなりません。
そのあたりのデータ構造や描画関連をちゃんと作らなくては。。。
音
音楽や効果音についてはなんも考えてないので、そろそろ考えなくては。
ちょっとづつ進歩していますが、ちょっとづつ複雑になっています。うーん。奥が深い。
おお、意外と順調ですな。
ちょっと遊んでみたくなった….
提案ですが、
C/Sは、Sがボトルネックになるので、P2Pにしない？
例えば、キャラクタの当たり判定の情報は、P2Pでやり取りして、サーバーは関与しない。
ドメイン(部屋？)に誰か参加した場合のみサーバーがイベントを発行する。
地図も可能であれば、P2Pでもらい、誰もいない場合は、サーバーからもらう。
会話もP2Pで行う。そうすれば、ひそひそ話もできる。
ユーザー管理、地図のマスター配信、セッション管理がサーバーの仕事。
すげぇ、これが本当のInternetだ！
基本的にサーバーって今、何にもやってないんだ。
セッション管理と、クライアントからあがってきたメッセージの再送しかしてない。
今後もクライアントでできる処理はできるだけクライアントでやらせるつもり。うちのサーバーはそんなに速くないし、ネットワークも遅いしね。
当たり判定も、できることならクライアント側でやらせるつもり。
だから、同期を考えなきゃいけなくて、ちと検討中なのさ。
おそらく、
Server-Client型
から始まって、
分散型サーバー形態で、Clientはどれかのサーバーに接続
てな形態を途中ではさむと思う。IRCみたいな形式ね。
んで、これができたら、サーバーでの処理をクライアント側に委譲していく。
という流れで進めていくと思う。
結局、ネットワークを使ったゲームの場合、「遅延と同期」の問題との戦いになると思われるので、もうちょっとじっくり考えないと駄目だな。今の構造ではそこまで、遅延と同期についての仕組みが作りこまれていない。このあたりの仕組みがエレガントに作ることができれば、どの形態に移行していくにしても、それほど問題は出ないと思われるが、いかんせん、同期の必要なネットワークのプログラムの経験がたらなすぎるので、もうちょっとServerClient型で修行を積んでから考えます。
二人が同時に刀を振り下ろして、ネットワークの速いほうが有利になるような状況はおかしいと思われるし、敵キャラの動きに差があって、ユーザーごとに有利不利がでても嫌だし。。。考えれば考えるほど奥が深そうです。
まぁ、今のServer-Client型で持ちこたえられないほど、ユーザーが集まるのは遠い未来の話だと思う。
偉大なる先人の「ScrapBookOnline(http://www.nurs.or.jp/~urara/sbo/sbo.htm)」では、のぼり750kくだり3.6MでCPU Crusoe600MHzのサーバーで100人をさばいた経験があるとのこと。この先人のWebによると、実は地図の配信が一番負荷が高いとか。
じっくり考える時間はある。
まぁあと、ServerClient型だとデバッグが楽なんだよね。P2Pに比べて。
もうちょっと修行を積んでからP2Pに移行していきたいと思いますが如何でしょう？。
このような提案は大歓迎。
これからもよろしくお願いいたします。