Eviter la scene unique monstrueuse : decouper un jeu Godot 4 en modules reutilisables
Formations

Eviter la scene unique monstrueuse : decouper un jeu Godot 4 en modules reutilisables

Antharuu Antharuu
12 min de lecture
godot 4 tutoriel godot nodes godot scenes godot scene tree godot instancier une scene godot architecture projet godot organisation des nodes prefab godot hud godot

Vous avez un projet Godot vide, vous savez naviguer dans l'editeur sans paniquer, et maintenant vous vous demandez : 'OK, mais comment Godot pense mon jeu ?' La reponse tient en trois mots : Nodes, Scenes, Scene Tree.

C'est simple sur le papier : des objets (nodes) organises en arborescence, sauvegardes dans des fichiers (scenes), puis reutilises par instanciation. Mais c'est aussi ce qui rend Godot tres robuste quand on construit un projet propre, modulable, et pas une scene unique monstrueuse.

Dans ce module, on va poser des bases solides, sans code, uniquement avec l'editeur. L'objectif n'est pas de faire un jeu jouable, mais de comprendre le coeur du moteur.

1) Contexte (ou on en est)

  • Projet Godot 4.x vide (ou quasi vide)
  • Vous savez retrouver les docks : Scene, Inspector, FileSystem
  • Vous savez lancer le jeu (F5) et lancer la scene courante (F6)
  • Vous avez deja l'intuition que tout est organise en hierarchie

Ce qu'il vous manque, c'est le modele mental : comment un jeu Godot est structure, comment on decoupe, et comment on evite de tout empiler dans Main.tscn.

On va donc creer deux scenes reutilisables :

  • Player.tscn (le joueur)
  • HUD.tscn (l'interface)

Puis on va les instancier dans une scene Main.tscn.

2) Objectifs (ce que vous devez savoir faire a la fin)

A la fin de ce module, vous serez capable de :

  1. Expliquer ce qu'est un Node et citer des exemples concrets (player, enemy, UI).
  2. Expliquer ce qu'est une Scene (.tscn) et pourquoi ce n'est pas juste 'un niveau'.
  3. Lire le Scene Tree (parent/enfant) et comprendre pourquoi ca change tout (transformations, organisation, logique).
  4. Comprendre l'idee de scene reutilisable (comme un prefab) et l'interet pour un projet reel.
  5. Creer Player.tscn et HUD.tscn (meme avec des placeholders).
  6. Instancier ces scenes dans Main.tscn via l'editeur (sans code).
  7. Comprendre les local changes et comment eviter de casser la scene d'origine.
  8. Savoir quand creer une nouvelle scene vs garder quelque chose dans la scene principale.

3) Vocabulaire minimal (sans jargon inutile)

  • Node (Noeud) : une brique de base. Un node a des proprietes, peut avoir un script, peut emettre/recevoir des signaux, et surtout peut avoir des enfants.
  • Scene (Scene) : un fichier .tscn qui sauvegarde un arbre de nodes (une structure complete, reutilisable).
  • Scene Tree : la hierarchie parent -> enfants que vous voyez dans le dock Scene. C'est la structure reelle du jeu.
  • Root node (Noeud racine) : le node tout en haut d'une scene. Tous les autres sont en dessous.
  • Instance : une scene 'posee' dans une autre scene. Vous reutilisez un bloc deja construit.
  • Local change : une modification faite sur une instance dans la scene qui l'utilise, sans modifier la scene source.
  • Revert : revenir a la valeur d'origine (celle de la scene source) pour une propriete modifiee localement.
  • Make Local : detacher une instance de sa scene source (vous obtenez une copie locale, independante).

Gardez une phrase en tete :

Un node est une brique. Une scene est un ensemble de briques organise. Le Scene Tree est la maniere dont ces briques sont rangees.

4) Comprendre les Nodes (avec des exemples qui parlent)

Un Node, c'est un objet du moteur, mais pas au sens 'objet 3D' ou 'sprite'. C'est plutot une entite logicielle qui fait quelque chose : afficher, detecter, gerer des entrees, jouer un son, organiser l'UI, animer.

