Logic behind multiplayer physics

rumblesushi

I know there are a few technical guys here and hopefully one of you has worked on a multiplayer game and has some idea of the logic behind it.

I'm possibly going to add multiplayer to my first game (and if not this one, then the sequel), and I'd like to know the general theory behind the physics side of things.

Obviously even in local multiplayer, you have ONE physics engine handling collisions between players, no different to player vs CPU collisions.

But what about online multiplayer? There you have 2 or more physics engine running simultaneously, how exactly is the collision handled?

One idea would be to share the computations between them, but surely that's actually a bad idea, as it means more network traffic when colliding.

So possibly the cleanest most efficient solution would be to determine which user's machine is performing better, whichever has the lowest time step between frames, and calculate the collisions only on that one machine, and exchange positions etc as per normal. Obviously this wouldn't apply to consoles, as the users would be on identical machines, but on PC's the logic seems OK.

Do you know how it's generally handled?

Cheers,
RumbleSushi

commander_keen

What kind of physics? For gameplay related things like player movement I think its usually done by each player submitting their position and velocity at set intervals, and maybe also when the player changes current movement keys pressed. The server would then send that info to all the other players and they would update the remote players object to reflect those changes (this opens up possibility for teleport hax so some server side checking would be a good idea).

For general ambient physics objects I think its common to do something similar where the server handles all external forces added to the objects (such as an explosion near a crate) and sends it to the clients. The clients would update the objects position and velocity every time it gets an update on it while still handling client side collisions.

rumblesushi

Obviously the player movement (and movement physics) is simple enough, like you said it's simply exchanging positions.

I guess in this instance to simplify things I'm talking about player to player collisions, let's just say 2 players are found in the same node, there are 2 instances of the physics engine running, so how is the collision detection and collision resolution solved in this case?

I'm considering either using SmartFox or hiring someone to build a multiplayer API, because server side stuff really isn't my thing.

However, I develop my own physics, so I obviously need to know how to integrate that side of things

Do you think player to player collisions are also handled in a similar manner then?

commander_keen

Player to player collision is always a bit tricky. Handling collisions purely server side will result in being able to walk through another player for a second so I dont think thats a valid solution.

In a lot of games you have problems when 2 players run close to each other in a line. The one in the back kind of jerks around (at least in that players perspective). I like how Left 4 Dead handles player collisions. They have very soft collision so they are just pushed away from each other instead of hard collision. That also allows multiple players to run through a small doorway at the same time. For most games just letting the client physics engine handle player collisions for each client is good enough. The only problem is when both players are moving fast while close to each other.

In any case I think the specifics of net code needs to be handles per game, and an engine should only offer a system for easy client>server>client communication.

rumblesushi

Yeah that makes sense. And I agree that most things need to be handled per game really, with any given engine providing an abstract foundation in it's given area.

The L4D method sounds good, but what about more complex physics, like proper solid body dynamics response?

Imagine multiplayer Burnout for example, with proper collisions where for example 2 spheres being pushed apart obviously isn't good enough. That's what seems a little more tricky.

When you say letting the client physics engine handle player collisions for each client, surely that means possible duplicate, simultaneous collisions?

One of the problems is, for any proper collision resolution, the physics engine needs to update the velocities and positions of BOTH objects it's processing, which obviously seems tricky. A player's position would be self governed and at the same time, needing to have it's velocity and position updated by rival players.

I agree a server side only solultion surely wouldn't work, especially for collisions that needed to have some degree of accuracy.

commander_keen

Yeah it definitely gets more complicated when you need really accurate collisions for something like a racing game.

Ben Apuna

I'm not knowledgeable in these areas but here are a few threads and links on the subject (or similar) that I've come across in the last week or so.

Networking approach thread from TIGSource.

Networking a shooter thread from TIGSource.

GDC Talk on networking from that thread.

Glenn Fiedler's site, which contains articles on Physics and Networking for games.

I hope that helps.

rumblesushi

Thanks for those links Ben.

The first gaffer article has a dedicated networked physics section, which although is for a FPS, so probably closer to what Keen has described, it should at least provide solid enough fundamentals to implement more complex vehicle physics etc

Ashaman73

Player collision in a classic fps multiplayer setup is often handled by the server only. The reason is simple, you need one consistent world representation. To avoid player penetration due lag most games also implements some kind of client side physics to predicit the movement of other players and to calculate the corrent movement behaviour of the client itself.

The workflow is like this:
- all clients sends their position/velocity/action to the server
- the server is the law, it will validate the input and calculated the next valid position of all players
- the client will do its own calculation to predict the position of other players until the correct data from the server has been received(extrapolation along a spline to get smooth movement). Using a physics engine will help to avoid player/world penetration etc.
- client: handling hard failures => when the lag is to great, most games will stop the prediction (an other player suddenly stops movement, even in air). On the other hand, when a client received a validated server position of a player which is too far away from its own predicted position, it will just reset the player to the valid position (an other player suddenly teleports to an other position).
- client: handling minor calculation errors => the client needs to consider the valid server position even if it differs from the predicted position. In this case the client tries to move the player to the current on a smooth spline like curve.

The server physics is often tolerant to position received from the client which differs from its own calculated position. To avoid interruption of smooth player movement the server will take over the client position if it differs not to much from its own.

One major issue with network code is cheating ! You need one trusted partner which is the server. If you let all the client do their own physics handling you game will fall due massive cheating. Without lag all would be so easy (server do all the calculations), but due to lag you need to give some of your control to the clients which will always lead to some degree of cheating (i.e. a simple speed hack would be a client which always utilize the full movement tolerance of the server).

An other aspect for player/npc collision/movement is "steering behavior". In this case no direct collision handling between player/npcs is calculated, instead forces are applied depending on other dynamic object surrounding the player. The standard player<->static world collision is still intact. This is more a less a "must have" for large groups of moving players/npcs. Doing the collision handling with rigid body physics will lead to massive issues with smooth movement.

commander_keen

I think that generally player/world collision is handled client side and then verified by the server to avoid cheating. Many years ago you had some games that actually handled player movement entirely on the server such as the original release of quake1. It was aweful because even your movement keys suffered from lag, but luckily got fixed in quakeworld.

It became a standard to handle player movement (at least initially) on the client, although many other actions such as shooting were done on the server. Many games today do most of the major actions, such as shooting and hit detection on the client. Doing that complicates cheat prevention, but in my opinion its absolutely necessary. It drives me crazy when I see a recent game with lag visible to the player. [/rant]

rumblesushi

Ashaman, interesting post, thanks for the insight.

If the server is the law, isn't that what Keen is describing? Even player movement governed by the server of having to be validated by the server? Which would obviously lead to a huge dip in response times. Or do you mean just for potential collisions with other players?

And the steering behaviour is kind of what Keen was talking about before.

So I'm still really curious as to how proper, CPU hungry solid body physics is handled, for something like Burnout multiplayer, where you have complex, iterative collision detection and resolvement between players

BTW Keen I agree. When I do a multiplayer game, minimising lag is going to be the #1 priority.

One of the reasons I'm not as big on multiplayer games as most people is actually lag. Games between UK players are generally fine, but with most US or Asian players it's unplayably laggy.

And even a SLIGHT bit of lag affects the gameplay for me, I like the super crisp response times of single player.