From the UK, Australia is quite a long ping:
mark, there’s been some trouble with the matchmaker at the moment, i’l email you the program as soon as we fix this.
Sorry for the delay…
DP
Didn’t the guys at eyeone.com and minatrix.com have applet MP racing games? (both 2d and 3d, with collisions and other interactions between players if I remember correctly)
Don’t know if the developers of these games hang around here, but maybe they can share some tips. From what I remember it worked pretty well…
-Thijs
Halo 2 is the best example of a world with physics involvement done right. Having played it a lot, and seen it under heavy lag, I have a pretty good idea of how it works. Most everything is done locally, except for damage taken. You might think you got hit by something, and even see your screen flash as if you’ve taken damage, but if you’re lagged and the server does not agree that you were hit, all of a sudden, “poof” you’re somewhere else as the host sync’s you back up and you realized you were never damaged. I’m pretty sure that they way they do their arrangement is that when a party is formed, 1 in the party (probably the one with the lowest ping) is set as the host. Everything has to agree with his machine. Who becomes host is completely unpredictable and uncontrollable as the server that matches up the party determines who is the host. Anyway, all the clients do the physics calculations locally. The host periodically informs everyone of where they “really” are and what’s “really” going on, keeping things in sync. I suppose you could prioritize what information needs to be sent out most frequently and what can wait a bit longer to more quickly send out information and reduce lag, but in Halo 2 lag never seems to be that bad. If lag gets REALLY bad, then you’re confused for half a second, then you’re back on track when the host syncs you back up with the rest of the action. Typically, though, all the machines should agree with each other about what’s going on.
Places I see this being more applicable for you would be in the case of barrels. One guy hits a barrel. He thinks he hit the barrel at an angle of about 5 degrees from the center. Your client thinks it was more like 10 degrees. At any rate, the barrel blows up and its effect shows it launch off the track, and his car is damaged. You both agree he hit the barrel, you both agree his car was damaged. No communication about where the barrel actually went afterward is necessary because it’ll no longer affect the world.
As for cars against cars. The host isn’t going to have any problems with the lag of course, but the other guy driving beside him should have a pretty close estimate of what’s going on. If he gets off, periodic resets of position and velocity should be enough to keep him on track of the real action, and hopefully they’ll be minor enough that he won’t really notice it happening. If it is a major change and he jerks out of position, well, sometimes it happens!
I hope some of that is good food for thought.
Hi
The point of the physics is to make the world more realistic. Rather than the barrel disapearing, it’s now bouncing around the track, hits a wall and goes skidding down the main streight. You were following car 1 and he hit it at 5 degrees, you saw it at 10 degrees. You were saying that this doesn’t matter, but it doesn. The barrel slid down the tarmac for a a while having been hit and bounced off the wall, it now sits on the track and you are heading towards it fast. That 5 degrees a few hundred hards ago now makes a couple of feet difference as to where the barrel sits, meaning that your swerve doesn’t move you out of the way enough and you hit it, where as before you would not. Now it’s suddenly very important. When it comes to physics, every minor difference can become major.
Unfortunatly for physics, we need networks with latency of 0, and that aint gonna happen. So the game needs to do some compensation, and that means ‘bodging’ it.
You need to guestimate latency based on how far a connection will travel, and then fudge the game to allow for this. That pretty much rules out realistic physics over a network.
Networks mean compromise
Endolf
Yeah Endolf is right.
The fundemental difference is that in an FPS there are two thinsg at work:
(1) Most of the phsyics is “window dressing”, it has now real effect on game-play so you can afford to have slightly different results on different screens.
(2) Even more imprtoantly you don bt have “cascade effects” where one physics interraction causes another one.
Car drivign on a tight track though is all about the physics. When you are drivcing at 100 MPH bumper to bumper, beig off 2 feet can mean a totallty different game result.
Unfortunately, for a game like this your gonna have to play all kidsn of hiding games PLU all kinds of latency limiting games. To start with I gues I’d use an open-loop UDP type communciation for thsi kidn of game. In msot games i stilla ssert TCP is really perfetly fien if yo uudnerstadn it, but here any network hiccup is likely to screw you up pretty badly…
Good luck. We did a ganme like thsi at TEN but we ended up using a special deal withya a ntework provider and really only ran well over their lines…
[quote]To start with I gues I’d use an open-loop UDP type communciation for thsi kidn of game. In msot games i stilla ssert TCP is really perfetly fien if yo uudnerstadn it, but here any network hiccup is likely to screw you up pretty badly…
[/quote]
Wow. Did you catch your train? 
Wow. Did you catch your train?
[/quote]
New here?
Ask around…
I’m working on a multiplayer spaceshooter, and it works great with just using tcp… I guess it’s not as disastrous with a latency hickup as a racing game (though I am planning on adding a racing mode… but from reading this thread… I’m getting the feeling I’d only be getting myself into trouble…).
I am planning on allowing players to host games… well, I have already impelmented it, but noone seems to be able to start a server… then I read this thread… and apparently it might be NAT messing things up…
UDP punch through seems to be the way to go… is there a way to set up a tcp connection in a similair way to udp punch through (I’m guessing not)? I’d really like to stick with tcp since it’s wonderful to know the packages sent will also arrive! :-)… but I really need for players to be able to start servers as I don’t have capacity to run a lot of servers…
If UDP is the only solution… is there a freely available implementation of reliable transfer over UDP in java? (I’d really not like to reinvent the wheel here… )
I’ll take a look at that. Thanx for the tip…
otherwise I thought about doing an implementation Q3 style… forgetting about reliable packages all together… and just send delta packs of changes since the last know successfully delivered package… seems like a pretty nice and simple model… altough I don’t know if it will work for me yet… since I have a lot of objects (all asteroids are separate entities…)
Shawn / Darkprophet: Have you continued working on this issue? Any progress been made?
Im also very interested in this subject, as I’ll start working on a multiplayer race game soon (multiplayer over the internet). Im looking for information on how to handle distributed physic states over connections (latency<200ms), but information on that is sparse…
Thijs
PS: This is an nice (though simple) example that a race game with collisions over the internet is possible: http://www.jollygoodgames.com/turbosliders
Trying to make it reliable is reinventing the wheel, with all the inherent problrms.
If your sim is going to require reliable packets your never likely to get the latency characteristics you need.
My quicka dvice:
(1) If you have the bandwidth, do redundant data to reduce the effect of a dropepd apcket.,
(2) Design your datastream so a dropped packet or two are non-fatal and can be recovered from.[quote]
[/quote]
Jeff, I’ve read up abit on this topic… and I agree with you… Now I’m in the process of converting everything to UDP… I’ve changed everything so it now runs on UDP but it still sends the same stuff as TCP, so it will basically crash for the moment if an important package is lost.
So now I will implement sending redundant packets… with every packet containing all (important) info since the last known correct state. (Q3 style)…
I’ll report back how it goes… and hopefully will have something up for testing pretty soon…