Click here to Skip to main content
14,972,640 members
Articles / Game Development / XBox
Technical Blog
Posted 2 Feb 2016


2 bookmarked

Be Careful of Those SPECIAL Names in Unity

Rate me:
Please Sign up or sign in to vote.
5.00/5 (5 votes)
4 Feb 2016CPOL4 min read
Be careful of those SPECIAL names in Unity


Every once in a while, you can be reminded of a simple fact, all tools have their own ways and means, each has its little tricks and those little things that if unknown, can trip you up in unexpected places, so too is it with Unity.

Unity is a very powerful engine and tool, but to master it you must learn how it works, what doesn’t work and what to avoid.

As ever reminded by that old quote:

“with Great power comes great responsibility”
(and a low shelf you will no doubt keep bumping your head in to)

One of those simple facts surrounds what you name things in your scripts and code (your class names, NOT properties or enums), as I’ll explain here.

What’s In A Name?

Now it should be clear from just using Unity for 5 minutes that there are some names that you simply can’t call things in Unity, the most obvious being:

  • MonoBehaviour – because almost everything is a MonoBehaviour
  • Base types such as Vector2, Point, Canvas – because Unity already has those things and while you can use them, you won’t get the base functionality
  • Reserved names – Basically anything within the Unity namespaces. Just try creating your own “UnityEngine” class and see what happens!

There are more and Unity usually forewarns you if you are doing something it considers silly or inappropriate.

However, the same cannot be said for the platforms you build upon… Does Unity also check those?

The answer sadly is NO.

You Can Have Any Color You Want, So Long As It’s Red

This all came about as I was helping out one studio (as it’s what I usually do) in testing their project as well as supporting them with building their Windows 10 UWP version (target several platforms from a single build, yes please).

There was an error that only popped up in the compiled version of their project which showed itself in one of two ways:

  • A very helpful issue loading the project with the following error “Object reference not set to an instance of an object” (not very helpful)
  • The project opens with no issues, but when it's built, you are suddenly assaulted with numerous errors:
    – “Class has no property called x” or
    – “Cannot implicitly convert type X to Y

In this case I was testing, the developer had created a class called “SplashScreen” (which seems fairly innocuous), however when you dig under the hood, you find that that BOTH Unity and the Microsoft platforms already have a type called SplashScreen. Unity was able to work around its own type in the internal build making sure the version of the SplashScreen class in the project was different to Unity’s version of SplashScreen (most likely by using different namespaces). When it came to the platform build however, the classes used in your project will OVERRIDE those used by the platform.

If You Test It They Will Come

So let’s test this so you can be better prepared if it happens. As far as I’m aware, this only affects all of the modern Windows platforms because they have full access to the Unity project directly from the platform (a very useful feature with .NET projects), although this could also affect any plug-in you write that is used by a platform (unless you follow the steps in the next section).

To replicate the issue, simply try the following:

  1. Create a new blank project
  2. Create a new script called SplashScreen
  3. Build the project for any of the “Windows Store” platforms
  4. Open the built project in Visual Studio or MonoDevelop

Look no errors, see. Now build it.

And you’ll see a wrath of errors related to the SplashScreen class, as the project now thinks the classes in your project should be used over the type that is reserved for the platform.

So What Names Should You NOT Use

Now, I’ve done some testing but it’s not very extensive, so I’ll list what I have tested and found issues.

If you find more, comment below and I’ll add them to the list.

  • SplashScreen
  • App
  • Application
  • Window
  • UnityPlayer (This one surprised me as Unity itself doesn’t warn against its use)

If you are aware of any more, feel free to comment below.

How To Avoid the Problem Completely

It’s important to note this affects any class or type defined in your base project. A simple way to avoid these headaches is to use your own namespaces in your classes, this means your code cannot be confused with any other code or types of the same name (except your own Open-mouthed smile).
To learn more about using namespaces, simply check out these references on the Unity Learn site:

Stay safe and code well!


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Simon Jackson
Architect ZenithMoon Studios
United Kingdom United Kingdom
Long time game developer / IT maniac.
By day working as a lowly Technical Architect for a healthcare software firm, by night Masquerading as the Master Chief of ZenithMoon Studios.

At heart I'm a community developer breaking down lots of fun and curious technologies and bringing them to the masses.

I'm also a contributor to several open source projects, most notably the AdRotator advertising rotator project for Windows and Windows Phone.

After a hefty break with Windows Phone and Windows 8 I'm heading back to my XNA roots to show how beginners and current XNA devs can take their skills forward with XNA's bleak future.

ID&Xbox MVP & Best selling author
[Mastering Unity 2D Game Development] (
[Unity 3D UI Essentials] (

Comments and Discussions

-- There are no messages in this forum --