I am "self-taught" in C#. I worked for a long time as a technology consultant, designing and building software and business solutions for customers. None of those solutions involved C#, but I often found myself firing up Visual Studio to build myself a little tool or application to help me do my job. I did a bit of Visual Basic as a very young lad, and the Visual Studio environment was familiar. C# also felt comfortable and accessible, coming from high-level languages like VB and Java, and combined with the VS IDE, it just seemed to have the right stuff to get me the quick and dirty results that I needed.

To this day, I've never had formal training in C#, and so I have developed a lot of bad habits and ways of working that don't sit well with modern development methodologies. There's still a part of me that doesn't really care, and the end result is what really counts, but there are still some aspects of C# that I've learned in the process of learning Unity, that I think help make things easier in the longer term. I wanted to set out some of those key elements in some blog posts, in the hopes that it helps others that are new to C# and Unity.

This week, I wanted to start with...

Namespaces

Namespaces in C# let you group and categorise code and classes. Something I learned very early on is that this is really important in Unity development, especially if you're using assets from the asset store. Imagine we're building a "spawner", to spawn AI creatures into our game world. Creating a script and class called "Spawner" makes a whole lot of sense. However, look to a host of assets on the Asset Store, and you'll find many that use this class name. How, then, can you ensure you clearly reference your "Spawner" and not someone else's when you're using that class within your game? That's where namespaces come in. Namespaces allow you to define your own safe space in which to declare and build classes and code, without fear of conflict with other sources. So I might have a top-level namespace called "DaftAppleGames" - that ensures uniqueness across all subsequent namespace categories, unless some other bugger takes the name. Fingers crossed that ain't gonna happen. I can then create a "DaftAppleGames.Spawner" namespace within which my spawner classes will live. Then all I need to do is add a "using" statement to any script file, and I can make use of my spawn classes:

using DaftAppleGames.Spawners;

Now I took Unity's guidance to heart, and structured my script files within a directory hierarchy contained within "Assets\Scripts":

• DaftAppleGames
  • Characters
  • Spawners
  • Managers
  • Quests
  • Controllers

This then gives me the hierarchy for my namespaces, which I define simply within each of the script files that I create in Unity:

namespace DaftAppleGames.Spawners
{    
    /// <summary>     
    /// Unity class to automatically spawn a number of Aniaml AI Game Objects in the scene     
    /// </summary>     
    public class AnimalSpawner : MonoBehaviour     
    {
        ...

Namespaces help avoid conflict with other sources of code and classes in your Unity project. Not only that, I found they really helped me to focus my code and classes, and build independent, functionally focussed and extensible classes, grouped into sensible and re-usable namespaces.

I just wish I'd discovered them sooner, as maybe those old C# tools I build back in the day would have been that much better!