Chargements automatiques contre nœuds normaux

Godot offre une fonctionnalité pour charger automatiquement les noeuds à la racine de votre projet, vous permettant d’y accéder globalement, ce qui peut remplir le rôle d’un Singleton : Singletons (Chargement Automatique). Ces noeuds auto-chargés ne sont pas libérés lorsque vous changez de scène à partir du code avec SceneTree.change_scene.

Dans ce guide, vous apprendrez quand utiliser la fonction de Chargement Automatique et les techniques que vous pouvez utiliser pour l’éviter.

Le problème du son qui coupe

D’autres moteurs pourraient encourager l’utilisation de la création de classes « manager » qui organisent un grand nombre de fonctionnalités en une entité globalement accessible. Godot fournit de nombreux moyens d’éviter d’utiliser un état global grâce à l’arbre des nœuds et aux signaux.

Par exemple, que se passe-t-il si un développeur construit un platformer et qu’il veut collectionner des pièces qui jouent un effet sonore ? Eh bien, il y a un nœud pour cela : le AudioStreamPlayer. Mais si on appelle un AudioStreamPlayer alors qu’il joue déjà un son, alors le nouveau son interrompt le précédent.

Une solution possible est de coder une classe globale de gestionnaire de son chargée automatiquement. Elle génère un pool de nœuds AudioStreamPlayer qui passe d’un lecteur à l’autre à chaque nouvelle demande d’effet sonore. Disons que nous appelons cette classe Sound, elle peut être utilisée n’importe où dans le projet en appelant Sound.play("coin_pickup.ogg"). Cela résout le problème à court terme mais cause de nouveaux problèmes :

  1. État global : un seul objet est maintenant responsable des données de tous les objets. Si la classe Sound a des erreurs ou n’a pas d’AudioStreamPlayer disponible, tous les nœuds qui l’appellent vont dysfonctionner.
  2. Accès global : maintenant que n’importe quel objet peut appeler ``Sound.play(sound_path)``de n’importe où, il n’y a plus de moyen facile de trouver la source d’un bug.
  3. Allocation globale des ressources : avec un pool de nœuds AudioStreamPlayer stockés dès le départ, vous pouvez en avoir trop peu et rencontrer des bugs, ou en avoir trop et utiliser plus de mémoire que nécessaire.

Note

En ce qui concerne l’accès global, le problème est que n’importe quel code n’importe où pourrait transmettre des données erronées à la classe chargée automatiquement Sound dans notre exemple. Par conséquent, le domaine à explorer pour corriger des bugs s’étend sur l’ensemble du projet.

Lorsque vous gardez le code à l’intérieur d’une scène, un ou deux scripts seulement peuvent être impliqués dans l’audio.

Comparez cela avec chaque scène qui garde autant de nœuds AudioStreamPlayer qu’il lui faut et tous ces problèmes disparaissent :

  1. Chaque scène gère ses propres informations d’état. S’il y a un problème avec les données, cela ne causera des problèmes que dans une seule scène.
  2. Chaque scène accède uniquement à ses propres nœuds. Ainsi, si il y a un bug, il est facile de trouver quel nœud pose problème.
  3. Chaque scène alloue exactement la quantité de ressources dont elle a besoin.

Gérer des données ou des fonctionnalités partagées

Une autre raison d’utiliser un Chargement Automatique peut être que vous souhaitez réutiliser la même méthode ou les mêmes données à travers plusieurs scènes.

Dans le cas des fonctions, vous pouvez créer un nouveau type de nœud qui fournit cette fonctionnalité pour une scène individuelle en utilisant le mot-clé class_name dans GDScript.

En ce qui concerne les données, vous pouvez :

  1. Créez un nouveau type de Resource pour partager les données.
  2. Stocker les données dans un objet auquel chaque noeud a accès, par exemple en utilisant la propriété owner pour accéder au nœud racine de la scène.

Quand utiliser un Chargement Automatique

Les nœuds chargés automatiquement peuvent simplifier votre code dans certains cas :

  • Données statiques : si vous avez besoin de données exclusives à une classe, comme une base de données, un chargement automatique peut être un bon outil. Sinon, il n’y a pas d’API de script dans Godot pour créer et gérer des données statiques.
  • Fonctions statiques : création d’une bibliothèque de fonctions qui ne font que retourner des valeurs.
  • Systèmes avec une large portée : Si le singleton gère ses propres informations et n’envahit pas avec les données d’autres objets, alors c’est un excellent moyen de créer des systèmes qui gèrent des tâches à grande portée. Par exemple, une quête ou un système de dialogue.

Jusqu’à Godot 3.1, une autre utilisation était juste pour plus de commodité : les chargements automatiques ont une variable globale pour leur nom générée dans GDScript, vous permettant de les appeler à partir de n’importe quel fichier de script de votre projet. Mais maintenant, vous pouvez utiliser le mot-clé class_name à la place pour obtenir l’auto-complétion pour un type dans l’ensemble de votre projet.

Note

Autoload is not exactly a Singleton. Nothing prevents you from instantiating copies of an auto-loaded node. It is only a tool that makes a node load automatically as a child of the root of your scene tree, regardless of your game’s node structure or which scene you run, e.g. by pressing F6 key.

Par conséquent, vous pouvez obtenir le nœud chargé automatiquement, par exemple un chargement automatique appelé Sound, en appelant get_node("/root/Sound").