This document contains rules for setting up a projects structure and a naming convention for scripts and assets in Unity. This is a living document, so any kind of feedback is welcome!
1.1 Style
All structure, assets, and code in any project should look like a single person created it, no matter how many people contributed.
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 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.
Style guides should be living documents however and you should propose style guide changes to an existing style guide as well as this guide if you feel the change benefits all usages.
If you see someone working either against a style guide or no style guide, try to correct them.
When working within a team or discussing within a community, it is far easier to help and to ask for help when people are consistent. Nobody likes to help untangle someone's spaghetti code or deal with assets with names they can't understand.
If you are helping someone who's 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.
Unity uses the term Prefab for a system that allows you to create, configure, and store a GameObject complete with all its components, property values, and child GameObjects as a reusable Asset.
Levels refer to what some people call maps or what Unity calls Scenes. A level contains a collection of objects.
Variables that are Serializable are shown in the Inspector window in Unity. For more information see Unity's documentation on Serializable.
There are a few different ways you can name things. Here are some common casing types:
Capitalize every word and remove all spaces, e.g.
DesertEagle,StyleGuide,ASeriesOfWords.The first letter is always lowercase but every following word starts with uppercase, e.g.
desertEagle,styleGuide,aSeriesOfWords.All letters are lowercase, e.g.
deserteagle,Words can arbitrarily start upper or lowercase but words are separated by an underscore, e.g.
desert_Eagle,Style_Guide,a_Series_of_Words.
The directory structure style of a project should be considered law. Asset naming conventions and content directory structure go hand in hand, and a violation of either causes unneeded chaos.
In this style, we will be using a structure that groups asset types with folders. See an example below.
Assets
ProjectName
Characters
Anakin
FX
Vehicles
Abilities
IonCannon
(Particle Systems, Textures)
Weapons
Gameplay
Characters
Equipment
Input
Vehicles
Abilities
Air
TieFighter
(Models, Textures, Materials, Prefabs)
_Levels
Frontend
Act1
Level1
Lighting
HDRI
Lut
Textures
MaterialLibrary
Debug
Shaders
Objects
Architecture (Single use big objects)
DeathStar
Props (Repeating objects to fill a level)
ObjectSets
DeathStar
Scripts
AI
Gameplay
Input
Tools
Sound
Characters
Vehicles
TieFighter
Abilities
Afterburners
Weapons
UI
Art
Buttons
Resources
Fonts
ExpansionPack (DLC)
Plugins
ThirdPartySDK
The reasons for this structure are listed in the following sub-sections.
2.1 Folder Names
2.4 Levels
2.5 Define Ownership
2.7 Large Sets
2.8 Material Library
2.9 Scene Structure
These are common rules for naming any folder in the content structure.
Always Use PascalCase
PascalCase refers to starting a name with a capital letter and then instead of using spaces, every following word also starts with a capital letter. For example, DesertEagle, RocketPistol, and ASeriesOfWords.
Re-enforcing 2.1.1, never use spaces. Spaces can cause various engineering tools and batch processes to fail. Ideally your project's root also contains no spaces and is located somewhere such as D:\Project instead of C:\Users\My Name\My Documents\Unity Projects.
If one of your game characters is named 'Zoë', its folder name should be Zoe. Unicode characters can be worse than Spaces for engineering tools and some parts applications don't support Unicode characters in paths either.
Related to this, if your project has and your computer's user name has a Unicode character (i.e. your name is Zoë), any project located in your My Documents folder will suffer from this issue. Often simply moving your project to something like D:\Project will fix these mysterious issues.
Using other characters outside a-z, A-Z, and 0-9 such as @, -, _, ,, *, and # can also lead to unexpected and hard to track issues on other platforms, source control, and weaker engineering tools.
There simply shouldn't be any empty folders. They clutter the content browser.
If you find that the content browser has an empty folder you can't delete, you should perform the following:
- Be sure you're using source control.
- Navigate to the folder on-disk and delete the assets inside.
- Close the editor.
- Make sure your source control state is in sync (i.e. if using Perforce, run a Reconcile Offline Work on your content directory)
- Open the editor. Confirm everything still works as expected. If it doesn't, revert, figure out what went wrong, and try again.
- Ensure the folder is now gone.
- Submit changes to source control.
All of a project's assets should exist in a folder named after the project. For example, if your project is named 'Generic Shooter', all of it's content should exist in Assets/GenericShooter.
There are multiple reasons for this approach.
Often in code style guides it is written that you should not pollute the global namespace and this follows the same principle. When assets are allowed to exist outside of a project folder it often becomes much harder to enforce a strict structure layout as assets not in a folder encourages the bad behavior of not having to organize assets.
Every asset should have a purpose, otherwise it does not belong in a project. If an asset is an experimental test and shouldn't be used by the project it should be put in a Developer branch.
When working on multiple projects it is common for a team to copy assets from one project to another if they have made something useful for both.
By placing all project specific assets in a top level folder you reduce the chance of migration conflict when importing those assets into a new project.
An extension to 2.2.2, if a team member decides to add sample content, template files, or assets they bought from a 3rd party, it is guaranteed that these new assets will not interfere with the project in any way unless your project's top level folder is not uniquely named.
You can not trust 3rd party content to fully conform to the top level folder rule. There exist many assets that have the majority of their content in a top level folder but also have possibly modified Unity sample content as well as level files polluting the global Assets folder.
When adhering to 2.2, the worst 3rd party conflict you can have is if two 3rd party assets both have the same sample content. If all your assets are in a project specific folder, including sample content you may have moved into your folder, your project will never break.
If your project plans to release DLC or has multiple sub-projects associated with it that may either be migrated out or simply not cooked in a build, assets relating to these projects should have their own separate top level content folder. This make cooking DLC separate from main project content far easier. Sub-projects can also be migrated in and out with minimal effort. If you need to change a material of an asset or add some very specific asset override behavior in a patch, you can easily put these changes in a patch folder and work safely without the chance of breaking the core project.
During a project's development, it is very common for team members to have a sort of 'sandbox' where they can experiment freely without risking the core project. Because this work may be ongoing, these team members may wish to put their assets on a project's source control server.
It is very easy for a team member to accidentally use assets that are not ready for use which will cause issues once those assets are removed. For example, an artist may be iterating on a modular set of static meshes and still working on getting their sizing and grid snapping correct. If a world builder sees these assets in the main project folder, they might use them all over a level not knowing they could be subject to incredible change and/or removal. This causes massive amounts of re-working by everyone on the team to resolve.
If these modular assets were placed in a development branch, the world builder should never have had a reason to use them and the whole issue would never have happened.
Once the assets are ready for use, an artist simply has to move the assets into the project specific folder on the main branch. This is essentially 'promoting' the assets from experimental to production.
2.4 All Scene Files Belong In A Folder Called Levels
Level files are incredibly special and it is common for every project to have its own map naming system, especially if they work with sub-levels or streaming levels. No matter what system of map organization is in place for the specific project, all levels should belong in Assets/ProjectNameName/Levels.
Being able to tell someone to open a specific map without having to explain where it is is a great time saver and general 'quality of life' improvement. It is common for levels to be within sub-folders of Levels, such as Levels/Campaign1/ or Levels/Arenas, but the most important thing here is that they all exist within Assets/ProjectNameName/Levels.
This also simplifies the job of cooking for engineers. Wrangling levels for a build process can be extremely frustrating if they have to dig through arbitrary folders for them. If a team's levels are all in one place, it is much harder to accidentally not cook a map in a build. It also simplifies lighting build scripts as well QA processes.
In teams of more than one, define ownership of zone/assets/features. Some assets like scenes or prefabs do not handle simultaneous changes by multiple people very well, creating conflict. Having a single person who can change (or give the right to change) a given assets helps to avoid that problem.
All assets are assets.
This can be seen as a pseudo-exception to 2.6.
There are certain asset types that have a huge volume of related files where each asset has a unique purpose. The two most common are Animation and Audio assets. If you find yourself having 15+ of these assets that belong together, they should be together.
For example, animations that are shared across multiple characters should lay in Characters/Common/Animations and may have sub-folders such as Locomotion or Cinematic.
This does not apply to assets like textures and materials. It is common for a
Rocksfolder to have a large amount of textures if there are a large amount of rocks, however these textures are generally only related to a few specific rocks and should be named appropriately. Even if these textures are part of a Material Library.
If your project makes use of master materials, layered materials, or any form of reusable materials or textures that do not belong to any subset of assets, these assets should be located in Assets/ProjectName/MaterialLibrary.
This way all 'global' materials have a place to live and are easily located.
This also makes it incredibly easy to enforce a 'use material instances only' policy within a project. If all artists and assets should be using material instances, then the only regular material assets that should exist are within this folder. You can easily verify this by searching for base materials in any folder that isn't the
MaterialLibrary.
The MaterialLibrary doesn't have to consist of purely materials. Shared utility textures, material functions, and other things of this nature should be stored here as well within folders that designate their intended purpose. For example, generic noise textures should be located in MaterialLibrary/Utility.
Any testing or debug materials should be within MaterialLibrary/Debug. This allows debug materials to be easily stripped from a project before shipping and makes it incredibly apparent if production assets are using them if reference errors are shown.
Next to the project’s hierarchy, there’s also scene hierarchy. As before, we’ll present you a template. You can adjust it to your needs. Use named empty game objects as scene folders.
Debug
Management
UI
Cameras
Lights
World
Terrain
Props
Gameplay
Actors
Items
_Dynamic
- All empty objects should be located at 0,0,0 with default rotation and scale.
- For empty objects that are only containers for scripts, use “@” as prefix – e.g. @Cheats
- When you’re instantiating an object in runtime, make sure to put it in _Dynamic – do not pollute the root of your hierarchy or you will find it difficult to navigate through it.
This section will focus on C# classes and their internals. When possible, style rules conform to Microsoft's C# standard.
3.2 Compiling
3.3 Variables
3.4 Functions
Source files should contain only one public type, although multiple internal classes are allowed.
Source files should be given the name of the public class in the file.
Organize namespaces with a clearly defined structure.
Class members should be alphabetized, and grouped into sections:
- Constant Fields
- Static Fields
- Fields
- Constructors
- Properties
- Events / Delegates
- LifeCycle Methods (Awake, OnEnable, OnDisable, OnDestroy)
- Public Methods
- Private Methods
- Nested types
Within each of these groups order by access:
- public
- internal
- protected
- private
namespace ProjectName
{
/// <summary>
/// Brief summary of what the class does
/// </summary>
public class Account
{
// Fields
public string BankName;
public const string ShippingType = "DropShip";
/// <summary>
/// Static fields come first and all fields should have a summary.
/// </summary>
private static decimal reserves;
/// <summary>
/// This field gets exposed via the SerializeField property.
/// </summary>
[Tooltip("Private variables set in the Inspector, should have a Tooltip")]
[SerializeField]
private float timeToDie;
// Properties
public string Number {get; set;}
public DateTime DateOpened {get; set;}
public DateTime DateClosed {get; set;}
public decimal Balance {get; set;}
// LifeCycle
public Awake()
{
// ...
}
// Public Methods
public AddObjectToBank()
{
// ...
}
}
}
We also provide a custom template for C# scripts that ensures that all script files created through Unity already follow our coding guidelines.
Use a namespace to ensure your scoping of classes/enum/interface/etc won't conflict with existing ones from other namespaces or the global namespace. The project should at minimum use the projects name for the Namespace to prevent conflicts with any imported Third Party assets.
Simply, any function that has an access modifier of Public should have its summary filled out.
/// <summary>
/// Fire a gun
/// </summary>
public void Fire()
{
// Fire the gun.
}
In addition, to help your fellow developers we also ask you to follow this less common rule and add a proper comment for all your private functions.
If a class has only a small number of variables, Foldout Groups are not required.
If a class has a moderate amount of variables (5-10), all Serializable variables should have a non-default Foldout Group assigned. A common category is Config.
- To create Foldout Groups, define a
[Serializable] public Classinside the main class. However, this can have a performance impact.
[[Serializable](https://docs.unity3d.com/ScriptReference/Serializable.html)]
public struct PlayerStats
{
public int MovementSpeed;
}
This is how Foldout Groups are displayed in the Unity Editor.
Comments should be used to describe intention, algorithmic overview, and/or logical flow. It would be ideal if from reading the comments alone, someone other than the author could understand a function’s intended behavior and general operation.
While there are no minimum comment requirements and certainly some very small routines need no commenting at all, it is hoped that most routines will have comments reflecting the programmer’s intent and approach.
Place the comment on a separate line, not at the end of a line of code.
Begin comment text with an uppercase letter.
End comment text with a period.
Insert one space between the comment delimiter (//) and the comment text, as shown in the following example.
The // (two slashes) style of comment tags should be used in most situations. Where ever possible, place comments above the code instead of beside it. Here is an example:
// Sample comment above a variable.
private int myInt = 5;
The #region directive enables you to collapse and hide sections of code in C# files. We generally consider the usage of regions a code smell as it usually is an indicator for excessively large files.
Do use a single space after a comma between function arguments.
Example: Console.In.Read(myChar, 0, 1);
- Do not use a space after the parenthesis and function arguments.
- Do not use spaces between a function name and parenthesis.
- Do not use spaces inside brackets.
Unlike Java or certain C-styles, braces in C# are generally placed on the next line.
All scripts should compile with zero warnings and zero errors. You should fix script warnings and errors immediately as they can quickly cascade into very scary unexpected behavior. Style warnings are permitted in your team feature branches as long as they are fixed before being merged into master.
Do not submit broken scripts to source control. If you must store them on source control, shelve them instead.
The words variable and property may be used interchangeably.
All non-boolean variable names must be clear, unambiguous, and descriptive nouns.
All variables use PascalCase unless marked as private which use camelCase.
Use PascalCase for abbreviations of 4 characters or more (3 chars are both uppercase).
All variable names must not be redundant with their context as all variable references in the class will always have context.
Consider a Class called PlayerCharacter.
Bad
PlayerScorePlayerKillsMyTargetPlayerMyCharacterNameCharacterSkillsChosenCharacterSkin
All of these variables are named redundantly. It is implied that the variable is representative of the PlayerCharacter it belongs to because it is PlayerCharacter that is defining these variables.
Good
ScoreKillsTargetPlayerNameSkillsSkin
In C#, variables have a concept of access level. Public means any code outside the class can access the variable. Protected means only the class and any child classes can access this variable internally. Private means only this class and no child classes can access this variable. Variables should only be made public if absolutely necessary.
Using the attribute [SerializeField] is preferred over making a variable public.
Local variables should use camelCase.
You can use implicit typing for local variables when the type of the variable is obvious from the right side of the assignment, or when the precise type is not important. This does not have any real world effect and does not impact performance. Especially for more complicated types this makes code easier to read.
var var1 = "This is clearly a string.";
var var2 = 27;
var var3 = Convert.ToInt32(Console.ReadLine());
// Also used in for loops
for (var i = 0; i < bountyHunterFleets.Length; ++i) {};
Do not use var when the type is not apparent from the right side of the assignment. Example
int var4 = ExampleClass.ResultSoFar();
Private variables should use camelCase and referenced using this.
Unless it is known that a variable should only be accessed within the class it is defined and never a child class, do not mark variables as private. Until variables are able to be marked protected, reserve private for when you absolutely know you want to restrict child class usage.
Do not use Hungarian notation or any other type identification in identifiers
// Correct
int counter;
string name;
// Avoid
int iCounter;
string strName;
All Serializable variables should have a description in their [Tooltip] fields that explains how changing this value affects the behavior of the script.
All Serializable variables should make use of slider and value ranges if there is ever a value that a variable should not be set to.
Example: A script that generates fence posts might have an editable variable named PostsCount and a value of -1 would not make any sense. Use the range fields [Range(min, max)] to mark 0 as a minimum.
If an editable variable is used in a Construction Script, it should have a reasonable Slider Range defined so that someone can not accidentally assign it a large value that could crash the editor.
A Value Range only needs to be defined if the bounds of a value are known. While a Slider Range prevents accidental large number inputs, an undefined Value Range allows a user to specify a value outside the Slider Range that may be considered 'dangerous' but still valid.
All booleans should be named in camelCase and prefixed with a verb.
Example: Use isDead and hasItem, not Dead and Item.
All booleans should be named as descriptive adjectives when possible if representing general information.
Try to not use verbs such as isRunning. Verbs tend to lead to complex states.
Do not use booleans to represent complex and/or dependent states. This makes state adding and removing complex and no longer easily readable. Use an enumeration instead.
Example: When defining a weapon, do not use isReloading and isEquipping if a weapon can't be both reloading and equipping. Define an enumeration named WeaponState and use a variable with this type named WeaponState instead. This makes it far easier to add new states to weapons.
Enums use PascalCase and use singular names for enums and their values. Exception: bit field enums should be plural. Enums can be placed outside the class space to provide global access.
Example:
public enum WeaponType
{
Knife,
Gun
}
// Enum can have multiple values
[Flags]
public enum Dockings
{
None = 0,
Top = 1,
}
public WeaponType Weapon
Arrays follow the same naming rules as above, but should be named as a plural noun.
Example: Use Targets, Hats, and EnemyPlayers, not TargetList, HatArray, EnemyPlayerArray.
Interfaces are led with a capital I then followed with PascalCase.
Example: public interface ICanEat { }
This section describes how you should author functions, events, and event dispatchers. Everything that applies to functions also applies to events, unless otherwise noted.
The naming of functions, events, and event dispatchers is critically important. Based on the name alone, certain assumptions can be made about functions. For example:
- Is it a pure function?
- Is it fetching state information?
- Is it a handler?
- What is its purpose?
These questions and more can all be answered when functions are named appropriately.
All functions and events perform some form of action, whether its getting info, calculating data, or causing something to explode. Therefore, all functions should start with verbs. They should be worded in the present tense whenever possible. They should also have some context as to what they are doing.
Good examples:
Fire- Good example if in a Character / Weapon class, as it has context. Bad if in a Barrel / Grass / any ambiguous class.Jump- Good example if in a Character class, otherwise, needs context.ExplodeReceiveMessageSortPlayerArrayGetArmOffsetGetCoordinatesUpdateTransformsEnableBigHeadModeIsEnemy- "Is" is a verb.
Bad examples:
Dead- Is Dead? Will deaden?RockProcessData- Ambiguous, these words mean nothing.PlayerState- Nouns are ambiguous.Color- Verb with no context, or ambiguous noun.
When writing a function that does not change the state of or modify any object and is purely for getting information, state, or computing a yes/no value, it should ask a question. This should also follow the verb rule.
This is extremely important as if a question is not asked, it may be assumed that the function performs an action and is returning whether that action succeeded.
Good examples:
IsDeadIsOnFireIsAliveIsSpeakingIsHavingAnExistentialCrisisIsVisibleHasWeapon- "Has" is a verb.WasCharging- "Was" is past-tense of "be". Use "was" when referring to 'previous frame' or 'previous state'.CanReload- "Can" is a verb.
Bad examples:
Fire- Is on fire? Will fire? Do fire?OnFire- Can be confused with event dispatcher for firing.Dead- Is dead? Will deaden?Visibility- Is visible? Set visibility? A description of flying conditions?
Any function that handles an event or dispatches an event should start with On and continue to follow the verb rule.
Good examples:
OnDeath- Common collocation in gamesOnPickupOnReceiveMessageOnMessageRecievedOnTargetChangedOnClickOnLeave
Bad examples:
OnDataOnTarget
Naming conventions should be treated as law. A project that conforms to a naming convention is able to have its assets managed, searched, parsed, and maintained with incredible ease.
Most things are grouped by folder to make locating them easier.
Assets use lowercase
All assets should have a Base Asset Name. A Base Asset Name represents a logical grouping of related assets. Any asset that is part of this logical group
should follow the the standard of baseassetname_variant.
Baseassetname should be determined by short and easily recognizable name related to the context of this group of assets. For example, if you had a character named Bob, all of Bob's assets would have the baseassetname of bob.
For unique and specific variations of assets, variant is either a short and easily recognizable name that represents logical grouping of assets that are a subset of an asset's base name. For example, if Bob had multiple skins these skins should still use bob as the baseassetname but include a recognizable variant. An 'Evil' skin would be referred to as bob_evil and a 'Retro' skin would be referred to as bob_retro.
For unique but generic variations of assets, variant is a two digit number starting at 01. For example, if you have an environment artist generating nondescript rocks, they would be named rock_01, rock_02, rock_03, etc. Except for rare exceptions, you should never require a three digit variant number. If you have more than 100 assets, you should consider organizing them with different base names or using multiple variant names.
Depending on how your asset variants are made, you can chain together variant names. For example, if you are creating flooring assets for an Arch Viz project you should use the base name flooring with chained variants such as flooring_marble_01, flooring_maple_01, flooring_tile_squares_01.
You can also chain variants if necessary, for instance for animations such as player_walk_left.
https://unity3d.com/learn/tutorials/topics/tips/large-project-organisation https://github.com/Allar/ue4-style-guide http://www.arreverie.com/blogs/unity3d-best-practices-folder-structure-source-control/