For the dude with the manly name.

I feel the need to explain how this is all "technically" possible with current tech. I'll preface by telling you that you would need a relatively newer computer but if you can run BF3 at full specs then you'll at least be able to run mine at low end full 32fps consistently. I've worked diligently to maintain that number even under the most brutal explosions and building collapses.

A lot of this comes from omission in which simply if you're not looking at it then it's hidden and if it's in motion and hidden it's still being processed but much quicker due to not needing to be rendered. Objects that are naturally hidden other than buildings are simply removed until you're in proximity, more specifically they're never there to begin with until you are and go away when you're not around. When a building collapses they're removed unless you're in there with them in which case they're treated specially to avoid excessive computation from all that bouncing around you know they'd do.

After a building collapse I cheat a little and use a lot of dust to hide things to increase processing speeds by removing rendering of the now almost impossible to see building, but I assure you I'm not swapping things out in that dust, all the buildings dynamically fall and damage other buildings which means I couldn't do that if I wanted. The entire building is set up in a destructible fashion but is also set in chunks that are responsible for large sections breaking away which can be manipulated to save valuable processing cycles. Again by using instancing I generally save a lot of processing by only having to change location and rotation values which is also easier to process in this destruction process.

I take heavy advantage of RAM when it's available, you'll need no less than 4GB to run this and if at all possible I'd honestly suggest up to 16GB though 8 should suffice to run smoothly at full settings. I basically load as much of the game into ram as I can to significantly increase data rate to feed things to the processor instead of waiting on the hard drive to respond for info requests. By more or less loading the entire game into RAM you'll almost never see a loading screen after the first and if you do it'll be short in addition to never having to deal with chugging frames.

It's sad that the Ageia PhysX card went away / got taken over because a dedicated PPU would make my job much easier. Granted NVidia and ATI/AMD now use graphics cards with thier linking systems respectively SLI and CrossFire to use a graphics card as a PPU however in my experience at the time when PhysX came around it stomped out graphics cards trying to do its job and continued to do so even after NVidia took over for quite some time. Now there's no competition it's a worthless card but what if it had continued down its path as a stand alone? I would love to see what it would have become because almost any game dev could use that to make a game like mine and never worry about a lot of these things. I will recommend that you have a secondary graphics card set up for physics for my game as I will be taking advantage of it, however I will also state that it won't be necessary it just makes things a little smoother and accurate.

A lot of my physics is almost a complete cheat. While I do in deed have a full physics system programmed to run so far it's hard to run it with low settings and a single GPU and still maintain frames so I had to find an alternative to support it. On high settings you'll get the real physics running and it'll definitely show. On low settings I've essentially created smaller variables with less dependents and don't require absolute outputs instead there's a lot of guess work involved. A sniping scenario for example, mid to long range in urban area, there's streets with wind blowing in a relatively consistent direction but at different speeds and other variables. In the full physics settings you'd actually calculate each variable to determine exactly where to shoot. In the low end settings you end up grouping all these variables and getting one relative value of offset and get a vague idea of where the bullet should go and that's where it lands. By precisely calculating the bullet let's say it hits the mark dead on after you've accounted for everything, but then you switch settings and none of the variables have changed one bit, now you shoot again and instead of hitting the mark dead on you're now nearly 6 inches off mark. It might not seem like it makes a difference in vague talk but I'm sure that example makes it clear, on low settings the computer just guesses a random area of where the bullets lands and if you make that shot 100 times you'll probably never hit the same spot twice, where as with full settings so long as nothing changes you'll hit that same spot every time.

The buildings collapse isn't actually determined by normal physics running in the game instead it works on an architectural algorithm to determine stability based on remaining structural supports and when it's determined unstable it collapses based on that information. To save from constantly processing this info it's only calculated whenever a structural support is damaged there by saving a lot of processing. This is primarily why the building is separated into chunks because each chunk depends on a specific support/s and if they've become destroyed part of the building may collapse while the rest remains intact.

Truly the most intensive thing in the game are explosions and boy are there a lot of them. I've tried and tried to reduce the time it takes to calculate everything in an explosion and I've met with minor successes yielding enormous results but I can go further and I know it. Right now the game can handle roughly 30 explosions simultaneously in and around each other in which has been included with physics programming to group any overlapping explosions and cut processing on that. On lower settings I've also removed the shockwave effect other than determining it's intensity and distance to shatter windows but other than that the rest of the effects have been removed on low settings. On higher settings the player can get knocked over or suffer various effects from simply being to close to an explosion and surviving. This also effects bullet physics for all players which thankfully doesn't require much processing to handle. The majority of explosions are all player controlled so I've been working heavily on the grenades and c4 etc to try and preprocess as much as I can and have various computers in the same network all process the data in parts and simply relay all the parts around but doing so consistently had been proving difficult so I'm rethinking that right now trying to find a suitable alternative. I haven't been successful in transmitting each players explosion around and simply having each computer process whatever explosion it's responsible for then simply sending the renders around because it only works when there's just one explosion and doesn't account for all other explosions in the same area. Right now basically every player has to process all the info by themselves. In persistent world this isn't a problem because it's handled by the various servers which all process it all at once and tell every player whats up. So when it comes down to it I need to find a more efficient method of creating and calculating explosions which right now I'd say I've got half complete. Basically the explosion is just an animation and the rest is a matter of behind the scenes work based on it's output radius for the various stages of the explosion. What I need to make better is reactions to this information, reduce the number of times anything gets calculated in relation to a given explosion so that way it doesn't get done several dozen times right away, instead it'll only be calculated once and force it to go through a specific process and time before it can be allowed to be recalculated again and if I do it right then I should be able to increase my number of simultaneous explosions in the same area to at least 100 if not closer to 1,000 which should suffice for any scenario.

Last but not least is just an addendum to structural design. Inside every building is a series of triggers to play around with lights, and various other things linked to an object that if damaged cuts "power" to the building preventing lights, and other things and this is important because it's not alone. I also have "gas lines" which when shot simply output a particle stream of fire which can damage the player etc among other things you'd expect to find in a building. What does this matter you say? I'm completely removing it from multiplayer because it's a great source of frustration and wanted to see if you would miss it in campaign or if I should work diligently and dedicate resources to making it work in multiplayer. Not many of you to say much but I'll still take it under consideration anyway. Chances are I'm taking it out all together, however I may just put it in a subsequent future game if it's something you'd think you'd want.