Les scènes de Godot et les scripts sont des classes

Dans Godot, les scripts et les scènes sont l'équivalent des classes dans les langages de programmation Orientés Objet. La principale différence étant que les scènes contiennent du code déclaratif, alors que les scripts peuvent contenir du code impératif.

De ce fait, beaucoup de bonnes pratiques de Godot se résument à appliquer des principes de design Orienté Objet dans les scènes, nœuds ou scripts qui composent votre jeu.

Ce guide explique comment les scripts et les scènes fonctionnent dans le cœur du moteur, pour vous aider à avoir une idée de la façon dont Godot fonctionne sous le capot, et pour vous aider à mieux comprendre d'où viennent certaines des meilleures pratiques de cette série.

Donner un sens aux classes dans Godot

Le moteur Godot fournit des classes intégrées comme Node. Les types créés par l'utilisateur ne sont pas techniquement des classes. Au lieu de cela, ce sont des ressources qui indiquent au moteur une séquence d'initialisation à exécuter sur l'une des classes intégrées du moteur.

Les classes internes de Godot ont des méthodes qui enregistrent les données d'une classe avec un ClassDB. Cette base de données fournit un accès runtime aux informations de classe. ClassDB contient des informations sur les classes comme :

  • propriétés
  • les méthodes
  • les constantes
  • les signaux

Cette ClassDB est ce que les Objets vérifient quand ils exécutent une opération comme accéder à une propriété ou appeler une méthode. ClassDB vérifie les enregistrements de la base de données et les enregistrements des types de base de l'objet pour voir si l'objet supporte l'opération.

Côté moteur, chaque classe définit une fonction statique _bind_methods() qui décrit le contenu C++ qu'elle enregistre dans la base et comment. Lorsque vous utilisez le moteur, vous pouvez étendre les méthodes, propriétés et signaux disponibles depuis la ClassDB en attachant un Script à votre noeud.

Les objets vérifient leur script attaché avant la base de données. C'est pourquoi les scripts peuvent remplacer les méthodes intégrées. Si un script définit une méthode _get_property_list(), Godot ajoute ces données à la liste des propriétés que l'objet récupère depuis la ClassDB. Il en va de même pour les autres codes déclaratifs.

même les scripts qui n’héritent pas d'un type basique (built-in), c'est à dire qui ne commencent pas avec le mot clé extends, héritent implicitement de la classe Reference <class_Reference> du moteur. Cela permet l'objet de s'en remettre au contenu du script si la logique du moteur le juge approprié.

Note

Par conséquent, vous pouvez instancier un script sans le mot clé extends dans le code, cependant vous ne pouvez pas l'attacher a une Node

Performances des scripts et PackedScene

Au fur et à mesure que la taille des objets augmente, la taille nécessaire aux scripts pour les créer devient beaucoup, beaucoup plus grande. La création de hiérarchies de nœuds en est la preuve. La logique de chaque Nœud individuel pourrait être de plusieurs centaines de lignes de code.

Voyons un exemple simple, créer un Nœud enfant seul. Le code ci dessous crée un nouveau Nœud, change son nom, lui assigne un script et change son futur parent en son propriétaire, afin qu'il soit sauvegardé sur le disque en même temps que lui, et finalement l'ajoute en tant qu'enfant du nœud Principal (Main) :

# Main.gd
extends Node

func _init():
    var child = Node.new()
    child.name = "Child"
    child.script = preload("Child.gd")
    child.owner = self
    add_child(child)
using System;
using Godot;

namespace ExampleProject
{
    public class Main : Resource
    {
        public Node Child { get; set; }

        public Main()
        {
            Child = new Node();
            Child.Name = "Child";
            Child.Script = (Script)ResourceLoader.Load("child.gd");
            Child.Owner = this;
            AddChild(Child);
        }
    }
}

Le code d'un script comme celui ci est beaucoup plus lent que le C++ du moteur. Chaque modification fait un appel distincts à l'API de script ce qui mène à de nombreuses recherche en arrière plan pour trouver la logique à exécuter.

Les scènes aident à éviter ce genre de problème lié aux performances. PackedScene, le type basique duquel les scènes héritent sont des ressources qui utilisent de données en série pour créer des objets. Le moteur peut ensuite calculer les scènes en lots en arrière plan ce qui permet de bien meilleures performances qu'avec des scripts.

Scenes et scripts sont des objets

Pourquoi tout cela est-il important pour l'organisation de la scène ? Parce que les scènes sont des objets. On associe souvent une scène à un nœud racine scripté qui utilise les nœuds inférieurs. Cela signifie que la scène est souvent une extension du code déclaratif du script.

Le contenu d'une scène aide à définir :

  • Quels nœuds sont disponibles pour le script
  • Comment ils sont organisés
  • Comment ils sont initialisés
  • Quelles connections signal elles ont, les une avec les autres

Beaucoup de principe du paradigme de code Orienté-Objet qui s'appliquent au code écrit s'appliquent aussi aux scènes.

La scène est toujours une extension du script attaché à son nœud racine. Considérez chaque nœud qu'il contient comme une partie d'une unique classe.

La plupart des conseils et techniques expliqués dans cette série s'appuieront sur ça.