Quelques exemples tres concrets (2D) :

  • Node2D : un node avec une transformation 2D (position, rotation, echelle). Utile comme conteneur.
  • CharacterBody2D : un node fait pour le deplacement avec collisions (parfait pour player et enemies).
  • Sprite2D : affiche une texture.
  • CollisionShape2D : donne une forme de collision a un objet (hitbox).
  • Area2D : zone de detection (ramasser une piece, declencher un piege, zone de degats).
  • Control (et ses enfants Label, Button, TextureRect...) : base pour l'UI.
  • CanvasLayer : un calque d'UI independant de la camera (ideal pour un HUD).

Ce qui est important : dans Godot, un node est rarement seul. Un player n'est pas 'juste' un CharacterBody2D. Il a besoin d'un visuel, d'une collision, parfois d'une animation, de sons, etc. Donc on construit naturellement une hierarchie.

Exemple typique :

Player (CharacterBody2D)
├── PlayerSprite (Sprite2D)
└── PlayerCollision (CollisionShape2D)

Vous voyez deja la logique : le node racine porte la 'logique' (deplacement, interactions), et les enfants portent les 'composants' (visuel, collision). Ce n'est pas une regle absolue, mais c'est un standard sain.

5) Comprendre les Scenes (et pourquoi ce n'est pas qu'un niveau)

Une Scene, dans Godot, est un fichier .tscn qui contient un arbre de nodes. Beaucoup de debutants pensent 'scene = niveau'. En realite, une scene peut representer :

  • un player (Player.tscn)
  • un enemy (Enemy.tscn)
  • une UI (HUD.tscn)
  • un bouton complexe (PauseMenu.tscn)
  • un morceau de decor (Crate.tscn, Door.tscn)
  • un niveau complet (Level01.tscn)
  • la scene principale (Main.tscn) qui assemble le tout

L'idee cle : une scene peut etre un module. Comme un prefab dans d'autres moteurs. Vous la construisez une fois, proprement, puis vous la reutilisez partout.

Pourquoi c'est crucial ?

  • Ca evite le copier-coller de nodes.
  • Ca rend le projet lisible.
  • Ca permet de modifier un module (ex : Player) et de retrouver le changement partout ou il est instancie.
  • Ca limite la taille de Main.tscn.

6) Scene Tree : parent/enfant, et pourquoi c'est important (pas juste pour ranger)

Le Scene Tree n'est pas qu'une liste pour faire joli. La relation parent/enfant a des consequences directes :

6.1 Transformations relatives (le truc qui sauve votre temps)

En 2D, la position d'un enfant est relative a celle du parent.

Donc si vous deplacez Player, son Sprite2D et sa CollisionShape2D suivent automatiquement. C'est exactement ce qu'on veut.

6.2 Organisation et lecture du projet

Une hierarchie bien faite vous permet de 'lire' un objet comme un schema :

  • racine = role principal
  • enfants = composants

Quand vous ouvrez la scene d'un enemy, vous devez comprendre en 10 secondes :

  • ou est le sprite
  • ou est la collision
  • ou sont les zones de detection

6.3 Maintenance (le vrai sujet)

Quand votre jeu grossit, vous passez plus de temps a relire et modifier qu'a creer. Une hierarchie propre vous economise des heures.

Un detail tres pratique : nommer correctement vos nodes. Evitez Sprite2D3 et CollisionShape2D7. Renommez tout de suite :

  • PlayerSprite
  • PlayerCollision
  • ScoreLabel

C'est un effort minuscule pour un gain enorme, surtout quand on ajoutera du code plus tard.

7) Quand creer une nouvelle scene vs garder dans Main ?

C'est une question que vous vous poserez tout le temps. Voici une regle simple, avec du bon sens :

Creez une nouvelle scene quand :

  • L'objet est reutilisable (player, enemy, projectile, coffre, UI).
  • L'objet est complexe (plusieurs nodes, une logique, des variantes).
  • Vous voulez pouvoir tester l'objet en isolation (ouvrir Player.tscn et voir juste le player).
  • Vous sentez que Main.tscn commence a devenir un fourre-tout.

Gardez dans Main quand :

  • C'est specifique au niveau ou a la scene (un decor unique, un node 'manager' temporaire).
  • C'est un assemblage unique qui ne sera jamais reutilise.
  • C'est du 'glue' : le fait de connecter des pieces ensemble.

