Architecture logiciel avec Unity

Une bonne architecture logiciel dans votre projet de jeu fait avec Unity pourrait littéralement vous sauvez la mise pour vous rendre jusqu’au bout. Avec mon expérience, j’ai fini par créé une architecture solide pour travailler avec une équipe multidisciplinaire de façon efficace et évitant le plus possible de saboter le travaille des autres par accident.

Le GManager

Comment partager les informations d’une scène à une autre de façon efficace avec un « Global Manager » ou un « Game Manager » si vous préférez ce terme plus geek.

J’ai déjà écrit un article, avec exemple, sur le GManager dans mon blog. Si vous désirez le consulter cliquez ici.

« Oui, mais Sebz, je sais déjà comment faire passer de l’information d’une scène à l’autre! » – Ce dit surement quelqu’un en ce moment –

Il faut se demander les questions suivante :

Est-ce que je dois commencer à partir de la première scène pour pouvoir faire fonctionner le jeu correctement? Si oui, vous avec un problème.
Est-ce qu’un non programmeur peut changer la valeur par défaut sans entrer dans le code? Penser au autre utilisateur, ce n’est pas à négliger.
Esr-ce qu’on peut accéder à ses informations sans avoir à hardcoder des string? Cela créera un problème d’IntelliSense mentionné plus pas.
Est-ce que toutes les scènes peuvent facilement accéder à l’information? Une manipulation complexe à chaque fois qu’on veux la variable c’est chiant.
Est-ce que l’achèvement de code intelligent (IntelliSense) prend en conte la solution? Je vous l’avais dit qu’on reviendrait sur ce point. C’est peut être redondant par contre 🤔
Est-ce que je peux simuler les valeurs reçu facilement quand je travaille sur une scène pour ne pas avoir à tester à partir d’une autre scène? C’est le problème que j’ai eu avec les solutions trouvées sur les forums.
Et le plus important, est-ce que la solution donne encore plus de pouvoir aux chats sur le Web? C’est une conspiration il faut prendre ça au sérieux.

C’est pour ces différente raison que j’ai développé le GManager qui s’instancie par lui même avec des valeurs par défaut dans l’Inspector de Unity grâce à une combinaison d’un MonoBehaviour static (Inspirer du singleton sans en être vraiment un) et de ScriptableObjects.

Les SManagers

Voici le chef d’orchestre de votre scène, le « Scene Manager ». Le respecter c’est respecter le cœur de votre jeu, ou projet. Surtout si c’est pour détruire la conspiration des chats du Web (CCW)

Le SManager fera surement parti d’un prochaine article, mais pour l’instant je n’ai pas de lien.

« C’est quoi ton problème avec les chats du Web, Sebz? » – Ce dit ceux qui ne croient pas en la conspiration –

Là vous vous égarez! On est ici pour parler d’architecture logiciel!

Bon, la logique de votre jeu doit surtout ce trouver dans cet objet qui sera instancié manuellement (contrairement au GManager) et qui permettra au différant élément de votre jeux de communiquer.

Les questions à vous posez :

Comment faire pour contrôler l’ordre du Update des différents MonoBehaviour de votre scène? Ça sa m’a créer des gros problème dans le passé.
Comment bien centraliser la mécanique général de notre jeu? Si vous éparpiller la logique du jeu dans vos différent MonoBehaviours de votre projet ça pourrait vite devenir indigérable pour votre cerveau. Votre cerveau est votre ami, dite non à la drogue. Fait ce que je dit pas ce que je fais.

Le SManager est très classique en général. Je l’ai vu dans plusieurs tutoriels et forums. Par contre, je lui ai apporté quelques modifications pour justement contrôler l’ordre des Update. Rien de ouf, mais ça pourrait sauver votre projet.

Les Behaviours

Ou comment donner un nouveau nom aux MonoBehaviours.

Les Behaviours sont tout simplement des MonoBehaviours classique dans lequel j’ajoute un Observateur que le SManager utilise pour gérer l’ordre d’exécution. Un article est prévu pour ce type d’élément.

« Pourquoi donner un nouveau nom aux MonoBehaviours? » – Ce dit ceux qui posent trop de question –

Tout simplement pour ma nomenclature des classes que j’utilise. NomDeLaClassBehaviour est beaucoup plus short and sweet que NomDeLaClassMonoBehaviour 😜

Il est toujours préférable d’utiliser ce type d’objet pour les éléments visible de votre jeu. Sinon, il serait peut-être préférable d’utiliser une simple class que j’appelle Module dont les instances seront gérer par le SManager.

Les Modules

Juste pour éviter que les élément vu plus haut deviennent trop volumineux.

Les Modules sont des simples classes avec une architecture semblable aux MonoBehaviours pour séparer la logique des éléments citer plus haut.

« Et c’est pour quand les filles tout nue que tu nous as promis? – Ce dit un gars saoul –

Bin! J’ai jamais promis ça! (Mettre lien vers une site pour adulte que je vais faire ici)

Les Modules ont une architecture de base semblable à un MonoBehaviour, mais avec ses éléments publique :

public void Awake(){
}
public void Start(){
}
public void Update(){
}

De cette façon, un MonoBehaviour pourra séparer sa logique en plusieurs points différents :

using UnityEngine;

using Talkudo.Projet.Modules;

namespace Talkudo.Projet.Behaviours.SManagers{
   Public class MonSmanager : MonoBehaviour{
      [...]
      Module1 module1 = new Module1();
      Module2 module2 = new Module2();
      Module3 module3 = new Module3();
      void Awake(){
         module1.Awake();
         module2.Awake(this);
         module3.Awake();
      }
      void Start(){
         module1.Start();
         module2.Start();
         module3.Start();
      }
      void Update(){
         module1.Update();
         module2.Update();
         module3.Update();
      }
   }
}

Noté que j’ai mis volontairement le « module2.Awake(this); » parce qu’il arrive très souvent que le module doivent savoir de quelle instance il est issus.

Les Data

Les objets Data sont simplement des ScriptableObjects dans lesquels vous pouvez enregistrer des données avec l’aide de l’Inspector de Unity. Vous en avec un exemple dans mon article sur le GManager. Et c’est comment on fini un article par son début 😎

Articles