Quand et comment éviter d’utiliser des nœuds pour tout

Les nœuds sont bon marché à produire, mais ils ont aussi leurs limites. Un projet peut avoir des dizaines de milliers de nœuds qui font tous quelque chose. Cependant, plus leur comportement est complexe, plus la pression qu’ils exercent sur la performance d’un projet est grande.

Godot fournit des objets plus légers pour créer des APIs qui utilisent des nœuds. N’oubliez pas qu’il s’agit d’options lorsque vous concevez la façon dont vous souhaitez construire les fonctionnalités de votre projet.

  1. ref:Object <class_Object> : L’objet léger ultime, l’Object original doit utiliser la gestion manuelle de la mémoire. Cela dit, il n’est pas trop difficile de créer ses propres structures de données personnalisées, même des structures de nœuds, qui sont aussi plus légères que la classe Node.

    • Exemple: Voir le nœud Tree. Il supporte un haut niveau de personnalisation pour une table des matières avec un nombre arbitraire de lignes et de colonnes. Les données qu’il utilise pour générer sa visualisation sont en fait un arbre d’Objects TreeItem.
    • Avantages: Simplifier son API à des objets de petite taille permet d’améliorer son accessibilité et d’améliorer le temps d’itération. Plutôt que de travailler avec l’ensemble de la bibliothèque de nœuds, on crée un ensemble abrégé d’Objects à partir duquel un nœud peut générer et gérer les sous-nœuds appropriés.

    Note

    Il faut être prudent quand on les manipule. On peut stocker un Object dans une variable, mais ces références peuvent devenir invalides sans avertissement. Par exemple, si le créateur de l’Object décide de le supprimer, cela déclencherait un état d’erreur lorsqu’on y accède ensuite.

  2. ref:Référence <class_Reference> : Seulement un peu plus complexe que l’Object. Elles suivent les références à elle-mêmes, effaçant seulement la mémoire chargée quand aucune autre référence à elles-mêmes n’existe. Elles sont utiles dans la majorité des cas où l’on a besoin de données dans une classe personnalisée.

    • **Exemple:**Voir l’objet Fichier. Il fonctionne comme un Object normal, sauf qu’il n’est pas nécessaire de l’effacer soi-même.
    • Avantages: les mêmes que l’objet.
  3. ref:Ressource <class_Resource> : Seulement un peu plus complexe que la Reference. elles ont la capacité innée de sérialiser/désérialiser (c’est-à-dire de sauvegarder et de charger) leurs propriétés objet dans les fichiers ressources Godot.

    • Exemple: Scripts, PackedScene (pour les fichiers de scène), et d’autres types comme chacune des classes AudioEffect. Chacune d’entre elles peut être sauvegardée et chargée, donc elles s’étendent à partir de Resource.
    • Avantages: Beaucoup de choses ont été dites: sur les avantages des Resource par rapport aux méthodes traditionnelles de stockage de données. Dans le contexte de l’utilisation des ressources sur les nœuds cependant, leur principal avantage réside dans la compatibilité avec l” inspecteur. Bien qu’ils soient presque aussi légers que Object/Reference, ils peuvent toujours afficher et exporter des propriétés dans l’inspecteur. Cela leur permet de remplir un objectif similaire à celui des sous-nœuds sur le plan de l’utilisabilité, mais aussi d’améliorer les performances si l’on prévoit d’avoir beaucoup de ces ressources / nœuds dans ses scènes.