Posts tagged ‘processes’
June 13, 2008
The one thing I’ve learnt from game development is to keep things simple, flexible and modular. Here are some things I’ve learned. Modularity and flexibility is the key!
- When making assets, rigs, effects etc keep things on a granular level. Have tools to save/load the: skeleton, vfx nodes, collision objects and LODs.
- Keep the rigging systems modular – have setups to build just arm rigs, hand rigs, leg rigs etc.
- Keep the all the assets pertaining to one character on the same rig! Including the animation. Keep all the clothes, faces, face elements on the same rig. And have export tools to export each.
- With animation keep it very simple – only export the animation on the controllers and nothing else. If they exist on the rig load them, if not skip them. It allows a TD to update the rig, change it – do essentially anything to it and the animation will live on.
- Keep file formats consistent – if your using xml, keep elements inside the structure the same. e.g. <NODE> object01</NODE> means the same thing for a vfx node exporter or a skeleton exporter.
- Also remove the ties to your one application, with simple exporters.
- With skeletons – keep the axis order consistent throughout the rig if z is up keep it up for everything. Mocap solving becomes hell if its not.
- Allow you rig to use mocap – and keep this simple i.e have tools to just build mocap rigs and constrain your character rig onto it.
Also always set remits on the tools, and throw questions at the development. e.g.
Animation Export v1.0
- Only load controller (puppet) animation.
- Skips if it cant find contoller (puppet).
Q. What if an animator deletes part of the rig?
A. Export all the animation there is, load the rig back and load the animation onto it.
By keeping everything at a granular level it allows technical direction to spot problems through the production and fix just them.