pygame and socket.recv

[Terry Reedy]

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

I am very sure that commercial 'real-time' (versus turn-based) 
multiplayer games do not operate that way, at least not the ones I have 
played.

I suspect that most do not operate by  frames on the server, but rather 
sent a more or less continuous series of events.  NPC movements come 
from the server (and can be given as vectors), other player movements 
get echoed as sent to the server.  The client uses the most current data 
it has when it renders a frame.  If the scene it too complex relative to 
the client rendering capability, the frames jump and the motion is 
choppy.  If the info stream is interrupted, the scene may freeze a bit 
even as the client continues to re-render to account for player motion. 
  Hope this helps a bit.

> 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.
> 
> 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.
> 
> 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?
> 
> 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
>