Multiplayer/Latency + Physics + Collisions

[Xaron]

Hi all,

 

I've thought about multiplayer and physics. I see that this must be somehow synchronized so that both server and clients have the same results. The way I see it there are several ways to do it:

 

1) Clients do all physics

 

That's the easy case where every client does its own physics calculation and send the results (position etc.) to the server which spreads it to the other clients.

 

Problem: Cheating is easy as the server doesn't control it all.

 

2) Server does all physics

 

The Server calculates the whole world with all bodies and send the results to the clients.

 

Problem: There is obviously the problem that this leads to massive lags at the clients side and jittering etc. as we need some interpolation on the clients side. The other problem is the huge calculation power for the server.

 

3) Mixed mode

 

This seems to me the only practicable way to do it. Every client calculates its own physics and send the results (forces, position, etc) to the server. As the server should NOT calculate unnecessary stuff it should just do some rough calculation to see if the client is still within its correct boundaries. So there would be some kind of trust as long as there are not big jumps, unrealistic forces and so on (cheating attempts).

 

Another issue would be the stuff like bullets. When one clients fire at another one and hits it, client A (the attacker) should send a "hit message" to the server. Again I would like to avoid all not necessary calculations on the server side so one idea would be to wait for client B to send this "hit message" as well. That way cheating would be unlikely as a hit is only recorded when both clients send its message. All the collision stuff would be done locally.

 

I'd like to discuss this a bit so do you see any flaws with this concept? How would you handle it? The main problem is latency here and it should be a smooth gameplay even with 100-200 ms latency so interpolation is essential!

 

Thanks!

[Canardia]

Interpolation is very easy in LE, you just do AddBodyForce( clientbody, CalcBodyVelocity( EntityPosition(serverbody) ) ).

That way you don't have to care about latency either, since you can send every 1000ms or even every 5000ms only one message, and even if the message is delayed by 60000ms (one minute), it would still work and have no jittering.

 

For non-physics model movements you would interpolate using PositionEntity( clientmesh, Curve( oldpos, newpos ) ).

 

If the server does physics, it would have also its own benefits:

1) You could use a super fast 64-bit server with Linux (Debian of course) and a super fast physics engine which doesn't need to be deterministic.

2) Clients would run faster, since they don't have to calculate physics at all.

[Xaron]

So I set a body force for the client by getting the body velocity from the server? Sounds a bit strange to me as you can't simply set a velocity as force. This won't help for lagging situations as well as the client has to immediately react on controls and can't wait for the server which would double the latency (client sends its control command to the server and the server replies with a force to act).

[Canardia]

No, I had a typo, it was meant to be CalcBodyVelocity, which interpolates a physics body to a given position.

[Xaron]

Hmm ok. Thanks for that. But shouldn't it be something like CalcBodyForce instead of CalcBodyVelocity? Again, putting a velocity into AddForce doesn't seem to be correct?!

[Laurens]

Whenever a client is authoritative there is going to be cheating so I would avoid it at all cost. For example, mixed mode could easily be cheated by modifying the client to never send the "hit" message.

 

You can solve it quite easily by not using physics and just do simplified calculations by "hand" (which several modern MMO's such as WoW, Lord of the Rings Online and EVE Online seem to do) but Lumooja's solution is of course far more elegant

[Xaron]

Whenever a client is authoritative there is going to be cheating so I would avoid it at all cost. For example, mixed mode could easily be cheated by modifying the client to never send the "hit" message.

 

That wouldn't be a problem as client B would send such a message. So for the case that only one of the two involved clients send such a message the server would look into this issue.

 

You can solve it quite easily by not using physics and just do simplified calculations by "hand" (which several modern MMO's such as WoW, Lord of the Rings Online and EVE Online seem to do) but Lumooja's solution is of course far more elegant

 

Thanks. Yes that would be doable but as I use submarines it would be nice to have some kind of realistic physics especially if it comes to collisions.

[Canardia]

Hmm ok. Thanks for that. But shouldn't it be something like CalcBodyForce instead of CalcBodyVelocity? Again, putting a velocity into AddForce doesn't seem to be correct?!

It's only the name of the function, which calculates the force needed to get the velocity needed to reach the position wanted.

[Canardia]

Whenever a client is authoritative there is going to be cheating so I would avoid it at all cost. For example, mixed mode could easily be cheated by modifying the client to never send the "hit" message.

You can do hidden banning, so you check if someone's client is behaving regularly unexpected, and then you make his character die more often in battles or let his weapon miss more often.

 

Some game, I think BatMan Forever had this kind of hidden banning, where it detected that it was not the original game, so it caused some wierd behaviour ingame. And when people asked why this happens, the moderator just said: "It's because you are using a pirated version."

[Xaron]

Thanks Lumooja. And regarding your second post: This is a nice and funny idea!

[Rick]

You can have the client do the physics and check for cheating on the server by checking abnormal numbers. I think Josh kind of proved when he was doing all his tests that doing physics all server side had some issues that in my book weren't acceptable.

[Xaron]

Thanks Rick. I think about to just avoid physics and do it simple by myself like Laurens mentioned...

[Guest Red Ocktober]

having every client calculating its own physics responses seems like a sure formula for chaos and condusion across the simulation...

 

wouldn't it be better for everything to be done on the server and the results sent to the clients...

all client objects would in effect be 'ghosts' of whatever they are on the server...

 

just a thought...

 

(suddenly, it seems as if everyone is into networking... did i miss a memo or somethin' )

 

--Mike

[Canardia]

It's just the phase in everyone's game development. When you start making a game with LE, you'll notice you need to do some things yourself, first the level save/load (which kinda conflicts with SBX scenes), then the networking (then you don't necessarity need load/save, unless your game is like diablo 2 which is a hybrid single/multiplayer game).

[Rick]

having every client calculating its own physics responses seems like a sure formula for chaos and condusion across the simulation...

 

wouldn't it be better for everything to be done on the server and the results sent to the clients...

all client objects would in effect be 'ghosts' of whatever they are on the server...

 

just a thought...

 

(suddenly, it seems as if everyone is into networking... did i miss a memo or somethin' )

 

--Mike

 

 

I think I should have clarified my response. I mainly meant for the client character, it should control it's physics and send it back to the server. As far as world items, it's not done very often in multiplayer games and the reason is because it doesn't work very well. Like you said the server should control this, but the clients can also interact with it and the feedback the client would get if the server controlled everything is horrible and so it's generally why you don't see in games.

 

You would need client side prediction on the physics but then the server would have to correct his data and sent the corrections back. Josh tried all this a few months back and the result was "bad" in my view. Unless you are neighbors with the server it's a pretty bad simulation. I seem to remember Josh thinking it was good for people close but realistically online games can't rely on that.