pygame and socket.recv

[Tim Wintle]

On Wed, 2009-04-01 at 18:45 -0700, Aaron Brady wrote:
> 
> My game loop looks like this:
> 
> poll events, get 1 at most
> send to server
> wait for server reply
> render entire frame

The look I'm suggesting is:

poll events
write to (non-blocking) socket
render frame
check non-blocking socket and add events to the event queue

> Yes, I am blocking for the data to come down the network.
> Unfortunately, if I use any "prediction," I will have to go back and
> un-render the previous frame, then redraw with the new information.
Sounds like that may have to be re-factored slightly, afraid this is why
real-time networked games are tough to make.
> 
> 40 transmissions per second in each way can't be too much to ask, it's
> just that they have to alternate, up one, down one.
IMO It's very unlikely to be a bandwidth issue. It's more likely to just
be a latency issue.

> 
> I don't understand your solution.  I can't picture it for my favorite
> RTS game or the one I'm writing.  Are you saying that the slower
> machine just jumps ahead, and its user just doesn't have the
> opportunity to make moves on the omitted frames?


a) How much to move etc. is decided based on some real-time solution
(not on the number of frames). Ideally all movement methods take a
parameter that is a delta in time. (i.e. 1/40th of a second)

b) That time is the time that is synced across machines - if machine B
has to put it's timer forward 1/50 of a second, you call all the methods
above with a timedelta of 1/50 before continuing.

c) Obviously things like which frame a sprite is on isn't really
necessary for the sake of a game, it's only game state variables that
would be required.

d) If you end up with jumping objects then you can create "ghost"
objects for the other player's objects. When you get the state of a
foreign object, update the real object with the properties, but draw the
sprite at the position of your ghost object - and every frame move the
ghost object towards the real one a little bit. That gets rid of the
effect of jumping from one place to another, but keeps collision
detection etc. correct wrt the other player.


> 
> I am using TCP, socket.SOCK_STREAM.  UDP is a potential solution, but
> it still doesn't fix my main loop.
> --
> http://mail.python.org/mailman/listinfo/python-list