On Apr 2, 5:46 pm, Tim Wintle <tim.win...@teamrubber.com> wrote: > 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
I don't think you did the link justice in your introduction of it. I don't think I did your post justice... by ignoring it. Here is a quote from the paper: """ Player Prediction This approach is purely predictive, and it gives one the best of both worlds: In all cases, the server remains completely authoritative. Nearly all the time, the client movement simulation exactly mirrors the client movement carried out by the server, so the client's position is seldom corrected. Only in the rare case, such as a player getting hit by a rocket, or bumping into an enemy, will the client's location need to be corrected. """ Please excuse me briefly; the FBI is beating down my door for quoting it. Regardless, I think it was the 'correction', per se, step that I was interested in. Does it suffice to merely wait until recovering from the lag to notify the player s/he's dead, and proceed normally otherwise? Should the keystroke that the player hit during lag be delivered asap, or 'in time' with how many seconds elapsed since the last known frame? My game in particular, I have a hunch, relies on more precise timing than you might expect in a game. > So it sounds like what you are trying to do is emulate shared RAM > between the two players! No, that's my other project ;) -- http://mail.python.org/mailman/listinfo/python-list
