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
-- http://mail.python.org/mailman/listinfo/python-list
