pygame and socket.recv

Tim Wintle tim.wintle at teamrubber.com
Thu Apr 2 18:46:43 EDT 2009


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





More information about the Python-list mailing list