Managing Assets – Part 2: Setting Naming Conventions

This is the second part of the “Managing Assets” series of posts and deals with asset naming. If you missed the first part, on asset quality, you can find it here.

Asset Management - Part 2: Setting Naming ConventionsAsset naming conventions reflect a really simple concept: How to name assets, or parts of assets. However, when it comes to adhering to those conventions, it’s anything but easy.As with the previous post, I’m going to take a look at the conventions by using Maya’s Dress Up as an example. My examples will focus on image assets but what I’m going to say can again apply to other rich media.

Use self-descriptive names

The rule of thumb is that from the name one can understand what the item is.  When I say ‘one’ it does not mean you who created and will name the file, but anyone in the team who might make use of, or need to reference it, either now or in the future.

For example, the filename “bigboss1.obj” is not very descriptive, while “final_boss_lvl_01.obj” is surely better.

In Maya’s Dress Up we use the term Garment to denote anything that Maya might wear. This can range from a different hairstyle to dresses or a bracelet.  The garment assets are saved in a directory structure like:

  • Wardrobe/Accessories/Gloves/
  • Wardrobe/Bottoms/Cropped/

When we began work on the game, a garment was identified by its full path, for example the ID for a set of crimson fur gloves would be “Wardrobe/Accessories/Gloves/Fur_Crimson”

Some time after release, we realised that this was not efficient and we decided to use the filename as an identifier.  This created issues as we now had duplicate filename issues as:

  • Fur_Crimson (the set of gloves from Wardrobe/Accessories/Gloves/)
  • Fur_Crimson (a fur scarf from Wardrobe/Accessories/Scarves/)

Our mistake was that the name was not self-descriptive. We did not lay out a future-proof naming convention for the garments, while we did pay serious attention to colour naming. After discussions, the following convention was used:

(material i.e. velvet)+ (style i.e. Tank) + (subtype i.e. cropped or sleeveless) + (type i.e. top or pants) +colour

Now, valid garment names would be something descriptive, such as OvalBuckleBelt or SuedeJacket.

Not all of the elements had to be used simultaneously, but the end name had to be descriptive.

Once this was done, the whole wardrobe had to be properly renamed – and unfortunately, this escalated to:

  1. Renaming all layers inside PSD files (one garment has about 5 layers and there are hundreds of garments).
  2. Validating correctness of names.
  3. Re-exporting all assets to high quality.
  4. Creating assets again for iPad, iPod/iPhone and Retina display.
  5. Creating a relationship table (old garment name – new garment name) to safely transfer a player’s saved styles to the new format.

So, we certainly did learn a lot from this and we hope by explaining it, it will help you to avoid such a scenario. Plan forward and see what might work for your game to avoid extra costly (and perhaps boring!) work.

Enforce the rules kindly but firmly

If you have rules about how you want things named in your projects, tell the asset creators first. Don’t assume they will know what you want without you telling them so.  Psionic (“mind-reading” for those of you without a D&D disposition) powers are not out yet.

Give clear instructions, and explain why things have to be named in such a way. Explain to them that Box01 or Layer9 will simply not do.  Make the artists part of the whole asset processing cycle and describe what happens to the art after it leaves their hands. A good artist will immediately see your point. Doing the opposite negatively affects teamwork.

After the naming incident, we created a set of guidelines for the artists here in Total Eclipse. In it we say something like:

What goes on once the artist delivers the artwork

Our task is to export all those garments, one for each colour, to be used in the game. We know that when artists paint, each garment may have a lot of layers inside it.

Here’s what we have to do for each item after you finish:

[procedure steps described for exporting stuff for iOS]

You can help a lot with points #1-5 by following a few guidelines for naming and organizing stuff. We’ll summarise them here and then explain why we need them and what it is that happens.

Our guidelines then contain guidelines like:

Put unused layers in group UNUSED. Colour the group in red.

Keep layer naming understandable. Don’t name layers as Layer15 or Vector. Either group them under a sensible name or rename them.”

If you don’t want to pressure the artist, or if you are the sole creator and really can’t bother, think about this:

Five years down the line you want to re-export the assets for a new device but a) the artist has left or b) you haven’t opened the PSD in said 5 years. You will have frankly no idea what is layer 56 and Group 2.

Scripts are your friends

Enforcing naming conventions is one thing but checking that they are being followed is another one entirely. One obviously cannot be expected to look at layers or directory files one by one.

In certain cases, like with PSD files, we are using Photoshop scripting to check things for us. The script loads a text file with the correct file names and checks it against the PSD. If any layer is named differently or is not found, the script gives an alert. Check out PS-Scripts for a similar source. The site is a treasure-cove for Photoshop scripting .

Some things to watch out for when dealing with text files.

  1. Make sure that your script checks for Upper/Lower case compatibility. OS X and the Unix file system are very VERY strict on such things.
  2. Try to avoid spaces in your file names or at least make sure you ‘escape’ the space characters properly.
  3. When you use text files make sure they are saved in the correct encoding. DOS and Unix save end line and EOF characters in different ways and parsing a text file line-by-line may lead to problems if it’s not in the correct encoding.
  4. Use a good text editor (avoid notepad) such as UltraEdit. In fact I can’t recommend UltraEdit enough, for all kinds of scripting. I think I’ll write another post dedicated to level scripting and UltraEdit.

Another thing you might need to do is recursively rename files spread on different directories. If you have a Windows system, DOS batch scripting is a really useful (albeit sometimes frustrating) tool to work with. You can have conditional and nested statements making it a powerful tool. This site has a good overview and examples of commands. I am sure Mac OS X’s automator does something similar but I’ve never used it.

Archive for the future

When an asset is created it usually goes through many iterations (or revisions) until the end result. Naming those revisions sensibly is also very important. You can use numbers, dates, or the alphabet to indicate sequence, such as final_boss_lvl_01_rev.A.obj; whatever works for you, really. Remember, however, to always, always, indicate clearly what is the final product that was used in the game. Have the word FINAL attached, move it into an IN-GAME directory, but make sure the distinction is clear. You will need to use those assets again and if you can’t tell which file holds the rough sketch from the end result you’re looking for trouble! :)

Conclusion

Everything in this post boils down to this:

  1. Take some time to define a naming system.
  2. Set guidelines for naming and handling assets and their revisions.
  3. Enforce the conventions by keeping the asset creators informed.
  4. Use scripting and other tools to check that everything is correct.

It is a small investment that will pay off and save you big headaches in the long-term.

Well, this ends the second part of the Managing Assets series. I hope you enjoyed it, as always comments are welcome!

This entry was posted in Maya's Dress Up. Bookmark the permalink.