Physics Collisions + Network Latency

Networking & Multiplayer
#1

Hi all,
Im trying to put a game together but it looks like ive stumbled across a dead point. The game is a multiplayer car game with physics and collisions. The initial idea was only to send the forces that are being applied onto the car through the network. This will give a smooth look on each player’s screens, which theorehtically, it does. But one problem. What if a collision occurs between two cars. The forces will change dramatically, but due to lag and whatnot, on one screen a collision can have happened, on another, it may not have. Obviously, its a problem.

I couldn’t find many articles on google describing this, and quite rightly so, because most article refer to FPS and a stray bullet isn’t really noticed.

Is server side collision detection and response a good idea? If so, how much of it? Just the collisions between two players and terrain-car client side?

What about if we only used forces. I.e. dont send anything other than forces and torques. Then we do a client side positions comparision wereby the client compares what he sees by what he should see (sending positions) and adding a force to bring the car back on track? Good idea? Bad? It can possibly take a while for the car to be back on track and it also might look weird if the car is drifiting sideways…

What about P2P style networking? send the force and torques via a P2P network (does P2P reduce ping times?) and other statistical things to a server. Also, the server will set out the rules for the game. E.g. how long it will last, what map…etc. Again, good idea? Better than the rest? worst? Im confuzzled! :-\

Regards,
DP

#2

Ok, we are doing nearly the same thing so perhaps I will come out and start discussing publicly to support any synergy that could germinate in this community.

I have done real-time game networking (RT meaning not turned based but “fast” in-frame action type stuff, FPS, racing etc) in the past with Java in our game demos. This was using UDP (and multicast in some cases) on LANS but NOT ever WAN (Internet).

This is what we are working on right now. More specifically, we are networking an “area” full of physics objects with multi-player intertactions.

We are not sending forces right now. Instead, we are sending the dynamics ‘snapshot’ of the object the ODE will use to bring back in sync the networked worlds. And specifically, position, orientation, linear and angular velocities. Work with forces in my experience is mess and in exact in frame based physics engines like ODE.

We are doing point to point networking, i.e. no server checking other than for connection services. Latency is the major issue (well asuming broadband) with the data, so direct player to player seems to be best. We make the ‘server’ another client in the group, so it has the last info, but isn’t in-between the clients creating delays. the big down side is that player client code has other players IPs, which ultimately can be a security issue.

Ok enouhg for now :-

#3

I see, ok, so your recomending i send the positions/rotations and the Torque and linearVelocity through a P2P network and simply “set” them to the other object. I know ode can recalculate the force based on a new velocity, but last time i heard, it doesn’t like it very much…

Have you played a game called TrackMania? (It was released last April)…Its a very fun realtime car racer and they dont allow collisions between cars which I found suprising. I.e. you can pass straight through another car. Perhaps they were hitting the same problem…

Take this scenario. Two cars almost parallel are traveling, they will eventually hit each other. Now one of the players (call him player1), swerves at the last minute to avoid a collision. If we are acting on forces, the other player (player2) will see player1 as carrying on forwards and a collision will happen between the two on player2’s screen. Although player1 has swerved 200 millis ago (average ping). Even on positions and linear velocites etc, it might be too late…

DP

#4

[quote]The forces will change dramatically, but due to lag and whatnot, on one screen a collision can have happened, on another, it may not have. Obviously, its a problem.
[/quote]
Maybe it isnt’ what you meant, but this implicitly assumes that it is “okay” for the calculations to be inexact when no large forces are involved. Any, even the slightest deviation across clients will be sufficient to severely desync games, so any inexact approach is completely unusable.

One approach which will eliminate this problem is to do all calculations on the server, then beam the complete game state across the network every frame. Rather expensive if you have many cars, and latency will be a problem. Latency can be eliminated to some degree by letting clients simulate loosely what they think is going to happen, then beam corrections from the server at regular intervals. Still, those corrections would be quite large. In a large world, not all information might be necessary to all clients, so one could save some bandwidth there. In games life Halflife, I guess things work roughly this way. When you fire or move, the person will do so immediately, but in reality there will be some fuss with respect to lag, since the server has to somehow carry out these things in sync across all clients.

