Le code rigide – hard coded – et le code modulaire

Même si j’étudie les jeux vidéo depuis 2008, ce n’est que tout récemment que j’ai commencé à apprendre vraiment à les programmer. Je suis à l’aise avec le HTML depuis le secondaire, incluant un peu de PHP depuis que j’ai mon blogue autohébergé, mais je n’avais jamais réussi à vraiment coder pour le jeu vidéo. Je connaissais aussi des moteurs de jeu plus « amateurs », comme RPG Maker avec lequel j’ai déjà fait quelques jeux, et HyperCard, que j’utilisais il y a très longtemps sans vraiment programmer. J’ai aussi utilisé un peu Twine et Ren’Py.

Bref, depuis 2022, je me suis donné comme objectif d’apprendre le langage de programmation C# pour pouvoir accompagner mes étudiant-e-s dans Unity. Je l’ai fait notamment pour créer mon cadre de développement leur permettant de travailler sans avoir à eux-mêmes programmer.

Qu’est-ce qu’un code rigide?

Un code rigide est un code où ce qui doit être accompli par le code est entièrement contenu dans ce code et prédéterminé par le code. Pour prendre un exemple simple, on va, par exemple, déterminer qu’un objet se fera détruire en cinq secondes en l’indiquant de cette manière:

public class DestroyInFiveSeconds : MonoBehaviour
{
    void Start()
    {
        Destroy(gameObject, 5f);
    }
}

Ce code vient « hard coder » que l’objet sur lequel ce script sera placé s’autodétruira cinq secondes après avoir été instancié.

Un code modulaire ou flexible

Pour le rendre plus flexible ou modulaire, on va « sortir » du code des variables qui permettent de rendre le même code plus flexible. Ainsi, on pourrait préférer l’écrire de cette manière:

public class DestroyOnTime : MonoBehaviour
{
    public float _autodestroytime = 5.0f;
    void Start()
    {
        Destroy(gameObject, _autodestroytime);
    }
}

Ici, on a créé une variable, _autodestroytime, qui stocke un nombre continu (float) qu’on appelle au moment où la destruction de l’objet est appelée. Au lieu que le temps soit déterminé par le script lui-même, il peut être changé à l’extérieur du script, soit dans l’inspecteur du moteur de jeu. Il peut aussi être changé par une autre classe (si la variable est publique) ou ailleurs dans la même classe.

Plus on ajoute de modularité, plus on a de flexibilité. Par contre, on peut en arriver à un point où un script devient trop modulaire et manque de clarté. Par exemple, j’ai créé un script appelé SpawnRandomly, qui fait apparaître un objet au hasard parmi une liste, mais il sert à la fois à faire apparaître un objet aléatoire au début d’une scène pour créer un niveau procéduralement et à faire apparaître un objet après l’élimination d’un ennemi ou d’un obstacle. Sa flexibilité se fait au détriment de rendre claire son utilité.