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