GDC2008 Notes – Massive D: STRANGLEHOLD’s Breakable Object System
“Massive D: STRANGLEHOLD’s Breakable Object System” by Steven Ellmore
“None of this is rocket science”
“Breakable Objects”
Tool pipeline for constructing fragments/breakables
- mixture of off the shelf maya tools/custom scripts
- time consuming to author by artists
Custom tool to associate rules with fragments in object:
- rules for breaking (when)
- actions for breaking (how – not just ‘break’, thing likes tip, tear etc)
- weapon specific rules
One action type (send event to AI) gave birth to emergent behaviour like suppressive fire & other cool interactions like player shooting chunks of object, falling on AI, causing the AI to jump onto other objects & break them.
Breakables classified into four types:
- static
- normal
- debris
- effects
Used pattern styles to speed up asset creation, e.g. pictureframes breaking into one regular pattern. This gave cheap variation, but lead to technical challenges with propogating material breaks with templated replacements.
Eventually came up with not just linear breaks, tree recursion with inheritance generating complex behaviour.
Biggest issue – interpenetration big unsolved issue with breakables. Authored content to avoid it where possible.
“WooGlue”
Dynamic connectivity graph of fragments/actors, can be visualised as a tree with fragments on leaves. When told to break, used “connected components” algorithm (google it) to figure out how to split the thing. Allowed for things like breaking legs off tables but keep the table as a valid actor for cover etc. First test case was a heavily damagable car. Big win for the team once they got this working.
“Supporting Thousands of Breakables”
Edge driven – no movement, no update. Don’t call tick() on empty functions!
Limit polling!
Aggressively, but temporarily, remove objects that aren’t visible – make their sleep but stay in memory. Remove means not process physics/visual systems of the object, but keep the logic around for consistency – if something spawns or breaks into that space, we need to know about the sleeping object to prevent interpenetration!
When streaming out volumes, don’t forget about these objects so they don’t suddenly awaken without collision data to keep them from falling(???) – (got to be a better way of handling this).
Hibernate! More aggressive – destroys object but serializes persistance for breakable state! So whenever streaming unloads a volume with breakables, we’re saving data, and when reloaded, recreate the breakable using this saved data so we can restore it “as was” keeping the room filled with the carnage the player did without keeping the breakables around. (NICE!)
Limit Spawning! Only spawn 5 to 10 fragments per frame.Multiple frames to create all fragments for one breakables. If massive mayhem going on, skips some of the effects & fragments.
Important to keep original visual representation in rendered until all spawning is completed, then ditch original rep – keeps collisions/logic correct to avoid interpenetration etc. Particles hide a lot of these delays etc of course 
“Lessons”
Current system is heavily art intensive – better tools will give better results by decreasing art creation time.
Supporting large number requires system wide architecture to back it up.
Huge plus in final game, took a while for designers to figure this tech & the implications of it (emergent behaviour, set pieces etc).
Next gen – DMM-like material stresses, fracture analysis etc using better WooGlue graph analysis to split graph & create multiple logical actors with the split fragments (e.g. breaking a table into two large chunks that can still be used as cover pieces – current system can’t split them into seperate actors).
My thoughts: Good straightforward talk covering good solid use of technology that gives great results without requiring cutting edge next-gen math/tech – as they said, I’m sure with time on tools, they’ll greatly improve their pipeline. Good food for thought with regards to our own tech moving forward.
