Up to date

This page is up to date for Godot 4.2. If you still find outdated information, please open an issue.

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. 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 : La simplification de l'API en objets de plus petite portée permet d'améliorer son accessibilité et de réduire le temps d'itération. Plutôt que de travailler avec l'ensemble de la bibliothèque Node, on crée un ensemble abrégé d'objets à 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. RefCounted: Only a little more complex than Object. They track references to themselves, only deleting loaded memory when no further references to themselves exist. These are useful in the majority of cases where one needs data in a custom class.

    • Example: See the FileAccess object. It functions just like a regular Object except that one need not delete it themselves.

    • Avantages : les mêmes que l'objet.

  3. Resource: Only slightly more complex than RefCounted. They have the innate ability to serialize/deserialize (i.e. save and load) their object properties to/from Godot resource files.

    • 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.

    • Advantages: Much has already been said on Resource's advantages over traditional data storage methods. In the context of using Resources over Nodes though, their main advantage is in Inspector-compatibility. While nearly as lightweight as Object/RefCounted, they can still display and export properties in the Inspector. This allows them to fulfill a purpose much like sub-Nodes on the usability front, but also improve performance if one plans to have many such Resources/Nodes in their scenes.