[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[QUAKE:1958] 面切替の設定(サーバ)



平尾@NTTデータ通信です。

ところで、サーバのコンソールからゲーム面を設定するコマンドを忘れてしまい
ました。gameじゃなくて、何でしたっけ?

以上

平成10年1月27日

NTTデータ通信株式会社 新世代情報サービス事業本部 
新世代情報サービス事業推進部 企画営業担当
平尾 吉邦(ひらお よしくに)
〒135-6033 東京都江東区豊洲3−3−3豊洲センタービル22F
Tel 03-5546-8338  Fax 03-5546-9641

>-----Original Message-----
>From:	KAF [SMTP:kaf@highway.or.jp]
>Sent:	Friday, October 24, 1997 12:45 AM
>To:	quake@ns.exa.co.jp
>Subject:	[QUAKE:1773] Re: Quakeworld感想
>
>kazさんこんにちは。
>
>横槍レスですいません(^^;
>
>At [Thu, 23 Oct 97 20:41:56 JST]
>Kazuo Nakata <n-kaz@nsknet.or.jp> wrote:
>
>> これはどういう事かと言うと,ping50の人が5アクションしている
>> 間,ping300の人は1アクションしか出来ないという事を示します
>> # 極端な話,向かい合ってショットを打ち合うと
>> # ping50の人が6発撃てて,ping300の人は1発しか撃てない
>> # という感じです
>
> 正確には、アクションの数はpingに影響されません。pingは入力→アクション
>の間の遅延になりますが、アクション数が減る原因になるのはバンド幅です。
>一般的に モデムとISDNでは、ISDNの方がping、バンド幅とも高性能なので
>それを一つに捉えがちですが。ちなみに、近くに沢山の敵がいるときに、
>突然反応が悪くなるのは、敵の位置情報等のデータが大きくなりバンド幅の
>性能を超えた瞬間からデータの送受信待ちの状態が発生してそれが余計な
>遅延になるからです。そのため人数の少ない対戦では64Kと128Kで違いはあり
>ませんが、一つの大部屋に大勢居る状態の対戦(E1M7が悪評高いですね)
>では128Kの人が圧倒的に有利になります。逆に28.8Kでは全く動かなくなったりし
>ますね。
>
> QWサーバーでは ping とバンド幅の問題を解決するために、
>サーバーがクライアントに一定量以上のデータを送らない(最大データ量はrate
>コマンドで設定可能)ようにすることと、クライアント側で「自分の移動だけ」予
>測表示する(予測量は pushlatencyコマンドで設定可能)ということをやってい
>ます。
>QWで最初に感じるのは移動のしやすさだと思うんですが、これが pushlatencyの効
>果です。ノーマルサーバーでは、クライアントがサーバーに対してコマンドを入
>力(前進、後進、弾を撃つ等)すると、サーバーはその入力に基づいて位置情報
>等の更新を行い、その結果をクライアントに送信します。クライアントは、
>サーバーからのレスポンスが届いて初めてアクションが成立したことを知ります。
>その間、ping ミリ秒の時間がかかります。ボタンを押してから反応するまで
>に遅延があるのはこのためです。それで、QWサーバーでは、移動に関してだけ
>クライアント側で予測表示することにより、快適に移動できるようになっていま
>す。で、歩く速度なんてたかがしれているので、ping分予測表示しようが、普通
>はサーバー側の情報とたいした相違は出ないから普通大丈夫なのですが、ロケッ
>トの爆風に巻き込まれて吹き飛んだ時やワープゲートを通過した時など、サーバー
>側で強制的に位置情報が更新されるようなイベントが発生したときは、普通に歩
>いていると仮定してクライアントが予測表示した分は全部嘘になってしまい、突
>然別の場所に(自分が)ワープする、というような現象が起ります。通信状態が
>悪いと、サーバーの情報とクライアントの予測した情報に相違が発生しやすいの
>で、よく予測分がキャンセルされてワープしまくります。ですが、あくまでも
>ワープしているのはクライアントの中でだけで、サーバー内では常に一貫して
>動いています。
>
>で、敵がワープするのは、バンド幅の問題が大きいのですが、先ほど述べた通り
>QWサーバーは、RATEで設定されたデータ量(デフォルト2500byte/sec)に収まるよ
>うに、情報を送ってきます。そのため、クライアント内部での対戦相手等の位置
>情報が更新される回数が、一回の更新にかかるデータ量に反比例して少なくなり
>ます。通常周りに敵の少ない時は、一回の更新に必要なデータ量が少なくて問題
>ないのですが、位置情報を受け取るべきオブジェクト(対戦相手や弾)の数が多
>くなると、データ量が増えて、ひどいときは一秒間に2回しか情報が更新されない、
>ということになりがちです。それで、対戦相手がピョンピョンとワープしている
>ようにみることになります(QWには、pushlatencyに似た機能で、対戦相手の位置
>情報も予測して滑らかに表示する機能(なんたらPREDICTだっけか)もあるのです
>が、 pushlatencyと似たような理由で、クライアントで敵が見えた場所には実際に
>はいなくて次の瞬間ワープするということがよくあります)。また、周りに対戦
>相手が少なくても、回線ノイズ等で受け取れるべきデータが損失した場合もワープ
>します。回線状態が悪いとワープ天国でしょう。
>
>というのが、私が感じたものです。
>
>QWのラグへの理解、ラグの改善等に役立つ知識だとは思いますので、
>つたない文章ですがずらずらと書かせていただきましたm(__)m
>
>汁汁汁汁汁汁汁汁汁汁汁汁汁汁
>      ▼ 廃 人 軍 団 ▼
>         HJ1  汁総帥
>    -  KAF The DooMer -
>     kaf@highway.or.jp
>汁汁汁汁汁汁汁汁汁汁汁汁汁汁
>