Sure, explosive projectiles are one thing, but then you’ve to make things take damage… and die.
Gone to Pieces
This caused me no end of pain in Project Y4. I’m not a particularly good animator, and FK animations are not ideal for explosive break-ups as it is. I had a few half-hearted keel-over animations that were too fast or two slow, where I’d try my best to mask the shonky movements with blistering particles and swapping to a battered wreckage texture.
Making things fall over convincingly, it turns out, is a Very Hard Problem.
Luckily, this time around, Unity has a built-in physics engine.
The first answer to this problem came easily enough. In the six-day-prototype, I used a single mesh chopped into pieces — when the AP-AM there died, the entire thing replaced itself with the cut-up version and it fell to pieces. Job done? Nuh-uh.
The cut-up version of the mesh was not animated. Even if it was, it wouldn’t have been synched up to the motion of the unit that previously existed — it was something new, something independent. When the AP-AM died, you could see the pieces fall, not from the pose it held when the death-blow struck, but from the default standing position.
It might seem like a small thing but annoys the fuck out of me about Starcraft II — units with alternative death modes for burning and suchlike suffer from this very same lack of blending. Most obviously the infested terrans in that Raynor mission as they walk towards you and immediately revert to standing stock still as they are roasted by the fire car things.
So, while that old strategy works and should continue to work for static decorations, it’ll never fly for my units, my characters. Those mechs might be reasonably sized in terms of real scale (the Delta is maybe 5 or 6 metres tall), but they will take up quite a bit of screen space so I want them to be detailed. Since it’s not like I can compete on graphical fidelity, I’ve got to make do with other details. (Details that are, conveniently, more important to me anyway. Can’t make a good game if you’re not feelin’ it.)
Of course, that’s not the end.
It’s all very well to have things disintegrate, but nothing dies cleanly in this world. Large robots don’t just fall to pieces, they explode in a shower of fiery shrapnel.
That means you can’t just bring the pieces into existence, you have to apply force to them. Not just one force, though — you’ve got to combine the force of the explosion that killed the unit with force of the explosion from its own core plus the unit’s overall motion at the time of death… And you’ve got to adjust the force of each explosion by how far a given chunk is from the epicentre of the explosion…
The mathematical model is simplistic enough, but the results are totally worth it.
So my disintegration strategy involves making things out of pieces, as befits my dreams of modularity. I have an invisible skeleton that is the actual unit, upon which I dangle the discrete components that make it up — pelvis, thighs, calves, ankles (those are new; added so the Delta can sidestep), feet…
That’s quite a lot of stuff to hook up, so naturally I don’t want to have to do that by hand for every single unit I ever place in a scenario (especially when I want to dive into pseudo-random variation of individual components along the way). Before I could go near death and destruction, I first had to program a mechanism that would spawn my units based on simpler settings.
As is always the case, Unity threw some spanners in my works. Sometimes a missing piece would kill the entire game in an obvious way (that’s good, easy to fix), other times a forgotten component would silently leave the unit inactive (that’s bad, hard to find). Forgetting to give my invisible skeleton a renderer, for example (since, well, it’s invisible and so doesn’t need rendered — right?) meant that the animations never played. Forgetting to assign an AI behaviour (they still ominously turn to face the cursor) meant the unit wouldn’t even get to the point of being affected by gravity.
Okay, okay, those are the fault of my own internal scripts as much as my ham-fisted understanding of Unity and its methods. Either way, it took some wrangling. Actually wiring up the wreckage spawning after all that was a piece of cake — take an identical wreckage mesh and place it in exactly the same place as the dying part.
Job done!
Rao Dao Zao 
Cool up date , I was waiting for one .
The animation is pretty good however I think some of the pieces should stay together when it is destroyed .
Strafing is very important I got half way through Ratchet and Clank without taking any damage because of strafing .
I think the mechs may be moving a bit fast they are six meters tall and most likely weigh a fair amount so perhaps you should factor in some inertia or more of it .
I see you have introduced fall damage as well , you can perhaps make the weight of you equipment factor latter on .
One step closer to a finished product and just remember to try to avoid getting bogged down in the details do what is crucial to game-play first them niceties . ( a problem I have which often prevents progress )
LikeLike
My model for the game is Nox, which did not include strafing, so I’m still counting it as an optional extra. It might depend on how melee/ranged the final scenarios end up being; obviously this is early days so I’m focusing on getting the simplest unit right before I layer on melee attacks and abilities.
Inertia is annoying, that’s why I always prefer Unreal engine to Quake engine. UT is my model for movement — high speeds, instant stopping and turn rate as fast as the player can move the mouse are non-negotiable. Enemy units have to act under the same constraints as the player to remain convincing (i.e. so they do not appear to cheat), so they will also be fast and have no inertia (their turn rates will be slower than instant, but they might make up for this by being able to independently rotate their turrets).
It might sound silly, but this kind of detail IS crucial to the game. I have now effectively implemented every single death animation I will ever need.
LikeLike
“It might sound silly, but this kind of detail IS crucial to the game. I have now effectively implemented every single death animation I will ever need.” I wasn’t implying that this isn’t necessary I was just humbly reminding you of a common problem developer and people face .
LikeLike
Statisfying kills are very important in games about blowing things up. Looks good, if you’ve got complicated bosses I can’t wait to see them fall apart!
If you can kill units with freeze weapons, you might want to freeze some components together while some others still fall apart from the internal explosion. Makes for some additional graphic diversity between damage types.
Have you also considered making some of the components themselves glowing hot while they fall? With more components glowing if there’s more temperature involved? (ie: laser,missile vs bullets)
LikeLike
I could do with some more particle emitters in general, it’s early days yet. Right now, it’s the exact same mesh that is dropped with only the wrecked texture instead, whereas eventually I’ll want physically crumpled/broken versions, and maybe even drop two smaller chunks instead of one whole one.
Sticking components together would be nice but probably too convoluted. I figured I might be able to ragdoll subcomponents, do something like keep one leg intact and flopping around, but it seems like too much effort with systems I don’t really understand. It wouldn’t tie into my current scripts very nicely either.
I don’t want to think about freezing yet, but it would be nice — I have a plan for temperature mechanics, something a bit better than the one I half-assed in Y4 (heat will apply to all units and not just the player, for a start).
LikeLike