AnimationPipeline.Com

Here is a re-post of Kevin Cureton’s great article on naming conventions…

Every time that I’ve started working on a production, be it a film or video game, the issue of naming comes up. Nobody likes the way things have been named on previous productions, and yet no one wants to be the person that creates and enforces a naming convention. Can you blame them? It’s never fun to be the person who has to put the figurative “smack down” on a production team to get them to name things correctly.

Naming conventions can have various levels of stringency. The most basic of naming conventions covers just the characters used to name files and directories in a production tree. A step beyond that could be setting some rules for naming files of a specific asset-type. And so forth. I imagine with some effort you could cover most every file in the production.

So what is a good balance between the chaos of having no naming conventions and the draconian restrictions of too many? Before addressing that let’s take a look at why naming conventions are necessary.

Why Have A Naming Convention?

Here’s my answer; so that the production can run smoothly, efficiently and focus on the creative issues of the product instead of the minutiae of the production processes.

Does a naming convention really do all that? No, not by itself. However it can help to create an environment in which you can have an efficient, smooth and creatively satisfying production experience.

The most basic benefits of a naming convention include:

1. Makes the naming of files and directories easy and predictable.
2. Becomes easier to deal with a large numbers of files and directories in an automated fashion (e.g., batch scripts).
3. Facilitates the transfer of assets between productions.

For a large production the second benefit would be reason alone. The automated processing of data is critical. Whether you think you will or not, you will be, at some point, automatically processing some or all of your production data. A naming convention will greatly simplify the scripts that you will have to write to perform the automated processing.

There you have it: a strong, compelling reason for instituting a naming convention. The next step? Figure out exactly what the naming convention should be!

What Should The Naming Convention Be?

All files and directories should contain only lowercase letters, numbers, and underscores.

This is the minimum basic convention that you should employ. Even this simple convention can help considerably for technical tasks, like those involved in the automated processing of data.

* Files and directories are sorted consistently.
* The generation of file and directory names is straightforward.
* The parsing of file and directory names is straightforward.
* Regular expressions won’t require complex quoting of special characters (which is often a source of bugs when writing regular expressions).

This can also have a positive impact on your production team.

* Separation of words by underscores is easy to read. It is a natural mapping from words being separated by spaces.
* It is easier to deal with a large volume of files visually.
* It is easier to navigate directories of files for someone whose first language is not the same as the production team’s predominant language. In the realm of video games this can have considerable impact on the effort it takes to localize the game for another country.

For the productions I’ve been a part of, this simple convention, coupled with asset organization conventions (more on those in another article), make the development of production scripts straightforward. Wouldn’t you rather spend your time working on a practical production issue instead of figuring out how to locate the data?

You can extend this convention beyond what characters can appear in file names. However, you should have a solid reason for anything beyond the basic convention. The danger is in having so many conventions that people can’t remember them all. You can publish the conventions all you like, but if a majority of people can’t keep them in their heads then they won’t get followed.

One of the most common places for extensions to the naming convention is in the various production disciplines. Modelers, animators, lighters, texture painters and FX developers all have workflows that are tailored to what they work on. It follows that you would build upon your basic convention differently for each discipline.

When you want to extend your convention ask yourself these questions:

1. Does it make it easier to write production scripts and tools?
2. Does it address an area where asset naming is inconsistent or inefficient?
3. What effort would it take to deploy the convention? Don’t forget about the time required to train the users on the new convention. There will also be additional support issues during the transition period.
4. Do you already have more than 5 or 6 conventions in place for a particular production discipline?

Answering these questions should help you to refine your reasons. There are no hard and fast rules. Trust your instincts. Only you know your production and the people involved with it.

If your production has never had a naming convention, start with the basic convention. Just getting your production onto that convention will be challenging. Once you have that solid base you can begin extending your convention where it makes sense.

Automated Enforcement vs. Social Pressure

Once you can get a team to agree on naming conventions, then the next question that comes up is how to enforce those conventions.

Some level of technical enforcement is typically the initial approach.

* Write all your scripts so they name files and directories correctly.
* Have scripts stop processing or “error out” if files or directories aren’t named as expected.
* Create scripts that build placeholder structures for your assets, complete with correctly named files.
* Have your asset management tools enforce naming during the importing of files and directories.

The other common approach is via social engineering.

* New user training.
* Ongoing production training.
* Peer guilt.

Where do I stand? I am always in favor of technical enforcement when it makes sense. Technical enforcement should serve to remind people of the correct conventions. It can, however, get to be fairly complex to manage. I would suggest putting your logic for naming conventions into a common library or module. All tools can then leverage this common code. Additionally, writing code to enforce your conventions is the best way to understand the complexity of your conventions.

I feel that in the long run social engineering will give more lasting results, especially if the studio takes training seriously. Productions really shine when they have a strong training program. New users are more productive faster and understand the production processes more completely when they get good training. Naming conventions (along with asset organization) should be the cornerstone of any production training curriculum. With ongoing training all users will know what the conventions are and why they are important.

When used in conjunction with technical enforcement and training, peer guilt can easily get you 99.9% compliance with naming conventions. There is no better reminder than having your cubemate turn around, tap you on the shoulder, and point out how your misnamed file broke her automated processing script!
So Get To It!

You should now have enough ammo to go to your manager and request the time and resources to help get a naming convention in place. The time you save during production will greatly outweigh the time you spend getting a convention up and running. Time is money to a production. Nothing makes a producer’s eyes light up like saying “We are ahead of schedule!” And you will have your naming convention to thank.

–kev

Editorial support from Steve Carter, Marlon Montgomery and Courtland Townsend.