Pensez a Main.tscn comme a une table de montage. On y assemble, on n'y fabrique pas toutes les pieces.

8) Demonstration dans l'editeur (sans code)

Objectif : creer deux scenes reutilisables, meme si elles sont encore vides ou tres simples, puis les instancier dans Main.tscn.

8.1 Creer Player.tscn (placeholder propre)

  1. Scene > New Scene (ou Ctrl+N)
  2. Choisissez comme noeud racine : CharacterBody2D
  3. Renommez-le : Player
  4. Ajoutez deux enfants a Player :
    • Sprite2D -> renommez PlayerSprite
    • CollisionShape2D -> renommez PlayerCollision
  5. Ne cherchez pas encore a faire bouger quoi que ce soit. On veut juste la structure.
  6. Sauvegardez : File > Save Scene As... -> res://Player.tscn

Arbre attendu :

Player (CharacterBody2D)
├── PlayerSprite (Sprite2D)
└── PlayerCollision (CollisionShape2D)

Notes utiles :

  • Le Sprite2D peut rester sans texture. C'est OK, c'est un placeholder.
  • La CollisionShape2D vous demandera peut-etre une Shape dans l'Inspector plus tard. Pour ce module, la presence du node suffit.

8.2 Creer HUD.tscn (un HUD minimal)

  1. Scene > New Scene
  2. Racine : CanvasLayer (important pour que l'UI reste au-dessus du monde)
  3. Renommez la racine : HUD
  4. Ajoutez un enfant : Label
  5. Renommez-le : ScoreLabel
  6. Dans l'Inspector du Label, mettez Text a : Score: 0
  7. Sauvegardez : res://HUD.tscn

Arbre attendu :

HUD (CanvasLayer)
└── ScoreLabel (Label)

Pourquoi CanvasLayer ?

  • Parce que le HUD ne doit pas bouger avec la camera. Le monde peut se deplacer, mais l'UI doit rester collee a l'ecran.

8.3 Creer Main.tscn et instancier Player + HUD

  1. Creez ou ouvrez Main.tscn
    • Si elle n'existe pas : New Scene -> racine Node2D -> renommez Main -> sauvegardez res://Main.tscn
  2. Dans Main.tscn, selectionnez Main
  3. Cliquez sur Instance Child Scene (bouton d'instanciation dans le dock Scene)
  4. Choisissez Player.tscn
  5. Recommencez : instanciez HUD.tscn

Vous obtenez un arbre qui ressemble a :

Main (Node2D)
├── Player (CharacterBody2D) [instance]
└── HUD (CanvasLayer) [instance]

Optionnel (pour bien sentir le concept) :

  • Dupliquez le Player dans Main (Ctrl+D) pour en avoir 2 ou 3.
  • Vous verrez que ce sont plusieurs instances du meme module.

Test :

  • Lancez avec F6 (scene courante) ou F5 (projet).
  • Il n'y aura peut-etre pas grand-chose a l'ecran si le sprite est vide, mais l'important est : pas d'erreur, hierarchie propre, instances visibles dans l'arbre.

9) Local changes : modifier une instance sans casser l'original

C'est un point souvent mal compris, donc on va le rendre concret.

Imaginez :

  • Player.tscn est votre modele.
  • Dans Main.tscn, vous avez une instance de Player.

Si, dans Main.tscn, vous selectionnez l'instance de Player et vous changez une propriete (par exemple sa position), Godot considere souvent ca comme une modification locale. C'est normal : chaque instance doit pouvoir etre placee differemment.

Mais vous pouvez aussi faire des changements plus profonds (selon les cas et les options d'edition d'instance). Godot vous indiquera qu'il y a une difference entre l'instance et la scene source. C'est ce qu'on appelle un local change.

Comment ne pas casser l'original ?

  • Si vous voulez que le changement s'applique a tous les Players du jeu, modifiez Player.tscn directement.
  • Si vous voulez un changement uniquement pour cette instance dans Main.tscn, faites un changement local.

Revert

Si vous avez modifie une propriete localement et que vous voulez revenir a la valeur d'origine, utilisez Revert (retour a la scene source). C'est une securite precieuse quand on a bidouille.

Make Local (attention)

Make Local detache l'instance : elle n'est plus liee a la scene source.

  • Avantage : vous pouvez la modifier librement sans impacter l'original.
  • Inconvenient : vous perdez les mises a jour automatiques venant de Player.tscn.

Bon reflexe :

  • Tant que possible, gardez le lien avec la scene source.
  • Utilisez Make Local seulement quand vous assumez de creer une variante unique.

10) Pieges courants (et comment les eviter)

