pygame and socket.recv

[Aaron Brady]

On Apr 2, 5:46 pm, Tim Wintle <tim.win... at teamrubber.com> wrote:
> On Thu, 2009-04-02 at 06:50 -0700, Aaron Brady wrote:
> > It's just that if you register a collision in between the time that
> > one object has changed its position and momentum, and the time you
> > learn about it, you have to retroactively edit the collision, restore
> > hit points, and recalculate the other object's position and momentum,
> > to name a few.
>
> So it sounds like what you are trying to do is emulate shared RAM
> between the two players!
>
> The problem being that you have to effectively lock the variables on one
> machine while the other one reacts.
>
> I believe the answer normally used is the client-server architecture.
>
> Choose one machine to act as the "server" somehow, then let that control
> the entire game state. Both players pass events to this server method
> (using non-blocking sockets), and render things in the position they
> believe they are in.
>
> I believe that is how all the current RTS games work, certainly how Red
> Alert worked, and is how all FPS games work (e.g. in unreal there is
> always a "server", and in single player mode the clients are simply bots
> and the local client application.)
>
> You might find the docs for Unreal networking (c. 1999) useful to
> explain what they did better than I can.http://unreal.epicgames.com/Network.htm

I don't think you did the link justice in your introduction of it.  I
don't think I did your post justice... by ignoring it.

Here is a quote from the paper:
"""
Player Prediction

This approach is purely predictive, and it gives one the best of both
worlds: In all cases, the server remains completely authoritative.
Nearly all the time, the client movement simulation exactly mirrors
the client movement carried out by the server, so the client's
position is seldom corrected. Only in the rare case, such as a player
getting hit by a rocket, or bumping into an enemy, will the client's
location need to be corrected.
"""

Please excuse me briefly; the FBI is beating down my door for quoting
it.

Regardless, I think it was the 'correction', per se, step that I was
interested in.  Does it suffice to merely wait until recovering from
the lag to notify the player s/he's dead, and proceed normally
otherwise?

Should the keystroke that the player hit during lag be delivered asap,
or 'in time' with how many seconds elapsed since the last known
frame?  My game in particular, I have a hunch, relies on more precise
timing than you might expect in a game.

> So it sounds like what you are trying to do is emulate shared RAM
> between the two players!

No, that's my other project ;)