If you are working on a project or with a team that has a pre-existing style guide, it should be respected.

Style guides should be living documents. You should propose style guide changes to an existing style guide if you feel the change benefits all usages.

"Arguments over style are pointless. There should be a style guide, and you should follow it." Rebecca Murphey

Moving from one project to another should not cause a re-learning of style and structure. Conforming to a style guide removes unneeded guesswork and ambiguities.

It also allows for more productive creation and maintenance as one does not need to think about style. Simply follow the instructions. This style guide is written with best practices in mind, meaning that by following this style guide you will also minimize hard to track issues.

If you see someone working either against a style guide or no style guide, try to correct them.

When working within a team, it is far easier to help and to ask for help when people are consistent. Nobody likes to help untangle someone's folder spaghetti or deal with assets that have names they can't understand.

If you are helping someone whose work conforms to a different but consistent and sane style guide, you should be able to adapt to it. If they do not conform to any style guide, please direct them here.

In any Identifier of any kind, never use the following unless absolutely forced to:

• White space of any kind
• Backward slashes \
• Symbols i.e. #!@$%
• Any Unicode character

Any Identifier should strive to only have the following characters when possible (the RegEx [a-z0-9_])

• abcdefghijklmnopqrstuvwxyz
• 1234567890
• _

The reasoning for this is this will ensure the greatest compatibility of all data across all platforms across all tools, and help prevent downtime due to potentially bad character handling for identifiers in code you don't control.

Capital characters are only allowed in specific cases such as the naming of LODs.