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!

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.

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...

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.

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.

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.

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.

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. Until we get LAN-range pings over the internet people will still have to mess around with game-specific shortcuts and fudges.

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...

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.

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!

@ 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...

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).

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.

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!

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.

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.

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.

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.

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.

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.

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.

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.

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.

It do not mather how tiny the difference is. Don't have to be an expert to know that the error will add up very quickly and the game will end up out of synch.

If you are not an expert you should probably not say anything at all on this subject. Whether the errors accumulate and how fast depends on the algorithms involved. While some algorithms would diverge rapidly, others can proceed for billions of operations with only tiny differences. In my opinion (as a PhD in mathematics) attempting to avoid floating point is not the correct answer to this problem. After all a great deal of effort was put into the design of the arithmetic used in modern computers (and required by Java) with the intention that the behaviour of floating point is well controlled. Perhaps instead of treating floating point as "here be demons", more programmers should learn to understand it.

Err, are you seriously suggesting people should use a more complicated and error prone system over a tried and simple secure system?

Floating point rounding errors do add up a lot over time. You either work around it (what I suggest), or make sure it the errors are exactly the same and add up in exactly the same way for everyone (what you seem to suggest).

Err, are you seriously suggesting people should use a more complicated and error prone system over a tried and simple secure system?

No, that is what you may get through attempting to use integers.

Quote

Floating point rounding errors do add up a lot over time. You either work around it (what I suggest), or make sure it the errors are exactly the same and add up in exactly the same way for everyone (what you seem to suggest).

Again no, what I suggest is to understand what the error bounds are and keep them under control. Accumulated error doesn't become a problem until it reach perhaps 1 in 1e6, so at that point you need to distribute corrections.

However in the case of Java, the extent of difference is very restricted. For the basic operations (+,-,*,/ etc) even without strictfp the results must be exactly the same unless the range of float/double has been exceeded. A JVM is not allowed to perform computation with any more (or less) precision, it can only use a larger exponent range. So in the case of double if no intermediate value exceeds 1e308, then the results are required to be identical. Java does allow some differences in the case of some of the non StrictMath methods (e.g. sin, cos, etc), but here the permissable difference is very small. Note that methods such as Math.sqrt specify a correctly rounded result --- all conforming Java implementations must return exactly the same result for this method.

While doing your own thing in integers may ensure that all clients produce the same answer, it also increases the likelihood that the answer obtained is wrong!

The problem with 0.1 (base 10) doesn't apply to physics. Using floating point with finance is much more problematic, largely because various authorities specify rounding rules invariably in base 10 while the usual computer floating point is base 2 based.

My point was that there are rounding errors in floating point math unless you happen to only use 2^x numbers, so claiming that floating point math contains fewer errors than integer math is wrong.0.1 was just a clever example, it's the 1/3 of binary math. (but please note that 1/3 is not a problem in trinary math)

The errors in floating math are more "hidden", though, so they often act as time bombs unless the programmer knows what he does. With integer math the error shows up immediately rather than after "billions" of operations.

You still have quantization errors when using integers to represent real world quantities, plus you add in risk, if you scaled the values, that someone will assume the wrong scale factor. In addition many real world quantities have inherent measurement uncertainties (Heisenberg). These uncertainties are much greater than the difference between a base 10 value and its double (base 2) approximation.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org