Naming strategy:

problem: often we want to find things easily by searching
solution: use guessable and consistent naming conventions

if you always name things the same sort of way, you'll
have a better idea of what to search for



problem: many computer systems (and programming) differentiate
between upper and lower case. Often there reasons that artists
won't understand.
solution: all art and content is lowercase only


problem: sometimes we have names that more than one word
solution: use underscores

crazy_drawing
giant_monster
apple_computer


problem: sometimes we want to seperate parts of the name
and know that that separation is different from
seperating words with spaces
solution: use double underscores

joe_crawford__giant_monster__udk

author__name_of_thing__type_of_thing

note that you don't always need authors name, it's usually enough to say

name_of_thing__type_of_thing  is usually enough

Sometimes you need more sections, if so, that's fine. Repeat the same pattern.




problem: we want to know what something is for quickly,
just by looking at the name, the file extension isn't enough.
solution: using a section in a name solves this problem

Put the type, what it's used for, in the name, at the end, like a file extention


this works really well for folder that are software specific projects, every folder doesn't always have to be named like this.

A maya project:
giant_monster__maya

With two underscore and maya at the end, even if this folder is moved, or copied elsewhere, it's obvious that it is a maya project.


A udk project:
joecc__giant_monster__udk

This has udk at the end to signify that it is a udk project, meant to go in the "Content" folder.  Also, since there are other folders in the content folder, and your projects should be unique and sort alphebetically together, put a common prefix in front (your name or initials work well, that's why I used joecc in the above example)


for individual assets, we already know they are part of a udk project because they are inside, the folder, or inside the package (which is itself in a folder)

thus, descriptive name and type is usually enough
we can also include a section on how it will be used

descriptive_name__usage__type_of_thing.extension

udk will drop the extension completely, so the .tga or .fbx gets removed automatically in the examples below

asset_name__diff__tex.tga
asset_name__emis__tex.tga
asset_name__spec__tex.tga
asset_name__norm__tex.tga
asset_name__mesh.fbx


asset_name__skelmesh.fbx
asset_name__animset
asset_name__running__anim.fbx
asset_name__jumping__anim.fbx
asset_name__shooting__anim.fbx
etc...

It should be noted that the animset shown above is not a file in a folder, it's an asset in udk, and is inside a packaqe, however, we still name it the same way, though it doesn't an extension since UDK doesn't use file extension inside packages.




for_udk  or  src_udk  folder

a place to put the files you will export from your working software and import into udk