Or don’t, I’m not a cop!

Ok, this is more a personal habit but a sensible one - hear me out. The most commonly referenced thing in unity is the idea of a Script, Unity even uses it in its context menus when creating new C# Scripts. This idea is a remnant from the days when programming in Unity was made to look approachable by non-technical game developers and frustratingly stuck around.

However it makes more sense to look at a Script as a traditional Class that extends MonoBehaviour. It might not seem like much but this distinction can help structure your games in Unity. Take a look at the hierarchy below, this is from Flocks Sake.

I use two distinct terms to organise my code, Behaviours and Classes, a folder called Scripts is nowhere to be found.

  • Behaviours - Classes that extend the Monobehaviour base class and execute the Monobehaviour methods
  • Classes - Standalone classes that might extend other classes but do not act as Monobehaviour instances in the game

This keeps all of your Monobehaviours away from Editor code, keeps game data classes away from your game controllers. So don’t make that Scripts folder in your next Unity project and do it properly. It’s always a great idea to have project hierarchy style just like you have a programming style.

Oh and on a final note be sure you are using the reserved folder names correctly, putting all your models in the Resources folder might seem like a good idea but could impact negatively on your project.

Links in this post: