Our “Rules”

These are some of the rules we work by. Maybe you’ll find them helpful too:)


  • People don’t like to read instructions. They might watch a video. If it’s short.
  • The question is never if something can be done but if the time spent is outweighed by it’s usefulness.
  • Credit those who help you or who’s work you use a a base.  Our industry is small.
  • Document your code. Be considerate, you could die tomorrow
  • “It’s always been this way” is not an acceptable reason to not try something else. “We tried that and it didn’t work because x” might well be.
  • “I don’t like that” is a criticism with no practical value. “I don’t like x because y” is better. “z might work better than x” is better still.
  • Don’t reinvent the wheel. If there is a perfectly good tool out there, why make another?
  • No pymel in the base libraries. For why, see this post from one of our favorite toolmakers.


  • Tools should be intuitive and efficient. One button doing different things depending on what is selected at the time it is pushed  is better than 4 buttons to handle those tasks.
  • 3 steps is better than 4, etc..

GUI Rules

  • Tools should attempt to usefully load selected objects into a gui if the logic checks (one less step)
  • When a tool creates or updates something, it should be selected at the end
  • When a tool requires a selection, that same selection should be selected at the end of the process unless something new was created
  • Function Priority
    • Selected
    • Loaded


  • Rigs must scale.
  • Everything created shall be named
  • Any hard stored positional information (as in on an extra attribute) will be stored in cm (maya’s default unit) and should be translated on call to your local units
  • Controls
    • Every animation control must zero out
    • Main controls should have at least one constrainable group transform above them
    • Rotation orders deserve some thought.