Physics in MP

[dscowboy]

Has anyone found out yet what kind of limitations we face on physics in multiplayer? Obviously, using physics as a component of MP gameplay requires some level of server-side processing and propagation, but how much? If a baracks is hit by a shell and one wall explodes into 8 flying pieces of cement, will things continue smoothly or will the lag-monster eat everyone within viewing distance of the explosion? When server-side physics are processed and sent to clients, is there any client-side physics prediction? If not, physics-affected objects are going to move at your network framerate, not your video framerate.

If MP server-side physics are limited to simple things like pushing a box in front of a door, then there's not a whole lot of potential for using physics as a major MP gameplay component. If no one knows about this yet I will e-mail Yahn.

 

[Grey]

From what I've read you determine during level building where the physics takes place. A pop can could be client, a car the server.

Go ahead and email Yahn I wanna know more .

 

[OCybrManO]

The physics engine is the same in MP... the only difference being that some calculations are synchronized server-side while others are purely client side. I would also bet that they have prediction for objects as well as players.

 

[nw909]

Big things = Clientside
Small things = Serverside

 

[Stigmata]

The server synchronizes all the "important" physical objects like stuff that can damage people or cause reactions (i.e. barrels, propane tanks, wood), and the non-important physics (like pop cans, bottles, glass) are calculated client-side since these will have no effect on other objects in MP.

 

[Cunbelin]

I think you have that backwards nw, big things would be server side, small things that don't affect anything would be client side. Examples of client side things, dead rag doll, harmless non blocking projectiles, particle systems. Server side things would be damage causing objects, path blocking objects. For instance in trap town, everything that you picked up with the manipulator would be server side, things like soda cans out of the machine would be client side, dead bodies, client side. The boards across the door server side, the dumpster and beam and their supports are serverside, but the particles generated by hitting the boards, or destroying the supports are clientside.

 

[Grey]

Yeah I think he ment small=client etc.

My point is valve stated this is all up to the designer. But obviously unimportant=client, important=server makes the most sense in terms of bandwidth and server processing time.

 

[dscowboy]

I'm not asking about whether the map designer can determine which things are client and which are server. I don't care about client side physics, they have no impact on gameplay. I'm asking what the limitations of server-side physics are. If each moving server-side object takes up as much bandwidth as a player character, then forget about it, it wouldn't be very useful for MP. If I wanted frag grenades and anti-personnel shells that actually exploded with shrapnel instead of using the lame distance-from-blast-is-inversely-proportional-to-damage calcuation, an exploding grenade would need to model quite a few pieces of shrapnel. 25 pieces would be pretty skimpy, but if each piece uses as much bandwidth as a player it would be out of the question, the first time two grenades exploded in sequence everyone would be playing dodge-the-lag.

The fact that Valve has mentioned that vehicles have the option of either being physically modeled as having friction with the ground, or being faked like HL1 vehicles makes me think that HL2 MP vehicles will be faked. They probably wouldn't have made the option to fake the vehicles if they didn't need to use it in their own multiplayer. And if physically modeled server-side vehicles eat too much bandwidth or act too laggy, that probably means that MP server-side physics will be pretty limited in its uses.

 

[dscowboy]

The reason I don't care about client-side physics is that they're essentially useless. Anything that's maintained serverside (the positions of the players, the positions of any weapons, etc), won't be influenced by any object that uses client-side physics. If I blew a hole in a building client-side, I wouldn't be able to walk through it, the server would know nothing about the hole. If I shoot someone and his body rag-dolls client side, there's nothing I could do with the body that would influence the game. I couldn't use it to block a path, I couldn't use it as a shield, I couldn't even stand on top of it. Client-side physics are only for visual effect, like in BF1942 where you can shell a building and it looks like big pieces break off and explode, but when the smoke clears nothing has changed about the building at all.

 

[Grey]

Email Valve now

I'd like to know all this too.

 

[Joeyslucky22]

now.. let me get this straight

clientside - whats on your computer

serverside- the information sent to everyone.



say you shot a popcan...would others have seen what happens to it?

 

[Rabid Llama]

