02/05/07 08:56
>((ラグa/2)+(ラグb/2))+100ms になるということに
全くその通りですが、HPの減算処理、将来の回復処理を入れたとき、サーバーで計算するので全遅延時間に占める通信ラグ部分が大きくなると回復が間に合わなくて死ぬ事が多くなるかなーと。
通信ラグがまぁ100msとすると、100msに一回ダメージ/回復処理を解決することでラグのせいで回復が間に合わなかった、が避けられるかと思って。
ラグがたとえば130msと200msでどれぐらい操作感に違いがでるかですが、ローカルでのレスポンスを上げ、遅延の分はアニメーションでごまかせば誤差範囲かと考えました。
どんなもんでしょうか。
拙作はクライアントは200msに一回データを送信しており、50msに一回受信しています。描画は50msごとに行っていて、順調に動いているときは通信間隔200msごとに4駒のアニメーション(今のところ移動の補完だけですが)を行ってます。
サーバからのデータがラグなどでまとまって着くと、アニメーションを飛ばして早送りで処理してます。
サーバは受信は最大速度で行い、100msごとに受信したデータ(最大でクライアント数n。各クライアントから複数回は受信せずソケットバッファにためてます)をまとめて処理し、n回送信してます。
これでどんな感じに動くか、っていうのはさわってもらえばいいのですが今Geoが動いてないので後ほど･･･。
WDiffいいですねー。WinDiffと誤解しておりました。