01/11/08 18:59 PAYRb3Kt
ご推察通り、移動方向指定型です。ただし、プレイヤーから見ると、
移動目標指定方式に見えるよう、最終的にはもっていく予定です。
つまり、移動目標座標をクリックすると、そこへ最短で到達しうる
「第一歩目の歩行方向」をクライアントが決定し、サーバへ送る
感じでしょうか。
設計初期には、移動目標を指定し、それ以上のメッセージ
送信は行わない方がローコストであろうと思い、そういう設計で
進めたのですが、上記のようにオブジェクト同士のすり抜けの
問題や、その他の整合性を優先するために、毎サイクル必ず１つ
のメッセージを送る方法をとりました。
（整合性においてはパーフェクトです）
これは一見とても無駄な通信ですが、実はそれほど状況は悪化
しなかったようです。C>Sは、メッセージの大きさが小さいですからね。
（UDPですので、エラーチェックもメッセージキュー的な物も
自前でゴリゴリ書いてます）
問題は、やはりS>Cでして、サーバ側の回線が「使われていない」時間
があるのが、もっとも無駄だと考えます。
たとえば、ゲームを一定のサイクルで割ったとします。先ほども書きましたが、
１ C>S×人数分
↓
２ 実質的な処理×人数分
↓
３ S>C×人数分
という流れですと「３」の時間のみ、回線がフルに使われるだけで、
残りの時間、回線がヒマな状態になってしまいます。
しかも、全クライアントは、自分から見えない範囲の者たちの
エントリーも待たねばなりません宿命に（笑）
これですと、プレイヤーはボタンを押してから、これらの長い行程を
へて、ようやく画面内が更新されるわけですから、とてつもなく
かったるいですよねー。
しかし、もしプレイヤー人数が少なければどうでしょう？
それならば、かなりあっという間にサーバからの返事が期待できます。
この手のゲームには千人なりのプレイヤーがアクセスする物が多いので、
そうはいかないのように見えますが、実は視野内にいるプレイヤー
は、それほど多くないはずです。これが自分の方法のヒントでした。