Qu’est-ce qu’un script ?

Les scripts écrits par les développeurs sont des composantes. Une composante, pouvant contenir un état et des opérations pour manipuler son état ou l’état d’autres composantes, est une classe qui contient du code qui appellera le moteur Unity.

Toutes ces classes doivent hériter de MonoBehaviour, car cette classe permet d’écrire des callbacks (formes de délégués) pour des évènements dans le moteur. Par exemple, supposons la composante LoadGameComponent qui est attachée au GameObject GameManager dans une scène. Le but de cette composante est de créer une connexion à une base de données contenant la sauvegarde d’un jeu. Si la connexion est impossible, une tentative de lire un fichier local de sauvegarde est faite.

Lorsque le jeu est démarré et que la scène contenant GameManager est active, GameManager est instanciée et, conséquemment, une instance de LoadGameComponent est créée. Quand une composante est instancié, cela déclenche un évènement dans le moteur. Un évènement peut avoir un délégué qui est appelé, au moment que l’évènement est déclenché. En autres mots, le moteur est programmé pour déclencher des évènements pour chaque Component. Le développeur est responsable de fournir se passe lorsque ces évènements sont déclenchés sous forme de scripts.

N.B. Pas tout le code C# écrit par un développeur est nécessairement un script. Un script, dans le modèle Unity, est un MonoBehaviour qui n’est pratique qu’avec l’exécution du moteur Unity. Les scripts ne sont pas du code réutilisable dans tous projets C#. Il reste pertinent d’écrire du code C# « conventionel » dans un projet Unity, tout de même. Plusieurs types importants, tels que Vector3 et Matrix4x4, sont des structures de données polyvalentes qui ne sont pas des scripts (MonoBehaviour).

Awake

Il existe au-delà d’une trentaine d’évènements qui peuvent être déclenchés pour une composante. Par chance, il n’est pas nécessaire d’écrire un délégué pour chacun. Il est possible de réaliser beaucoup avec quelque évènements notables.

Pour commencer, il y a l’évènement nommé Awake. Cet évènement est déclenché la première fois qu’une composante est instanciée dans une scène, pendant l’exécution du jeu.

Pour écrire la fonction qui sera utilisée pour Awake, il faut utiliser la déclaration void Awake(). Le moteur s’attend à un délégué qui retourne void et qui ne prend pas de paramètre. Le développeur n’attache pas cette méthode explicitement à l’évènement du moteur ; le moteur va chercher pour une fonction qui a exactement la déclaration void Awake() et l’utiliser pour son évènement Awake. C’est un peu lourd, mais simple pour le développeur.

using UnityEngine;

public class FooComponent : MonoBehaviour
{
    void Awake()
    {
        //Debug.Log écrit dans la console de l'éditeur
        Debug.Log("Ce FooComponent a été instancié pour la première fois !");    
    }
}

Pas de constructeurs dans les scripts

Le moteur s’occupe d’instancier les composantes que les objets de jeu contiennent. Ce n’est pas toujours explicite quand un MonoBehaviour sera instancié, car Unity peut détruire une instance et en crée une nouvelle avec le même état sans que cela soit perceptible (les clones n’appelleront pas les évènements d’initialisation). Écrire un constructeur est donc dangereux, car il peut être appelé de façon pseudo aléatoire. De plus, car le développeur n’est pas responsable de créer des instances de composantes, il n’est pas possible d’appeler un constructeur paramétrique. Un projet Unity ne devrait jamais contenir de code avec la sémantique suivante : MaComposante composante = new MaComposante(...). Ceci implique que toutes les composantes sont instanciées avec des valeurs par défaut pour leurs attributs. Par exemple, la ligne int bar initialise un attribut avec la valeur 0 tandis que la ligne int akat = 2 initialise un attribut avec la valeur 2. Pour affecter les attributs avec des valeurs autres que celles programmées en dur, il faut le faire post instanciation — très différent qu’utiliser un constructeur paramétrique.

Les attributs d’un MonoBehaviour et l’inspecteur

Supposons la classe FooComponent qui dérive de MonoBehaviour. Tous les attributs d’instances (attributs non-static) qui sont public seront visibles dans l’inspecteur.

using UnityEngine;

public class FooComponent : MonoBehaviour
{
    public int bar;
    
    void Awake()
    {
        Debug.Log(bar);
    }
}

console

0

Changer la valeur d’un attribut dans l’inspecteur est une façon de modifier l’état d’une composante post instanciation. La valeur dans l’inspecteur sera tout de suite affectée à la composante après qu`elle soit instanciée. En pratique, l’inspecteur remplace l’écriture d’un constructeur paramétrique, malgré que ces deux méthodes sont techniquement distinctes.

N.B. Dans un chapitre avenir, le masquage d’attribut et l’encapsulation sera vus.