Snarkpit Articles



Physics Props

What is A Prop_Physics?

For multiplayer levels in the Source Engine, one expects a lesser degree of physics interaction than with the single-player counterpart. For the most part you'd be right, but Valve and the team behind Half-Life 2 Death Match put a bit of extra effort into the network code enabling proper physics models to perform adequately in an online environment (contrary to popular beliefs about Valve making HL2DM as an afterthought project). So with that, you may be already familiar with the entity: prop_physics. This is the primary entity used to render single physics-based models in-game. That is, any model needing to be kicked or picked up or interacted with the environment of the game should be placed into the level via this entity.

Now, this entity is great for single-player games, and I wouldn't use any other, but for multiplayer games, this entity may not always be the right choice, but we shouldn't eliminate it from our dictionary of multiplayer entities just yet!

Benefits of Prop_Physics_Multiplayer

prop_physics_multiplayer is pretty much identical to prop_physics in just about every way except for the most important way in the eyes of a server. Models existing as prop_physics_multiplayer have a much more 'bouncy' and less accurate method of collision detection (taken from article at EditLife). This is so the server takes less stress when attempting to calculate EVERY player's collision interaction with a physics prop on the fly and can focus its saved processing power for other things. The 'bounciness' is due in part to the automatic collision detection applying a generic 'bounce' force against the player and other possible collision surfaces instead of calculating the rigid collision mesh that would otherwise be used to calculate how a model sits on a surface. It's because of this type of automated collision detection that you would not want to use this entity on objects intended to be picked up by the player and used to slam another player in the face with, because it may not detect their face at all! -It's too cheap.



Now, when attempting to place down some eye-candy models in your mutiplayer level, you'll want to consider their size and purpose. If their size is really big, then it should be an automatic inclination of you as a mapper to make these a prop_physics because they are more likely than not to be encountered by and perhaps even used by players as part of the game environment (especially in HL2DM). Now, if their size is small and most likely won't have the intended use of being thrown at a player or stepped on, then it might be in the best interest of the mapper to go ahead and turn these kind of entities into a prop_physics_multiplayer. Now of course purpose is not always correlated to size, so understanding what the prop_physics_multiplayer entity does, it is up to you, the mapper, to decide whether an entity deserves to be rigidly calculated or just simulated.

It ought to be noted about making a few other checks before keeping this entity in your multiplayer maps. be sure to check under the 'Flags' tab of this entity: "Debris - Don't collide with the player or other debris." This is important for entities you do not want to collide with the player. Simply placing them as prop_physics_multiplayer will not keep them from getting in the way of a player. Similarly, you may check "Prevent pickup" to prevent further player interaction, but usually the 'debris' flag will cover this. Also of note is the "Force server-side (Multiplayer only)" flag; only check this if it is important that this prop_physics OR prop_physics_multiplayer entity is needed to be synced at the same time for all players. (like a large boulder barreling down a mountain to kill several players at once). Anything made 'server-side only' will only cause more lag across all players connected to that server. Generally it's a good idea to avoid this flag. It's also important to note that you should use either 'physics' entity sparingly; they are both resource hogs somewhat compared to other entities.


Possible Suggestions:

Set to prop_physics_multiplayer if:
  • garbage debris only meant to collide with other debris
  • environmental effects to be 'pushed' (physical leaves, dead fish, small bricks)
  • tied physical entities (bag on a punching bag stand, dangling ornaments, swinging lights)
  • distant unreachable objects meant to move physically
  • falling models that are numerous (concrete chunks from a ceiling, apples from a tree, books off the shelf)
Set to prop_physics if:
  • large objects expected to come in contact with the player
  • deadly objects by mass (falling boulder, guillotine)
  • need accurate collision detection (round ball in a square hole)


Prop_Physics_Respawnable

One last note: prop_physics_respawnable are another entity used commonly in multiplayer maps. Their physics calculation is exactly the same as the expensive prop_physics entity (because it is assumed this entity will be used to smash other players in the face). The only difference is their "respawn time" keyvalue. It only applies if the entity can 'break,' otherwise it is useless for those entities that can't explode or break apart. The default time is usually 60 seconds. Make it longer if it is a 'game-changer' or really popular throwable prop; this would make it more rare and special. Okay, I think that's enough about physics entities smiley


>Next up, the ultimate tool, Player Clips!


Post ReplyView Topic
Discussion
0 starsPosted by Gwil on Fri Jan 1st 2010 at 2:12pm

Great tutorial Riven - picks up on a finer nuance of gameplay that people might otherwise miss when finishing up a map.
5 starsPosted by G4MER on Thu Dec 31st 2009 at 2:59pm

Great Tutorial Riven. I learned a few new things from it. I cant do the player clip tut now.. but that is ok, I think you did a much better job of explaining than I ever could. smiley

I like how you laid the tut out as well on several pages. Made the content easy to follow and read.
Post ReplyView Topic