Namespaces

As projects become larger and the number of scriptsA piece of code that allows you to create your own Components, trigger game events, modify Component properties over time and respond to user input in any way you like. More info
See in Glossary increases, the likelihood of having clashes between script class names grows ever greater. This is especially true when several programmers are working on different aspects of the game separately and will eventually combine their efforts in one project. For example, one programmer may be writing the code to control the main player character while another writes the equivalent code for the enemy. Both programmers may choose to call their main script class Controller, but this will cause a clash when their projects are combined.

To some extent, this problem can be avoided by adopting a naming convention or by renaming classes whenever a clash is discovered (eg, the classes above could be given names like PlayerController and EnemyController). However, this is troublesome when there are several classes with clashing names or when variables are declared using those names - each mention of the old class name must be replaced for the code to compile.

The C# language offers a feature called namespaces that solves this problem in a robust way. A namespace is simply a collection of classes that are referred to using a chosen prefix on the class name. See Microsoft’s documentation on namespaces for more information.

In the example below, the classes Controller1 and Controller2 are members of a namespace called Enemy:

namespace Enemy {
    public class Controller1 : MonoBehaviour {
        ...
    }
    
    public class Controller2 : MonoBehaviour {
        ...
    }
}

In code, these classes are referred to as Enemy.Controller1 and Enemy.Controller2, respectively. This is better than renaming the classes insofar as the namespace declaration can be bracketed around existing class declarations (ie, it is not necessary to change the names of all the classes individually). Furthermore, you can use multiple bracketed namespace sections around classes wherever they occur, even if those classes are in different source files.

You can avoid having to type the namespace prefix repeatedly by adding a using directive at the top of the file.

 using Enemy;

This line indicates that where the class names Controller1 and Controller2 are found, they should be taken to mean Enemy.Controller1 and Enemy.Controller2, respectively. If the script also needs to refer to classes with the same name from a different namespace (one called Player, say), then the prefix can still be used. If two namespaces that contain clashing class names are imported with using directives at the same time, the compiler will report an error.

Note: Unity has a specific limitation relating to namespaces and MonoBehaviour or ScriptableObject classes. If your file contains a definition for a MonoBehaviour or ScriptableObject class, you cannot use multiple namespaces within that file.

Unity gives the following warning in the console: Class MyClass can not exist in multiple namespaces in the same file, even if one is excluded with preprocessor directives. Please move these to separate files if this is the case.

This means if you have a file which defines a MonoBehaviour in one namespace, and other classes in a different namespace within the same file, Unity will not recognize the MonoBehaviour class and you will not be able to use it on GameObjectsThe fundamental object in Unity scenes, which can represent characters, props, scenery, cameras, waypoints, and more. A GameObject’s functionality is defined by the Components attached to it. More info
See in Glossary. This limitation was introduced in Unity 2020.1 to improve import and compilation speed, and therefore some older asset storeA growing library of free and commercial assets created by Unity and members of the community. Offers a wide variety of assets, from textures, models and animations to whole project examples, tutorials and Editor extensions. More info
See in Glossary packages written before this limitation was introduced may function incorrectly as a result. To fix problems relating to this issue, separate out the code for the classes in each namespace to separate files.