Archived

This topic is now archived and is closed to further replies.

core114

networked multiuser physics

Recommended Posts

First, this is mainly related to physics, as the network people know how to network, but not how to do physics properly (generally), and there havn''t been any posts about networked physics on the physics forum. For networked physics, games must resolve inconsistincies from latency and user movement. For example, User A is driving their car to the right. just before they run into user B, B jumps out of the way. To make things more interesting, user B is more massive than the car, (like a small volume but high massive robot) //.................^. //.................|. //.*-----*.........B. //.| A |--->....... //.*-----*........... //................... So, just after this happens, user A doesn''t know user B moved, and responds to the collision, causing the velocity of the car to be changed greatly. However, to user B, the car is still speeding past. Both simulations are now very different, and even worse, the server may have another outcome of the events. For most games, it seems the server is right, so whatever happens on it is what really happened, moving clients local objects towards where they are on the server. Instead, the server could get the new information after the collision, find something was inconsistant, back up the simulation a fraction of a second, then use the new information about what has already happened on each client to modify the outcome of the collision to minimize the change that then has to be sent to each client. But, of course, this would be much harder to do, and could lead to further complications. Are there any modifications to either approach that would be less complex, or more accurate? Delaying Everyone''s input by .1 seconds or so, so everyone could have exactly the same simulation could even be done.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
I have been working on a commercial game. Flying cars racing in a big city, streets full of bots and automats. The game was supposed to be a multiplayer hit. Maybe U C which one. LOL ! I quited because the staff did not consider it was the major issue. To me the whole project and production had to be designed around this point : Network*Physics complexity ! Pizza sellers arent good enough at maths to understand ! Thus I let my ROFLMAO stock options to others . I had a lot of nice ideas to solve this problem.

These days some ppl think that they can produce some generic middleware package for multiplayer networking or physics ! Let me laugh again. Of course with a ping=5 cable it''s still possible .. with lots of bugs however. Else what a bullshit pseudo techie propaganda ! It''s even worse than the idea of a generic 3D engine. Never fits to your needs. Network and physics, that''s a job !

The main problem is that percussion are ultimatly discontinous. Network latency worsens the incoherency between client worlds in an impressive manner !

You can well predict dynamic changes up to the 4th degree. I mean turning the wheel is roughly a continuous move of the driver. Thus you can extrapolate with a good accuracy, knowing roughly the first 4 derivatives of movement as long as the power (force change) and accelerations are bounded to natural values. Lets say a few Gs. But percussions are a 0 or 1 pb. And it''s a brutal 2nd degree change !


I thought of several ideas to turn around this important issue.

1st idea
--------
Use smooth collisions.

Think of a kind small but strong anti-gravity field around your collision volumes. The goal is to smooth collisions. If two worlds are spatially incoherent with a difference of a few inches you will drastically reduce the jerks when collisions occur. The percussions will be replaced by continuous works of fields.

To test it, I have solved the integration of a magnetic field on a triangle analytically. It leaded to a small but impressively efficient routine ! But I wont explain it here. I needed Mapple and a lot of wit to solve this double integration.

2nd idea
--------
Use probabilities.

This one is still based on collisions between undeformable solids. In a fast action game you dont bother that your collisions are really precise. Imagine that you can maintain a kind of dispersion volume ( relative to extrapolated incoherency ) of the dynamic states of the objects. A kind of cone.

Second step try to figure out an algo which could quickly sample the potential collisions. Get the probability of collision. Average the metrics in case of collision. Metrics can be the maximum interpenetrating distance in the near future, as if the objects followed straight forward.

Example 1:
Client A guesses collision is 10% possible with a collision metric of 3 inches. Then 0.1*3=0.3 gives U a result you can compare to a decision threshold. Let''s say here the prediction is no collision.

Client B guesses 25% and 2 inches. Prediction : no collision.

Thus both clients wont collide. In a peer to peer scheme everything is OK. No jerk. The player sees nothing stupid and is happy because the game keeps fluent.

If U compare with the strict parent/child decision scheme using standard determinist physics, you would possibly get :
A : no collision
B : collision

Jerk or even lag thereafter.

Even better you can mix 1) and 2).

However you need to be a brute at maths and know what you are doing to make it work. That''s why I dont care to let these ideas public. I could have a patent for it. But if I had a patent for each of my ideas ... I would ruin myself ! LOL

If you are interested for more, e-mail me ! It''s only the main ideas. I have examined the issue much deeper. But I dont wanna crash the server with my posts !

Charles B from Paris.

2^16 ideas/second. LOL
Seeking for interesting ppl to work with.

cbcht@wanadoo.fr


Share this post


Link to post
Share on other sites
I would say a combo of fuzzy and deterministic methods.
Server gets 2 different accounts, determines which is more exact and/or up-to-date, and firesd that version off.
If you have low latency peer to peer, you definatly want a modified deterministic. if B jumps out of the way, then goes flying, hes gonna be pissed. So you want a value jugement again- who gets the frag ?

If you havea high latency system, players are gonna lag, and tats just that simple. Its going to be jerking all over the place, and errors are gonna be popping up all over the place.
So a more fuzzy way would be acceptable.

Ideally everyones on a T1, and all network code is hyper optimesed. But thats pipe dreams...



the bugle4D engine;
a new dimension in graphics...
[link]http://members.tripod.com/thefivelions/bugle4d/[/link]

Share this post


Link to post
Share on other sites