MMORPG 作成at GAMEDEVMMORPG 作成 - 暇つぶし2ch■コピペモード□スレを通常表示□オプションモード□このｽﾚｯﾄﾞのURL■項目テキスト115:名無しさん＠お腹いっぱい。 01/11/08 18:12 とりあえず>>1の関連スレとは関係無いよってことにして、 向こうからの厨房流出を防ごう。 116:81 01/11/08 18:59 PAYRb3Kt ご推察通り、移動方向指定型です。ただし、プレイヤーから見ると、 移動目標指定方式に見えるよう、最終的にはもっていく予定です。 つまり、移動目標座標をクリックすると、そこへ最短で到達しうる 「第一歩目の歩行方向」をクライアントが決定し、サーバへ送る 感じでしょうか。 設計初期には、移動目標を指定し、それ以上のメッセージ 送信は行わない方がローコストであろうと思い、そういう設計で 進めたのですが、上記のようにオブジェクト同士のすり抜けの 問題や、その他の整合性を優先するために、毎サイクル必ず１つ のメッセージを送る方法をとりました。 （整合性においてはパーフェクトです） これは一見とても無駄な通信ですが、実はそれほど状況は悪化 しなかったようです。C>Sは、メッセージの大きさが小さいですからね。 （UDPですので、エラーチェックもメッセージキュー的な物も 自前でゴリゴリ書いてます） 問題は、やはりS>Cでして、サーバ側の回線が「使われていない」時間 があるのが、もっとも無駄だと考えます。 たとえば、ゲームを一定のサイクルで割ったとします。先ほども書きましたが、 １ C>S×人数分 ↓ ２ 実質的な処理×人数分 ↓ ３ S>C×人数分 という流れですと「３」の時間のみ、回線がフルに使われるだけで、 残りの時間、回線がヒマな状態になってしまいます。 しかも、全クライアントは、自分から見えない範囲の者たちの エントリーも待たねばなりません宿命に（笑） これですと、プレイヤーはボタンを押してから、これらの長い行程を へて、ようやく画面内が更新されるわけですから、とてつもなく かったるいですよねー。 しかし、もしプレイヤー人数が少なければどうでしょう？ それならば、かなりあっという間にサーバからの返事が期待できます。 この手のゲームには千人なりのプレイヤーがアクセスする物が多いので、 そうはいかないのように見えますが、実は視野内にいるプレイヤー は、それほど多くないはずです。これが自分の方法のヒントでした。 次ページ最新レス表示レスジャンプ類似スレ一覧スレッドの検索話題のニュースおまかせリストオプションしおりを挟むスレッドに書込スレッドの一覧暇つぶし2ch