Prev: MD5 function generates a different checksum than Solaris utility
Next: Simple hack to get $500 to your home.
From: Rui Maciel on 11 Jul 2010 10:06
Can anyone give me any tips on network programming for games?


Thanks in advance,
Rui Maciel
From: Daniel T. on 11 Jul 2010 10:28
Rui Maciel <rui.maciel(a)gmail.com> wrote:

> Can anyone give me any tips on network programming for games?

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.

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.)
From: Rui Maciel on 11 Jul 2010 11:32
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?


Rui Maciel
From: Daniel T. on 11 Jul 2010 12:51
Rui Maciel <rui.maciel(a)gmail.com> wrote:
> Daniel T. wrote:
>
> > 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?

I haven't dealt with latency issues that were so striking that such a
system had to be implemented. None the less when you send a turn message
to an object where everything is in the same process, you can generally
assume that immediately after the message returns the action has been
accomplished. However, this isn't the case in network games.

The best solution, IMHO is lots of use of the observer pattern. In
object oriented programming, there is a general distaste of "get"
methods, in network gaming they are even more unreliable.
From: Daniel Pitts on 14 Jul 2010 19:15
On 7/11/2010 8:32 AM, Rui Maciel wrote:
> 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.
Not just cheaters, but bugs, latency, data-failures, hardware failures,
and random-number-generators can cause inconsistencies.
>
>
>> 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.
Actually, I believe modern game engines are even more sophisticated,
keeping track of "probable" states of all active objects in the system,
and simple re-syncing them on a regular schedule.

>
>
> Nonetheless, this approach appears to be a bit too reliant on the ability to synchronize all the
> simulations. Would this work at all?
Indeed, the best one can hope for is "close enough for player comfort."
Good prediction, and leeway in what the user "could have done" will aid
in that goal.
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
 |  Next  |  Last
Pages: 1 2
Prev: MD5 function generates a different checksum than Solaris utility
Next: Simple hack to get $500 to your home.