Game Development Community

Destruction engine on a MMO?

by Terra Snover · in Torque 3D Professional · 01/16/2010 (5:07 pm) · 9 replies

I'm working on a MMOFPS using T3D, and was thinking about adding the Physx Destruction engine to the game. The game is set in an urban environment (small city). I want walls especially to be breakable.
But alas I don't know if this is something I can do because I get the felling that adding any Destruction engine would bog down the server so bad the game would not work. So what I need to know is could I use Physx Destruction engine for this or is it just a bad idea, and if it is a bad idea what else can I do do make things in the game breakable with little to no bog down?

#1
01/16/2010 (5:15 pm)
Well, it depends on what you want to do with it. Are the breakable objects going to affect gameplay at all or are they just going to be a nice effect? If it's just the effect you're going for and not going to affect gameplay you can just do it on the client side.
#2
01/16/2010 (5:29 pm)
I want some of it to effect gameplay. Like you can brake a wall and make a hole into the next room, and that wall is forever broken for all players on the game.
As for the effects I should just run it client side, that makes life simpler.
#3
01/16/2010 (7:00 pm)
It would raise the costs for your server significantly, but actually even worse is that each object thats destructed creates masses of traffic as each piece will become an own network object.

Thats not realistically doable, at least I personally don't think it is.
Even DICE had to reduce the number of parallel players and the "active combat area" in Bad Company 2 drastically to cope with the destructability.
#4
01/16/2010 (7:50 pm)
I think the latest Red Faction kind of answers the question; they've limited the game to 16 players, and with reduced physics destruction in multiplayer.

Here's something you could try... make the destruction event itself networked, but have the resulting debris be client side and not obstructive to the player (no collision w/ player, or just pushes aside without slowing them down). This way you could have the destructable wall you talked about, without bothering to network all the random pieces of junk that come flying out of the broken segment.

In this case, physics updates are only sent at the moment something breaks. The actual effect for this is done client side, and while it won't be identical on every screen, the big gaping hole will be.

There might still be a lot of overhead here, but it would be an improvement. I'm using GMK's Bullet implementation at the moment, and I've had a lot of luck creating client-side only physics actors for things like debris from larger explosions. For example, when a medium-sized building is destroyed, it might break into 2 actual networked physics chunks and 10 client-only smaller chunks. After a bit, the networked bits lock themselves down as static objects w/ the same model in the same place, allowing a battlefield to be littered with old debris from destroyed structures and vehicles without all that network traffic. Over a longer time, they gradually fade away entirely.

The client keeps the most recent (this is a user option) 20 or so client-only physics objects, and when a new one is added for an effect, deletes the oldest one. If a new client ragdoll appears, it may remove a few client objects at once (or just 1 other ragdoll).
#5
01/17/2010 (1:10 pm)
Is PhysX's destruction engine deterministic? As in, if you apply the same force at the same location, are the results always the same?
#6
01/18/2010 (12:39 am)
I'm not sure about that, but even if it is, the problem is that objects aren't really ever 100% accurate on the client vs the server, simply because of varrying amounts of interpolation and lag compensation, not to mention the lag itself.

So, even if you can be certain the exact same values will result in the exact same results, there's still the issue of making sure the objects start in the same positions. And the fact that any destruction event started by the server will reach clients and fire off at slightly different delays.
#7
01/18/2010 (12:56 am)
@Steele - By "Physx Destruction" you mean the new Apex stuff? We should be getting beta access to it soon and will begin experimenting with it ourselves.

My suggestion is to do destruction like the Battlefield Series does in the Frostebite Engine...

- Pre-author art to be broken off in bits.
- Syncronize what bits are broken off on the server and clients.
- Broken off debris do not effect gameplay.
- Broken off debris are not synced with the server.

@Manoel - PhysX is deterministic if the simulation starts in the exact same state, gets the exact same inputs, runs on the same CPU make, and not it their 'fine grained' threading mode.

So while its possible... its hard... and even then there will be cases you need a correction. For this reason i don't think its worth chasing determinisim as a way to do less networking.
#8
01/18/2010 (1:29 am)
@Steele

A few other tips from our experience...

Don't overcomplicate your breakable objects/buildings. You don't need to break every little brick and board off one at a time to make it an enjoyable and convincing simulation. Break off big chunks of your object with a few spawning debris elements and alot of particle effects and sounds.

Joints in general are hard to manage and trying to pull together a complex object held together by joints is difficult. Physics engines for games are not up to the task for the forces generated by lots of interconnected objects... they tend to jitter and have trouble coming to rest. It also just wastes cycles as its trying to hold your object together... if your object is normally solid until broken... don't use joints.

So you should avoid using breakable joints as the driver for breakable elements. Instead look for strong contact or explosion forces on your actors and use that to trigger a break event yourself.

In general always drive the physics engine from your game logic... don't let the physics engine drive the game uncontrolled.
#9
01/24/2010 (12:15 pm)
Thank you all for your help I think I know what needs to be done now.