A very bandwidth-cheap way is to let every computer do all calculations in parallel, then simply send basic commands by the user through the network. This approach is common in RTS games. Latency is a problem, but very little traffic is required. You just need to synchronize the execution of these events across the network by associating a specific frame with each.

These are just ideas, and I’m not exactly a specialist, so feel free to clear up any inaccuracies and stuff.

#5

After playing Q3 I am convinced that it is not possible with current technology to make a fast-paced network game that works. There is no way to get around the lag that is satisifying… some aspect of game play MUST suffer.

#6

Best car game I ever played is Flatout, http://www.flatoutgame.com/
It uses some sort of point to point networking i think, since if the “host” crash all other still can play on without any problems.

#7

Well you can try all the fancy algorithms you want, but for a face paced game over the internet the fact remains that there’ll be about 200ms seperating the two players, and humans are inherantly unpredictable. :wink: Until we get LAN-range pings over the internet people will still have to mess around with game-specific shortcuts and fudges.

#8

Put the track on the moon with all drivers operating via remote control. Now you have an excuse for 500ms delays. :slight_smile:

#9

Thanks all,
So i guess the conclusion from this thread can be thought of as do P2P networking, server (acting as a client) manages states and hope for the best!

@ Ask_Hjorth_Larsen: In a way, yes, this approach is inaccurate. Lets put a scenario together: A player (player1) and someone is watching (player2). Player 2 is not playing…Now if we are only sending forces, the force can change without it being sent to player2, e.g. accelerate hard and then brake, the total force will not show that, so what player2 sees will be probably a very innacurate picture of what should happen. To get around this, probably sending the position every 3 - 4 seconds and setting the position to of player1 is probably best…

Any other ideas folks?

DP

#10

Don’t worry about synching the state. It don’t matter if what the player sees is “correct” as long as it seems plausable and it don’t effect the lap time. With that in mind you can cut some corners and just try and make the physics seem realistic.

#11

tom, thanks for the advice, if I just ignore it, inaccuracies can accumulate and it ends up being WAAYY off. Player1 colliding with player2 on his screen sending player2 off, but on player2’s screen, P1 is miles away…thats what im worried about.

@JoC, i just downloaded the demo for this game…SWEEEET! It is very good, shame i can’t nab their models/tracks tho, it seems the first track is perfect for me! :slight_smile:

Regards

#12

[quote]@ Ask_Hjorth_Larsen: In a way, yes, this approach is inaccurate. Lets put a scenario together: A player (player1) and someone is watching (player2). Player 2 is not playing…Now if we are only sending forces, the force can change without it being sent to player2, e.g. accelerate hard and then brake, the total force will not show that, so what player2 sees will be probably a very innacurate picture of what should happen. To get around this, probably sending the position every 3 - 4 seconds and setting the position to of player1 is probably best…
[/quote]
That seems reasonable. Allow me to emphasize, though, that even small inaccuracies can affect the game very much (near-misses and whatnot), and it can be difficult to determine the minimum amount of data necessary to reconstruct the model without having to send the complete game state. For a car game, however, it might be possible to send a complete game state since only a rather small amount of entities are moving around (depending).

#13

Im afraid the amount of data that needs to be reconstructed would be quite large… ::slight_smile:

Think of barrels, tyres…etc and because they all can possibly change the state of the game (hit a car), they have to be entities as well…

Also, how frequently should I be sending packets? Every frame? Thats 60 in a second! That seems quite large…or am i wrong?

Regards

#14

