[pythian] Re: CODE - Network
- From: "KEN FLORENTINO" <majic.majic@xxxxxxxxxxx>
- To: pythian@xxxxxxxxxxxxx
- Date: Wed, 31 Jul 2002 18:47:19 -0400
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:
