Prev: MD5 function generates a different checksum than Solaris utility
Next: Simple hack to get $500 to your home.
From: BGB / cr88192 on 21 Jul 2010 21:24

"Rui Maciel" <rui.maciel(a)gmail.com> wrote in message
news:4c39e40c$0$18470$a729d347(a)news.telepac.pt...
> Daniel T. wrote:
>
>> There must be a single authoritative source for every piece of
>> information. When the state of a game object is different between two
>> executions of the program, only one of them is correct. It is up to you
>> to decide which one it is, but remain consistent.
>
> Fair enough. Damn cheaters.
>
>
>> Keep in mind that when something changes the state of a game object,
>> there will be a delay before the state change is evident. When you tell
>> an object to change facing, for example, you have to keep in mind that
>> its facing will not be different immediately after the command (except
>> by coincidence.)
>
> Thanks for pointing this out. So what strategies are there to coordinate
> all the game clients with
> the game server? I guess some sort of synchronized scheduling would be in
> order. For example,
> something similar to:
>
> 1) a client sends a "I want to start action X" message to the server
> 2) the server reacts by sending a "player A starts action X at N time
> frame" to all clients
> 3) once time frame N is reached, the server along with all clients update
> the state of their Player
> A simulation to reflect action X.
>
>
> Nonetheless, this approach appears to be a bit too reliant on the ability
> to synchronize all the
> simulations. Would this work at all?
>

actually, with slight variations, this is similar to how most FPS games
work...


on the client, the client will send an update to the server, telling for
example, which direction the player is looking, which keys are pressed, ...
then, the client will typically update its own state, assuming that the
actions it has requested have taken place (at least typically WRT basic
movement, weapon firing usually just sends the keypress-state to the
server...).

on the server, an object representing the client will exist, which will hold
the "cannonical" position and state of the client. the server will then
regularly send back updates to all connected clients, telling them where
they are, ... this will then override whatever state the client will have
locally.

similarly, all state on the server is cannonical, and all state on clients
(such as the location of monsters, other clients, ...) is merely predictions
from the last recieved values (for example, assuming that an object in
motion will continue in motion unless acted upon by an external force, ...).

other adjustments may be made to account for measured latencies (for
example, if the times can be measured, then they can be compensated for).
given delays tend to be fairly consistent, some measurements can get them
calculated within a reasonable measure of accuracy (simplest though is to
calculate the ping and assume the delay is 1/2 ping both ways).

so, then, messages travel back and forth, and usually the delays and
inconsistencies are small enough that no one notices them...


in the case where there are larger delays, often state will drift, leading
to obvious "teleportations" and other effects during gameplay.


some other games choose to keep state on the client (such as where the
client is, or the status of their inventory, or even how much health they
have and when they take damage), but usually this is a bad idea, since then
the user can "hack" the client, or write a clone client or network-packet
interceptor or whatever, and then start cheating (altering their origin to
teleport them around, giving them unlimited health or money, ...).

so, generally, it is better to keep all state on the server, and merely tell
the client what the state is, but not otherwise (apart from mouse and
keyboard control) giving them ANY say as to what is going on...

oddly enough, this also tends to minimize the effects of latency as well,
since only the client/server ping matters, rather than the respective pings
of everyone involved.


or such...



First  |  Prev  | 
Pages: 1 2
Prev: MD5 function generates a different checksum than Solaris utility
Next: Simple hack to get $500 to your home.