60 times a second isn’t feasible. What you’re trying to achieve is very very difficult (I was going to say impossible, but I’m sure someone would just disagree). Running a synchronised world across the internet with any sort of accurasy just isn’t possible. As people have mentioned above the latency just doesn’t make this possible, 200ms is a reasonable estimate and in that time frame so much can change in a physics world.

Herk once said that its about tailoring the game not the network (or something similar). In your case I would suspect the sensible thing to do would be to be run everything locally. Two people can for instance hit the same barrel at different times at the same location, just make it look right to the player. Car (QuadBike?) damage is maintained locally to the player, if they see themselfs get hit - they get hit - yes this is prone to cheating. If you’re really bothered add a voting layer, damage is inflicted when 50% of players say it happened. Don’t try to sync game worlds in this sort of detail, its just a frustrating track through the darkest dampest bowels of hell.

You do of course want to resolve times when two people intersect and the like, but that pretty similar to any FPS.

Kev

#15

Ok, taking a laid back approach to the whole thing…

Ok, realistic scenario: Player1 is racing ahead and player2 is behind him. Theres a barrell out of sync between the players and player2 is going to hit it on his screen, but the barrel is out of place on player1’s screen. The damage should just appear on player1’s screen? It actually sounds horrible, but thinking about it, its not so bad.

What if player1 sees player2 is going to collide with the barrel? but he doesn’t…If im just transmitting forces, player2 will be HIGHLY out of sync (actual player2 would be traveling fine, but player1 sees him flying through the air)…That sounds a horrible concept! Everytime i get an answer, 4 questions crop up! Your right kev, its an underground, flammable sewer in hell, full of monkies with laser guided chickens!

And your right kev, it is a quadbike. Its looking currently like a jeep, so if anyone wants to model me a quadbike…consider it a late birthday gift! ;D

DP

#16

Due to simplicity I recommend the (high-latency) RTS approach. Transmit all control input (commands) across the network and have every client calculate physical stuff in parallel. Associate with each command the absolute frame number in which that command is going to be carried out.

ALL (logical) FRAMES MUST BE NUMBERED SEQUENTIALLY.

You could implement it like this:
player 1 hits “forward”.
a “forward” instruction is sent to the server.
Server receives this instruction in frame number 716.
A “forward” instruction is sent to all players, scheduled for execution at frame number 716+LATENCY, let’s say LATENCY = 20.
A player receives the instruction in frame number 731. that instruction is stored in a queue until its time is up.
Finally in frame number 716+LATENCY = 736, ALL players are expected to have received the command, and will then execute the command in exactly the same frame!

One question remains: what stops each player from progressing beyond the time at which the command is scheduled for execution? You could regularly send out max-frame-number-instructions allowing clients to run up to a certain frame number. Whenever the client’s frame number reaches this maximum frame number, the game MUST HALT until a new max-frame-number instruction is received. Thus it is virtually impossible to get out of sync, at least if this is implemented correctly! TCP/IP is really a nice protocol.

#17

Be aware that you’ll have to limit yourself to integer math if you base your simulation on input only. Floating point math will differ between hardware, even vm version. StrictMath might help, but don’t know if garanties that all results will be identical.

#18

That is exactly the problem with “deathmatch” play in every FPS I have ever played. Either your own “hits” aren’t counted, or you are hit by something that clearly was rendered as a “miss”. Not to mention shooting walls because the game didn’t react to your strafe in a timely manner.

I stopped playing them because it took all the fun out of it to be “cheated” like that all the time. Depending on your network traffic you can even see the effect on a LAN.

That said, Q3 is still quite popular… so not everybody cares that the games aren’t WYSIWYG.

#19

That’s exactly what StrictMath is for. However, to make all floating point operations identical, you’ll need to declare all game-state affecting code ‘strictfp’ too. Note that this is a problem if you’re using e.g. ODE which is probably not strictfp at all.

  • elias
#20

Even without StrictMath/strictfp, any differences will usually be tiny. However estimating the likely size of these differences for particular algorithms is a highly specialized skill.