Piege 1 : la scene unique monstrueuse

Symptome : Main.tscn contient tout, des dizaines de nodes, des sous-groupes, des trucs temporaires, et personne ne comprend rien.

Solution :

  • decouper en scenes reutilisables (player, enemy, UI, objets interactifs)
  • garder Main.tscn comme assembleur

Piege 2 : des noms incoherents

Symptome : Sprite2D, Sprite2D2, Node2D5.

Solution :

  • renommer immediatement
  • adopter une convention simple : PlayerSprite, PlayerCollision, ScoreLabel
  • etre constant (meme style partout)

Piege 3 : ne pas savoir ou faire une modification

Symptome : vous changez un truc dans une instance, puis vous vous etonnez que les autres instances ne bougent pas. Ou l'inverse.

Solution :

  • demandez-vous : 'est-ce un changement global (scene source) ou local (instance) ?'
  • si global : ouvrez Player.tscn
  • si local : modifiez dans Main.tscn et acceptez le local change

11) Exercices

Exercice (obligatoire) : creer Player.tscn proprement

Objectif : construire la scene reutilisable, sans s'occuper du deplacement.

  1. Creez Player.tscn avec :
    • racine CharacterBody2D renommee Player
    • enfant Sprite2D renomme PlayerSprite
    • enfant CollisionShape2D renomme PlayerCollision
  2. Sauvegardez la scene.
  3. Ne bougez rien, ne codez rien. On veut juste une base propre.

Critere de reussite :

  • l'arbre est exactement celui attendu
  • les noms sont propres
  • le fichier res://Player.tscn existe

Challenge : creer HUD.tscn minimal

Objectif : une UI reutilisable.

  1. Creez HUD.tscn avec :
    • racine CanvasLayer renommee HUD
    • enfant Label renomme ScoreLabel
    • texte : Score: 0
  2. Sauvegardez.
  3. Instanciez le HUD dans Main.tscn.

Critere de reussite :

  • HUD.tscn existe
  • le Label affiche Score: 0 en jeu (si vous lancez la scene)

12) Recap + checklist

Idee centrale : Godot = des nodes organises en arbre, sauvegardes en scenes reutilisables, instanciees pour construire le jeu.

Checklist :

  • Je sais expliquer ce qu'est un Node et citer des exemples (CharacterBody2D, Sprite2D, Control).
  • Je sais expliquer ce qu'est une Scene (.tscn) et pourquoi c'est reutilisable.
  • Je comprends le Scene Tree (parent/enfant) et les transformations relatives.
  • J'ai cree Player.tscn avec PlayerSprite et PlayerCollision.
  • J'ai cree HUD.tscn avec ScoreLabel qui affiche Score: 0.
  • J'ai instancie Player et HUD dans Main.tscn via l'editeur, sans code.
  • Je sais ce qu'est un local change et je sais quand modifier la scene source vs l'instance.
  • Je sais reconnaitre le piege de la scene unique monstrueuse et je renomme mes nodes.

13) Mini quiz (pour verifier que c'est acquis)

  1. En une phrase : quelle est la difference entre un Node et une Scene ?
  2. Pourquoi une hierarchie parent/enfant est-elle utile pour un player avec sprite et collision ?
  3. Player.tscn est instancie 5 fois dans Main.tscn. Vous voulez changer la taille du sprite pour tous les players. Vous modifiez ou ?
  4. Vous avez deplace un Player dans Main.tscn et Godot indique un changement local. Est-ce un probleme ?
  5. Cite deux signes que votre projet est en train de tomber dans le piege de la 'scene unique monstrueuse'.

Articles similaires