Sunday, September 5, 2010

Droids - Today a Robot Must Die

Robots need to die, or soon they will enslave us all.
Or at least, droids that shoot other droids need to get shot and die as a result.
Kaaaaaa............ BOOOOOOOOOOOOOOOOOOOM!
My droids are now exploding a rather fun fashion, with physics included! Since my model is composed of many Blender objects, the droid isn't a single mesh but a series of game objects tied together. On the droid's death I add a RigidBody to each part, as well as a Collider whose mesh is the MeshFilter's mesh. After that I unparent the parts from the model. Then I can apply forces as I wish!

I didn't want to have the parts interact with the CharacterControllers of the living players. CharacterController is a subclass of Collider, but I couldn't get it to work with Physics.IgnoreCollision(), and I'm not the only one. Embracing the limitations and assumptions your framework uses is a very key step to moving forward. Writing my own CharacterController may be in the future, but in a 3D environment I believe that's a lot of work - work I don't want to put in right now when I could be fleshing out game ideas. My workaround was to make the Z scale on the platform longer. When a droid dies I translate it's Z away from the camera. In an orthographic view, this has no effect on the visual. Because I'm constraining the parts to only explode along the X/Y axises, the parts "behind" the living droids never touch. Since there's no interaction I can keep this all client-side. There's no need to sync explosions (other than a single RPC call to notify the clients of the death). I actually scoot the dying droid so some of it hangs off the edge of the platform. This makes some parts hit the platform, others fall. The body usually tips and rolls off. These are all great effects for very little work.

Here's the core of the code:

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.