[pythian] Re: CODE - Network
- From: Darryl Long <pythianproject@xxxxxxx>
- To: pythian@xxxxxxxxxxxxx
- Date: Wed, 31 Jul 2002 19:53:25 -0700
Hi Ken,
I think I've got what you're saying so far, but it raises a question.
We don't want to penalize all the players with good connections for
playing on the same server as a player with a bad connection. All the
players with 50ms pings shouldn't have to wait around because someone
else has a 500ms ping.
My understanding is that we pick some latency, say 250ms, and normalize
everything based on that. Players with connections better than 250ms
will always have to wait 250ms round trip for all data (because the
server is delaying the info), and players with worse connections will
see delays and their local representation of the world isn't very accurate.
Is that correct?
The next question is where are you getting this info? Is there some
on-line information you could share with us so we can read about this,
or are these your own ideas? You mentioned before that CS uses the same
methods, and I'd like to read more about how CS does stuff.
Darryl
KEN FLORENTINO wrote:
>My replies are below. Quite Lengthy so bring some soup and
>crackers.
>
>
>
>
>>Here's my thought: when you first connect to a server,
>>the server sends
>>you a bunch of "sync" packets and the client responds
>>ASAP. The server
>>uses this to calculate your latency. Each sync packet
>>has a time in it
>>(I'm speaking of game time, not real time). With each
>>successive sync
>>packet, the client and server get closer to agreeing on a
>>time. The
>>packet would take a form something like "my current time,
>>the time I
>>predict you'll receive this". The client would receive
>>this packet and
>>set its game-time to the time predicted by the server.
>>It would then
>>send back "the time I received your packet, the time you
>>thought I would
>>receive the packet, my current time, and the time I
>>predict you'll
>>receive this". Somehow a series of these will resolve
>>into an agreed
>>game time.
>>
>>Eventually, once the known time and predicted time are
>>close enough, the
>>server allows the client to connect and proceeds with the
>>game. During
>>gameplay, the server continues to send periodic sync
>>packets to the
>>client to test the latency of the client. The client and
>>server again
>>try to recalculate the latency and re-sync. This should
>>keep our
>>predicitive simulation from becoming inaccurate and
>>client getting out
>>of sync.
>>
>>Darryl
>>
>>
>>
>
>I think I may not be getting my point across. All time is
>handled on the server. The client doesn't need to know
>about time.
>
>The client is nothing more than a dumb terminal that draws
>and handles any calculations that are non-critical or
>don't require accuracy or don't have exploitable
>qualities.
>
>Yes, the server does measure ping times and calculates
>average latencies, and here is why.
>
>Let's say you have 3 players (A, B, C). Let's suppose the
>server has been calculating average pings for awhile and
>this is what it has...
>
>A ping = 100ms (50 ms one way)
>B ping = 200ms (100 ms one way)
>C ping = 300ms (150 ms one way)
>
>Let us suppose a spell has been case and for whatever
>reason you want to ensure that all players see the spell
>at the same time (or as close as possible).
>
>Where T represents time, and T begins as 0 (in ms), this
>is the order that the server sends the requests out...
>
>T = 0 : Server sends a packet to player C
>T = 50 : Server sends a packet to player B
>T = 100 : Server sends a packet to Player A
>T = 150 : Player C receives server packet.
> Player B receives server packet.
> Player A receives server packet.
>
>All three players receive the packet at the same time
>because the server uses a delayed broadcast mechanism,
>delaying for an appropriate amount of time before sending
>to each player. Thus even players with higher latency get
>to experience similiar realities to other players (this
>packet of course was a guaranteed packet).
>
>Since the packet only describes the effect, each player
>starts the appropriate gesture animation the moment they
>cast the spell. They continue to gesture until they
>receive the event that says it has been cast. Once the
>packet is received, the spell animation begins...
>
>Any damage/healing that takes place is sent from the
>server to the client so they may update their GUI's if
>applicable.
>
>The point here is that there is no "synchronization" of
>sorts. The client is a dumb terminal. Imagine it another
>way.
>
>The server is a television camera in Japan. The Japanese
>watching it locally (the clients) see it immediately.
>Those of us in the US who wait for the satellite
>rebroadcast see a delayed version. This is how earlier
>games were done.
>
>Newer games delay the broadcast to the closer clients (the
>Japanese) to allow time for the broadcast to reach the US.
>Now both the Japanese and the US are watching nearly the
>same broadcast.
>
>In both cases, the client only draws what is seen by the
>camera.
>
>I may be a little redundant here but I'm just trying to
>get the point across.
>
>Now then, time can still be used on the client side, but
>only for interpolation purposes. When a user presses a key
>(like forward) he expects to move forward immediately. If
>the client presses a key, and the client sends a packet to
>the server, and waits for his coords and has a 500ms ping,
>that means he will physically feel a delay from the time
>he presses the key until he sees he's moving forward.
>
>Our client, however, will be smarter than that. He knows
>that it will take about 500ms until he receives his first
>coordinate from the server (after that they will come at a
>steady rate of XX per second). The client knows that he
>can move XX feet per second, so he starts his movement.
>When he receives his first packet he auto-corrects.
>Subsequent movements are still interpolated constantly
>(the position coordinates may only come at say 10 times
>per second or less).
>
>Nevertheless, the client is never "out-of-sync". The
>server is the only one who keeps track of position and
>movement. The client simply asks permission to move, and
>waits to be told where to move to. By interpolating while
>waiting, the user has a smooth gaming experience.
>
>This goes for everything. When the player shoots an arrow,
>the client of course performs some basic checks (do i have
>arrows, have i selected the bow weapon, and I able to
>move, am I paralyzed, etc). If the client decides it's OK
>to shoot based on current rules, he begins the shooting
>animation and interpolates where the arrow will go. Once
>the server sends the arrow flight information (start
>position, vector, current gravity conditions whatever),
>the client can use that information to calculate the rest
>of the flight of the arrow for *drawing purposes only*.
>Once the arrow hits (or misses) it's target, the server
>notifies the client of any critical info (your HP are now,
>you have poison, etc).
>
>Hopefully this beginning to become a bit clearer. Nearly
>all game critical information and calculations remain on
>the server. The client only calculates when it doesn't
>require critical calculations (animations and such).
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
Other related posts:
