Category Archives: opinion-piece

Using attributes and modifying the Inspector

As you create your games, there will be times when you will want to control some parameters at run-time to perform tests. For example: you may want to be able to modify a variable inside the Inspector while the game is running by typing its value or by using a slider to make this easier. In both cases, you will need to modify the Inspector and the way data is presented within.

Thankfully, Unity makes it possible for you to perform these changes from your own C# script. The first thing we could do, is to make our variable public, as all public variables are available and modifiable in the Inspector.

We could also, in addition, define a range, so that we know that people testing the game within Unity can only modify the values of this variable within a specific range, as illustrated in the following code.


public float myVariable;

In the previous code, we use the keyword Range followed by values that indicate the range for the variable myVariable.

Next, we could make it possible to display and change the value of private variables. By default, private variables are not displayed in the Inspector, unless they are proceeded by using the attribute SerializedField as illustrated in the next code.


private int myPrivateVariable;


This being said, Unity also makes it possible to use attributes to modify the behaviours of variables, classes, or methods, when the scene is not played. For example, the following attributes can be used at run-time:

  • HideInInspector: can be used to hide some variables in the Inspector; for example, a variable might be public but you may not want to make it possible to readjust its value in the Inspector.
public class TestSerialized : MonoBehaviour



    public int myPrivateVariable;//this variable will be hidden

     public Vector3 test;


  • Serializable: this attribute gives the opportunity to serialize a class, so that member variables content can be displayed in the Inspector.

public class TestSerialized : MonoBehaviour


// All public member variables will be visible in the Inspector

     public int myPrivateVariable;

     public Vector3 test;


ExecuteInEditMode: this attribute makes it possible to execute a script even in edit mode. Please use this attribute carefully as any of the changes made will be permanent in this case. When things are changed at run-time, your scene will be back to normal when your stop playing it; however, when you perform actions from your code that is executed in edit mode (i.e., with the attribute ExecuteInEditMode) you may need to be careful as the changes made from your script will be permanent.

Creating maintainable and reusable code

When you are coding your game, the size and structure of your code can rapidly become overwhelming over time, unless you have, from the beginning, set a defined strategy that you will follow to ensure that your code will grow in a way that is manageable. To achieve this goal, there are several ways that you can follow including a component-based structure.

Continue reading

Collision Detection in Unity Explained (i.e., Colliders, Triggers and Ray-casting)

In your games, you will often need to detect collisions between objects. This can be related to NPCs or objects that you will collect or interact with. For this purpose, you can use (and monitor) colliders. However, the way you manage collisions, and the methods to be called in this case, will highly depend on the type of colliders used (for example, colliders or triggers) as well as the object from which you want to detect the collision (for example, simple objects or character controllers).

This being said, you may want to be able to detect the presence of objects located far away from the player or the NPC. In this particular case, ray-casting may make more sense than collision or trigger detection.

So this tutorial will explain in great details how you can detect objects using a wide range of techniques such as colliders, triggers and ray-casting.

  Continue reading

5 Common Coding Errors in C# and Unity and how to Solve them

As you will start your journey through C# coding, you may sometimes find it difficult to interpret the errors produced by Unity in the console. However, after some practice, you will manage to recognize them, to understand (and also avoid) them, and to fix them accordingly. The next list identifies the errors that my students often come across when they start coding in C#.

When an error occurs, Unity usually provides you with enough information to check the location of this error in your code, so that you can fix it. While many are relatively obvious to spot, some others are trickier to find. In the following paragraphs, I have listed some of the most common errors that you may come across as you start with C#. The trick is to recognize the error message so that you can understand what Unity is trying to tell you.

Again, this is part of the learning process, and you WILL make these mistakes, but as you recognize these errors, you will learn to understand them (and avoid them too :-)).

Again, Unity is trying to help you by communicating, to the best that it can, where the issue is with your code; so by understanding the error messages, we can get to fix these bugs easily. To make it easier to fix errors, Unity usually provides the following information when an error occurs:

  • The name of the script where the error was found.
  • The location of the error (i.e., row and column).
  • A description of the error.

So, if Unity was to generate the following error message…

“Assets/Scripts/MyFirstScript.cs (23,34) BCE0085: Unknown identifier: ‘localVariable’”

…it is telling us that an error has occurred in the script called MyFirstScript, at the line 23, and around the 34th character (or the 34th column) on this line. In this particular message, it is telling us that it can’t recognize the variable localVariable.

So, you may come across the following errors; this list is also available in the resource pack as a pdf file, so that you can print it and keep it close by:

  1. “;” expected: This error could mean that you have forgotten to add a semi-colon at the end of a statement. To fix this error, just go to the line mentioned in the error message and ensure that you add a semi-colon at the end of the statement.
  2. Unknown identifier: This error could mean that Unity does not know the variable that you are mentioning. It can be due to at least three reasons: (1) the variable has not been declared yet, (2) the variable has been declared but outside the scope of the method (e.g., declared locally in a different function), or (3) the name of the variable that you are using is incorrect (i.e., spelling or case). Remember, the names of all variables and functions are case-sensitive; so by just using an incorrect case, Unity will assume that you refer to another variable.
  3. The best method overload for function … is not compatible: This error is probably due to the fact that you are trying to call a function and to pass a list of parameters (which means the number and the types of parameters) that is not compatible with what the function is expecting. For example, the method mySecondMethod, described in the next code snippet, is expecting a String value for its parameter; so, if you pass an integer value instead, an error will be generated.
void mySecondFunction(string name)


print (“Hello, your name is” +name);


mySecondFunction(“John”);//this is correct

mySecondFunction(10);//this will trigger an error

  1. Expecting } found …: This error is due to the fact that you may have forgotten to either close or open curly brackets for conditional statements or functions, for example. To avoid this issue, there is a trick (or best practice) that you can use: you can ensure that you indent your code so that corresponding opening and closing brackets are at the same level. In the next example, you can see that the brackets corresponding to the start and the end of the method testBrackets are indented at the same level, and so are the brackets for each of the conditional statements within this function. By indenting your code, using several spaces or tabulation, you can make sure that your code is clear and that missing curly brackets are easily spotted.
Void testBrackets()


if (myVar == 2)


print ("Hello World”);

myVar = 4;






  1. Sometimes, although the syntax of your code is correct and does not yield any error in the Console window, it looks like nothing is happening; in other words, it looks like the code, and especially the methods that you have created do not work: This is bound to happen as you create your first scripts. It can be quite frustrating (and I have been there :-)) because, in this case, Unity will not let you know where the error is. However, there is a succession of checks that you can perform to ensure that this does not happen; so you could check the following:

    • The script that you have written has been saved.
    • The script contains no errors.
    • The script is attached to an object.
    • If the script is indeed attached to an object and you are using a built-in method that depends on the type of object it is attached to, make sure that the script is linked to the correct object. For example, if your script is using the built-in method OnControllerColliderHit, which is used to detect collision between the FPSController and other objects, but you don’t drag and drop the script on the FPSController object, the method OnControllerColliderHit will not be called if you collide with an object.
    • If the script is indeed attached to the right object and is using a built-in method such as Start, or Update, make sure that these functions are spelt properly (i.e., exact spelling and case). For example, for the method Update, the system will call the method Update every frame, and no other function. So if you write a method spelt update, the system will look for the Update function instead, and since it has not been defined (or overwritten), nothing will happen, unless you specifically call this function from your code. The same would happen for the method Start. In both cases, the system will assume that you have created two new functions update and start.

    Click here if you want to know more about learning to code in C# in less than 60 minutes.

Creating, activating or destroying objects

Instantiating and Casting

Using C# through Unity, you will at some point, need to create (or instantiate) new GameObjects; this can be done in several ways; the first way could be to call the constructor of the class GameObject as in the next code.

GameObject g = new GameObject ();

Another way, is to use the built-in function called Instantiate. So, for example, let’s say that we want to instantiate bullets, that we have created as prefabs; we could use the following code:

public GameObject bullet;

void Start ()


GameObject g3 = (GameObject)(Instantiate (bullet, transform.position, Quaternion.identity));

In the previous code:

  • We instantiate a new object and save it in the variable g3.
  • We use the method called Instantiate to create a new Object; this method takes three parameters: an object, a position and a rotation.

Now, the important thing to notice here is that the method Instantiate returns a variable of type Object and NOT GameObject; however, when we create the variable g3, we need to make sure that, because the type of g3 is GameObject, that what is returned by the method Instantiate is also of type GameObject; this is the reason why we use the code (GameOBject) just before the keyword Instantiate: this is called Casting; by casting, we have converted the type returned by the method Instantiate from Object to GameObject.

You will obviously use Csting in other occasions; however, when using the Instantiate method, we will need to use casting.

Note that casting can be done using the keyword as, as described in the following code:

GameObject g3 = Instantiate (bullet, transform.position, Quaternion.identity) as GameObject;

In the previous code we use the key words as GameObject to specify that the Object returned by the method Instantiate will be casted as a gameObject.


As we have seen previously, it is possible to instantiate objects using the Instantiate function; and it is also possible to destroy or to deactivate an object accordingly.

To destroy a specific object, you can use the Destroy function and destroy an object either instantaneously or after a specified delay, as illustrated in the next code snippet.

void Start ()


Destroy (gameObject, 5);

Destroy (GameObject.Find ("Cube");


In the previous code:

  • We use the function Start.
  • We destroy the object linked to this script with a delay of 5 seconds; this could be used for example, for bullets or any objects that would typically disappear a few seconds after its creation. Note that we use gameObject with a lowercase g as we refer to the object linked to this particular script.
  • In the second line, we look for an object called Cube and we destroy it instantaneously.

There are also times where it is good not to destroy an object, but instead, to deactivate it; for example, you may want an object to appear in the scene only after the player has collected some items; this can be useful for treasure hunts, or adventure games based on exploration; in this case you would typically do the following:

  • Add the object to the scene manually (possibly). While you could do this through code, doing this manually has the advantage, especially for bulky object, to know exactly where and how they will fit in the scene. Of course, if you had to do this for several objects, a script-based Instantiation may be more efficient.
  • Make sure the object is activated in the Scene view (by checking the Inspector)
  • Create a reference to the object in your script before it is deactivated.
  • Deactivate the object from your script at the start of the scene.
  • Reactivate the object from your script when an event has occurred (e.g., player collected all relevant items).
public class DestroyAndDeactivate : MonoBehaviour {

GameObject g;

bool collectedItems;

void Start ()


g = GameObject.Find ("Cube2");

g.SetActive (false);


void Update ()


if (collectedItems && ! g.activeInHierarchy) g.SetActive (true);


In the previous code:

  • We declare the variable g that will be used as a reference to the object we need to hide/deactivate.
  • We also declare a Boolean variable that will be used to know whether the necessary items to activate the object have been collected.
  • Then, in the function Start, we find the object called Cube2 and link it to the variable g.
  • Through the variable g, we deactivate the object Cube2.
  • In the Update function, we then check that the object Cube2 is not active; we also check that the items have been collected; if this is the case, then we activate the object Cube2.

So this approach is very useful when you want to reveal or unveil some items; and you can also, as we have seen earlier, destroy objects either instantaneously or after a delay.


This being said, there are cases when you may want to make sure objects (and any related component or children) are not destroyed when transitioning between scenes. You see, when you load a new scene, by default all the objects in the previous scene are destroyed before the objects from the new scene are instantiated. So, there are cases


In this case, you could use the following snippet and attach the corresponding script to the object that you’d like to keep between scenes.

void Awake()




In the previous code:

  • We implement the method called Awake that is usually called when the script is loaded; this method is called only once in the lifetime of the game.
  • We then use the method DontDestroyOnLoad to ask Unity to keep this particular object and its children.
  • The method Start in not used in this case, as it is often called every time a scene is starting; however, in our case, we just want to call it once in the game, and Awake is therefore more appropriate.


You could this method when you want to create a game manager that should be present in (accessible from) any scene, for example.