Valve writes excellent netcode, and supposedly HL2 has better netcode than HL1 did. Surely, with the physics engine being as prominent as it is, they wouldn't simply overlook it in multiplayer. I'm sure they have the synching down well, either by feeding all the clients the same calculation parameters for all the objects, or by simply sending states for objects (which wouldn't be as much as a player, as it'd just be x/y/z/pitch/yaw/roll for each object, or something similar. That's just a few bytes per object per tick, though it could very easily add up).

Anyway, I'm just making stuff up, so feel free to email somebody who actually knows :nerd:

 

[dscowboy]

Originally posted by Rabid Llama
(which wouldn't be as much as a player, as it'd just be x/y/z/pitch/yaw/roll for each object, or something similar.

But that's about the same for players, right? As long as they aren't shooting, players are just x/y/z, an aiming vector, whether they're ducking or not, which gun they have, etc.

I don't know, hard to say because with players, a lot of info goes from client to server, like the aiming vector and the events for key presses (jumping, weapon firing, moving forward). But a physically modeled object would only need information to move from server to client. So maybe it's considerably less taxing like you said. If the client does prediction for physically modeled objects, they might be able to improve performance a lot more by staggering the updates to clients like this: Frame 1: Update objects 1,4, and 7 to all players. Frame2: Update objects 2,5, and 8 to all players, etc. Or to go even further, if HL2 MP used deterministic physics (I know Gabe said it didn't, but bear with me), you could just tell the clients about the different forces that act upon the objects, and the clients could figure out the rest of it. No need for constant position updates, just let the clients figure it out.

I e-mailed Yahn, we'll see if I get a reply.

 

[dawdler]

Originally posted by Rabid Llama
(which wouldn't be as much as a player, as it'd just be x/y/z/pitch/yaw/roll for each object, or something similar.

That isnt all... You got your acceleration/speed/material/rotation/mass and the other stuff I probably forgot... At any rate, none of this is being sent by the server when they arent in motion. Actually playing a level shouldnt be much more stress than HL except for the new stuff added for the player. Once one start to interact with the level, the hard part comes... But keep in mind, the player is physically modelled and basicly another object with a few more additions. So its quite easy to estimate it. For example, a 16 player game could in *theory* have 16 objects moving around at the any given time, shouldnt be more work than a normal 32 player server. And 16 objects is quite alot if you really think on it. Someone that could host a 64 player game, but limit it to 32, could have 32 objects moving at the same time easily...

Well, that's just a theory, I'm probably wrong

 

[Rabid Llama]

Originally posted by dawdler
That isnt all... You got your acceleration/speed/material/rotation/mass and the other stuff I probably forgot... At any rate, none of this is being sent by the server when they arent in motion. Actually playing a level shouldnt be much more stress than HL except for the new stuff added for the player. Once one start to interact with the level, the hard part comes... But keep in mind, the player is physically modelled and basicly another object with a few more additions. So its quite easy to estimate it. For example, a 16 player game could in *theory* have 16 objects moving around at the any given time, shouldnt be more work than a normal 32 player server. And 16 objects is quite alot if you really think on it. Someone that could host a 64 player game, but limit it to 32, could have 32 objects moving at the same time easily...

Well, that's just a theory, I'm probably wrong

No, you don't really have to send anything you mentioned. The server handles all that, and models the actual motion of the object. The player just needs to know where the thing IS, for prediction purposes, so he doesn't get hit by an invisible swinging girder. The server knows where the player is, and where the girder is, and takes care of stuff like what happens when they hit (which is where acceleration, speed, and material come into play). It then tells the client "You take this much damage. You now have this velocity. Have fun." The client doesn't care about the actual velocity of the item for anything beyond simple prediction of where the item will be between state updates. Depending on how often these state updates happen, maybe the velocity data won't even be necessary.

Edit: once again making stuff up. I'm talking from my small understanding of how most client/server relationships in games work combined with intuition on how to write efficient client/server algorithms.

 

[dawdler]

Originally posted by Rabid Llama
No, you don't really have to send anything you mentioned. The server handles all that, and models the actual motion of the object. The player just needs to know where the thing IS, for prediction purposes, so he doesn't get hit by an invisible swinging girder. The server knows where the player is, and where the girder is, and takes care of stuff like what happens when they hit (which is where acceleration, speed, and material come into play). It then tells the client "You take this much damage. You now have this velocity. Have fun." The client doesn't care about the actual velocity of the item for anything beyond simple prediction of where the item will be between state updates. Depending on how often these state updates happen, maybe the velocity data won't even be necessary.

Edit: once again making stuff up. I'm talking from my small understanding of how most client/server relationships in games work combined with intuition on how to write efficient client/server algorithms.

Oh yeah, that make sense... Meh, its in the morning

Anyway, this is even better, as one could increase what I said. Say a 16 player game with 60 movable objects at any given time shouldnt be more stressfull than a 32 player game. Someone should really mail Valve and ask on some hypothetical figures.

 

[Joeyslucky22]

well.. I'll be ready for lots of patches with HL2.. just like HL1! it was easy to get and do too!

 

[dscowboy]

I e-mailed Valve but got no reply. Anyone else want to try?

 

[BlazeKun]

Here's my guess on the Prediction stuff. Say each update is x/y/z/pitch/yaw/roll. The client would not need anymore info than that because it would know that if the object was here, and now it's here, in whatever timescale the server sends the client info, then the client would be able to interperate those variables as the other parts like velocity. It's all basic math folks... You know... Train traveling this way at this many mph, other train this way... How long before they crash?

 

[Cunbelin]

More than that, the client can predict where it is going to fall, you can't predict where a player will go or do, Consider it this way, the server may only transmit what I'll term "collision events" to the client concerning the object, basically these would be collisions, not when an object was flying through the air, but when an object was hit by something, be it a player a bullet or an explosion. I don't know what would be more efficient, a collision event transmission including velocity, or two quickly sucsessive position updates for all objects involved.

 

[dscowboy]

The problem with physics prediction is, Valve said the physics engine isn't deterministic (though it could be made deterministic with a mod). Without determinism, the same initial forces would produce a different result on each client, like how the bodies in the Steam videos ragdoll differently than the bodies in the E3 QT video.

 

[Piecemak3r]

WOOT FOR HL2!!!

 

[ferd]

anyways i believe they will make sure everything runs smooth