Examen de la version Godot 4.7 : Innovations architecturales, écosystème de développement et standards de production

En tant que l'un des représentants les plus importants et innovants de l'écosystème des moteurs de jeu open source, Godot a atteint un niveau de maturité critique en matière de modularité architecturale, de fidélité graphique et d'ergonomie pour les développeurs avec sa version stable 4.7, publiée le 18 juin 2026 1. Alors que les versions précédentes se concentraient sur la stabilisation des systèmes de base du moteur et la correction des bugs fondamentaux, la version 4.7 adopte une structure axée sur « la production et les flux de travail », visant directement à résoudre les goulots d'étranglement rencontrés au quotidien par les studios professionnels et les développeurs indépendants en phase de production 3. Avec la mise à jour de maintenance 4.7.2 publiée le 18 août 2026, les coordonnées des ombres PCSS, les performances sous Windows des souris dotées d'un taux d'interrogation (polling rate) élevé, ainsi que les légers problèmes dans les scénarios de réplication multijoueur ont également été résolus, consolidant ainsi la stabilité du moteur en environnement de production (production-ready) 5.

Plutôt que de proposer un tout nouveau moteur physique ou un pipeline de rendu entièrement réécrit de zéro, Godot 4.7 est un pack d'optimisations approfondies qui élargit les infrastructures de rendu Forward+ et Mobile existantes, résout les problèmes chroniques liés aux animations d'interface utilisateur (UI), standardise les processus de développement mobile et répond aux exigences matérielles modernes telles que la Plage Dynamique Élevée (HDR) 2. Lors des évaluations menées par la communauté et les professionnels de l'industrie, on constate que les développeurs utilisant depuis de nombreuses années différents moteurs propriétaires (par exemple Unity) sont particulièrement impressionnés par les capacités de rendu et la rapidité de prototypage de Godot 4.7 2. Ce rapport examine, dans un cadre analytique extrêmement complet, les innovations techniques offertes par Godot 4.7, l'impact de ces innovations sur l'architecture logicielle, les retours de la communauté et les évaluations stratégiques des projets lors de leur transition vers cette nouvelle version.

Moteur de rendu et innovations dans l'infrastructure graphique 3D

Le pipeline de traitement graphique est l'un des domaines où Godot 4.7 a réalisé les progrès les plus marquants. Dans le développement de jeux moderne, l'équilibre délicat entre photoréalisme et optimisation des performances dépend de la diversité des outils offerts par le moteur de rendu et de sa capacité d'accélération matérielle. La nouvelle version propose des fonctionnalités analytiques qui répondent aux standards de l'industrie à tous les niveaux, du calcul de l'éclairage à la gestion des matériaux.

Lumières de zone (AreaLight3D) et physique de l'éclairage

Les modèles d'éclairage sont l'élément le plus fondamental qui détermine la crédibilité visuelle des moteurs de rendu 3D. Avant Godot 4.7, les développeurs devaient regrouper des lumières ponctuelles (point lights) ou utiliser des matériaux émissifs (emissive) soutenus par l'illumination globale (Global Illumination) pour simuler des sources lumineuses rectangulaires ou à large surface (par exemple : enseignes au néon, immenses fenêtres industrielles, écrans de télévision, lampes fluorescentes ou éclairages de studio doux) 1. Ces solutions temporaires et indirectes engendraient à la fois un coût GPU inutile en termes de performances et s'avéraient insuffisantes en matière de douceur des bords des ombres (pénombre) et de précision physique.

Ajouté à l'architecture des nœuds principaux avec Godot 4.7, le nœud AreaLight3D offre une solution de rendu en temps réel analytique qui permet à la lumière de se propager non pas à partir d'un point unique infiniment petit, mais à partir d'une zone de surface rectangulaire bidimensionnelle aux limites définies 1. Cette architecture structurelle génère des transitions d'ombres naturelles et progressivement adoucies en fonction de la taille physique de la source lumineuse, tout en garantissant une réflexion précise de la forme rectangulaire de la source lumineuse sur les surfaces lisses et réfléchissantes de la scène (specular reflections) 1. Ne nécessitant pas de lancer de rayons (ray tracing), cette approche augmente considérablement la qualité d'éclairage des scènes sans dépasser le budget de performance. En matière de visualisation architecturale, de jeux d'horreur en intérieur (indoor horror) et de conception d'atmosphères cinématographiques, cette évolution offre aux concepteurs de scènes un flux de travail beaucoup plus propre et une qualité visuelle supérieure.

Prise en charge de la sortie vidéo en Plage Dynamique Élevée (HDR)

Avec les progrès des technologies d'affichage, le matériel dépassant les limites de l'espace colorimétrique sRGB standard est devenu la norme sur le marché grand public. Godot 4.7 a acquis la capacité de transmettre les données d'éclairage à plage dynamique élevée, calculées en interne par le moteur au format virgule flottante (floating point), directement vers les écrans pris en charge via les API HDR au niveau du système d'exploitation 2. Prenant en charge des valeurs de luminosité théoriques allant jusqu'à 10 000 nits, cette fonctionnalité permet de présenter des éléments tels que des explosions, des lumières au néon, des effets de sorts ou la lumière directe du soleil avec une luminosité aveuglante à l'écran, des noirs profonds et une gamme de couleurs (color gamut) beaucoup plus large 3.

Étant donné que la prise en charge de la sortie HDR nécessite une intégration de très bas niveau avec les pilotes matériels et les gestionnaires de fenêtres du système d'exploitation (window manager), les dépendances de la plateforme et du moteur de rendu sont spécifiques. La matrice de configuration relative à l'intégration de cette fonctionnalité est détaillée dans le tableau ci-dessous :

Système d'exploitation / PlateformeÉtat de prise en charge HDRMoteur de rendu requisNotes d'architecture et d'intégrationWindowsEntièrement pris en chargeForward+ ou MobileLes paramètres Windows HD Color au niveau du système d'exploitation doivent être activés et un moniteur compatible doit être utilisé.macOSTentièrement pris en chargeForward+ ou MobileIntégré directement avec les API de gestion HDR natives d'Apple et l'interface Metal.iOS & visionOSEntièrement pris en chargeForward+ ou MobileCompatible avec les capacités de haute luminosité et les structures d'écran XDR des appareils mobiles Apple.Linux (Wayland)Entièrement pris en chargeForward+ ou MobileFonctionne uniquement sous les compositeurs Wayland modernes. Nécessite un protocole de gestion de fenêtres complet.Linux (X11)Non pris en chargeNon applicableDésactivé en raison des limitations de profondeur de couleur de l'ancienne architecture X11. Les développeurs doivent passer à Wayland.AndroidNon pris en chargeNon applicableActuellement indisponible en raison de la forte fragmentation matérielle d'Android.Web (HTML5)Non pris en chargeNon applicableLes limitations des API graphiques de navigateur WebGL and WebGPU ne standardisent pas encore la sortie HDR.

Comme on peut le déduire du tableau, l'utilisation du HDR ne doit pas être traitée comme une obligation globale (requirement), mais plutôt comme une couche d'enrichissement visuel optionnelle qui s'active sur les plateformes prises en charge 4. Les développeurs doivent considérer le HDR non pas comme la base de toute la direction artistique (art direction), mais comme un vernis permettant d'enrichir encore davantage des projets qui s'avèrent déjà de bonne facture en plage dynamique standard (SDR) 4.

L'une des plus grandes ruptures technologiques de l'industrie du jeu vidéo, la technologie de lancer de rayons matériel, a été intégrée à Godot 4.7 en tant qu'infrastructure de plomberie (plumbing) de bas niveau (low-level) dans l'architecture Vulkan du moteur 2. Cette version ne contient pas de fonctionnalités directes destinées à l'utilisateur final telles que les « Réflexions par lancer de rayons » (Ray-traced reflections) ou le « Path tracing » que les joueurs ou les développeurs peuvent activer en un seul clic 10. À la place, le moteur s'est vu doter de la capacité de construire des structures d'accélération (acceleration structures), qui constituent les exigences fondamentales du lancer de rayons, et de lancer des rayons directement depuis le pipeline de rendu Vulkan (ray dispatch) 2.

Cette initiative d'ingénierie stratégique offre une base standardisée permettant aux grands studios d'écrire leurs propres solutions de lancer de rayons sur mesure (par exemple, des shaders d'éclairage personnalisés ou des systèmes de miroirs). Les années précédentes, les équipes souhaitant utiliser le lancer de rayons matériel dépendaient de forks Godot personnalisés (fork) entretenus par NVIDIA ou des développeurs indépendants 2. Cette intégration au cœur du moteur apportée par la version 4.7 est la preuve irréfutable que les fonctionnalités de lancer de rayons intégrées (built-in) fonctionneront directement sur le moteur principal (mainline) dans les versions futures telles que Godot 4.8 et 4.9 2.

DrawableTexture2D et traitement de texture à l'exécution

L'opération de « dessin de texture à l'exécution » (runtime texture drawing), qui est fréquemment requise dans les mécaniques de jeu, était réalisée dans les versions précédentes par le biais d'opérations indirectes et coûteuses, telles que la création d'un Viewport séparé pour y rendre la scène ou l'envoi de commandes GPU de bas niveau via des API RenderingDevice complexes. Godot 4.7 abstrait ces difficultés en introduisant la classe DrawableTexture2D, qui s'avère être une API extrêmement accessible et performante 2.

DrawableTexture2D permet aux développeurs d'écrire des données de pixels ou des traits de pinceau directement sur une texture (texture) au moyen d'appels de transfert standard (blit) 2. Cette fonctionnalité permet même aux développeurs ne maîtrisant pas en profondeur les API de rendu de créer facilement des effets complexes. Par exemple, des masques de brouillard de guerre explorables (fog of war) dans les jeux de stratégie, des traces de pneus dynamiques dans les jeux de course, des mécaniques où les personnages projettent de la peinture sur les surfaces (paint tools), des outils permettant aux joueurs de dessiner librement, des jeux de masques de grattage/révélation (reveal mask) ou des textures d'armure se déformant au fil des dégâts (scratch effects) peuvent être développés à l'aide de cette API sans surcharger le système principal 1.

Pixel art et visuels 3D : Mise à l'échelle Nearest-Neighbor

Les moteurs de rendu 3D traditionnels utilisent par défaut un filtrage bilinéaire (bilinear) lorsqu'ils projettent à l'écran des textures, des habillages ou des sorties d'écran à basse résolution. Bien que cet algorithme de lissage produise d'excellents résultats pour les graphismes photoréalistes, il entraîne des flous indésirables (blurring), en particulier dans les jeux en pixel art 3D à basse résolution ou ceux imitant le style rétro des années 90 (esthétique PS1) 2. De nombreux développeurs au sein de la communauté étaient contraints d'écrire des shaders personnalisés rien que pour éliminer ces imperfections. Godot 4.7 intègre l'option de mise à l'échelle Nearest-Neighbor (plus proche voisin) pour les espaces de visualisation 3D (viewport) en tant que fonctionnalité standard du moteur, offrant un excellent outil de contrôle esthétique qui préserve la netteté et les contours nets des pixels même en cas de réduction de la résolution 1. Cette fonctionnalité constitue une infrastructure indispensable pour les productions indépendantes alliant des caractéristiques 3D modernes à une approche pixel art nostalgique.

Shaders, effets et améliorations des matériaux

Les effets de post-traitement (post-processing) et les systèmes de particules qui définissent le langage visuel du jeu ont également fait l'objet d'optimisations détaillées. Pour les développeurs travaillant sur des shaders textuels basés sur du code (text shaders), la plus grande innovation réside dans les aperçus de shader en ligne (inline) au sein de l'éditeur. Désormais, lorsqu'une modification mathématique est effectuée dans le code du shader (par exemple, la modification de la fréquence d'une fonction d'onde), les changements peuvent être prévisualisés en temps réel directement à l'arrière-plan de l'éditeur de code, sans qu'il soit nécessaire de recompiler le moteur ou de basculer vers un espace de travail différent 2. C'est une avancée qui accroît la vitesse d'itération dans des proportions extraordinaires.

Du côté des matériaux de rendu physique (PBR), les algorithmes de rendu de vernis (clearcoat), utilisés pour simuler des surfaces telles que la peinture de voiture ou le sol mouillé, ont été améliorés ; la réfraction de la lumière à travers ces couches transparentes est devenue plus précise 1. Les passes de rendu (render passes) peuvent désormais abriter leurs propres tampons uniformes (uniform buffers) environnementaux distincts, ce qui confère de la modularité dans les chaînes de post-traitement complexes 1. Quant aux systèmes de particules 3D, ils offrent aux développeurs un contrôle étendu sur l'échelle (scale) et les rotations (rotation) des particules, et des corrections mathématiques ciblant les vitesses angulaires (angular velocity) des particules ont été appliquées pour rendre les simulations plus organiques 1.

Ingénierie de l'Interface Utilisateur (UI) et Animation

Systèmes

Dans les processus de développement de jeux, la conception d'interfaces utilisateur est un domaine qui demande généralement bien plus de temps que le codage de la mécanique centrale du jeu, sujet à des itérations et doté d'une structure extrêmement fragile 9 . Pour permettre aux éléments d'interface de s'adapter aux différentes résolutions sur l'écran de jeu, Godot propose dès le départ un système de mise en page robuste basé sur des nœuds (node-based). Cependant, la version 4.7 résout un problème structurel de longue date dans l'interaction entre les éléments d'interface et les animations, offrant ainsi l'un des ensembles d'outils UI les plus performants du secteur 9 .

Transformations de Décalage des Nœuds Control (Offset Transforms)

Le système de mise en page (layout) UI de Godot repose sur des nœuds Container (Conteneur) hiérarchiques. Les nœuds Control (boutons, panneaux, barres de défilement, etc.) placés à l'intérieur d'un HBoxContainer (boîte horizontale) ou d'un VBoxContainer (boîte verticale) sont gérés de manière stricte par les algorithmes de tri et de placement automatiques du conteneur 1 . Dans les versions précédentes, lorsqu'un designer augmentait l'échelle (scale), l'angle de rotation (rotation) ou la position d'un bouton à l'aide d'une animation Tween pour créer un retour visuel lors du survol (hover state), ce changement était perçu par le conteneur parent comme une « rupture de mise en page ». Le conteneur effectuait un recalcul instantané pour repositionner les éléments d'interface selon sa propre logique algorithmique, ce qui provoquait des sauts indésirables (snap back) des boutons, des scintillements dans les menus et poussait les développeurs à lutter littéralement contre le système de conteneurs (fighting layout) 1 .

La solution la plus critique apportée par Godot 4.7 à l'ingénierie UI est le système de transformations de décalage Control (offset transforms), qui sépare les transformations visuelles du modèle de boîte logique (box model). Les nouvelles propriétés offset_transform_* (position, rotation, échelle) ajoutées déterminent la manière dont l'élément d'interface est dessiné visuellement tout en maintenant ses coordonnées logiques et sa zone d'occupation à l'état d'origine 1 . En d'autres termes, lorsqu'un bouton est agrandi visuellement de 20 % ou déplacé à l'écran à l'aide des transformations de décalage, le conteneur parent ne perçoit pas cette modification comme une mise à jour de la mise en page et conserve ses calculs de positionnement 4 . Cette islation permet aux programmeurs UI et aux artistes techniques de concevoir des animations d'interface fluides, dynamiques et flexibles sans perturber la structure du conteneur ou la logique d'ancrage (anchoring) 4 . Les retours de la communauté confirment que cette fonctionnalité élimine des centaines de lignes de code de contournement (workaround) dans la conception des menus et s'avère « salvatrice » 9 .

Étiquettes de Texte Riche (RichTextLabel) et Dégradés Coniques

Les capacités d'affichage de données des interfaces utilisateur ont été améliorées pour répondre aux exigences de mise à l'échelle dynamique des polices des jeux modernes. Les images intégrées dans un RichTextLabel à l'aide de la balise [img] (par exemple, une touche "A" de manette Xbox ou un symbole emoji spécial affiché dans le texte) peuvent désormais être positionnées de manière sensible à la taille du texte en ligne 1 . Les développeurs peuvent utiliser des définitions de type CSS relatives telles que [img height=1em] pour s'assurer que l'image est automatiquement mise à l'échelle de manière proportionnelle avec la police de texte lorsque la résolution du jeu, les traductions linguistiques ou les paramètres d'accessibilité sont modifiés 3 .

De plus, le mode FILL_CONIC (remplissage conique) a été ajouté à la classe GradientTexture2D, utilisée pour créer des spectres de couleurs dans le domaine des effets 2D et de la conception UI. Contrairement aux dégradés linéaires ou circulaires standard, cette fonction de dégradé conique distribue les couleurs en balayant (sweep) autour du centre d'une manière similaire aux styles CSS. Cet ajout mathématique constitue une base extrêmement pratique pour créer des barres de progression circulaires, des indicateurs de munitions, des effets de balayage radar ou des illusions d'ombrage cylindrique 3D factice (fake 3D shading) lors de l'écriture de shaders 2D 3 .

Écosystème de l'Éditeur et Améliorations du Flux de Travail des Développeurs

Les moteurs de jeux ne sont pas seulement des moteurs de compilation produisant des fichiers exécutables ; ce sont également des logiciels de productivité et de développement (IDE) où les designers, les artistes et les programmeurs passent des milliers d'heures. Dans ce contexte, la fluidité de l'interface de l'éditeur influe directement sur le temps de développement. Godot 4.7 intègre un grand nombre de mises à jour de Qualité de Vie (Quality of Life - QoL) qui optimisent l'expérience de l'éditeur, réduisent le nombre de clics et allègent la charge cognitive dans les grands projets.

La Naissance de l'Asset Store (Ancienne Asset Library)

L'Asset Library (Bibliothèque d'actifs), qui offrait depuis de nombreuses années aux développeurs de Godot un service de téléchargement d'outils créés par la communauté, a cédé sa place au concept de l'Asset Store (Boutique d'actifs), réécrit de zéro avec des normes d'API modernes 2 . Il ne s'agit pas seulement d'un changement de nom cosmétique, mais d'une révision architecturale de l'infrastructure. Dans l'ancien système, lors du téléchargement de gigantesques paquets d'actifs depuis le serveur ou du traitement de requêtes de recherche, le thread principal de l'éditeur (main thread) se bloquait, entraînant des gels. La nouvelle API de boutique utilise activement les threads d'arrière-plan (background threading) 1 . Ainsi, l'interface de l'éditeur reste totalement réactive (responsive) pendant le téléchargement des contenus 3 . De plus, un zoom sur les images d'aperçu pour examiner de plus près les actifs, des affichages de notes (rating) actualisés par la communauté et un arbre de catégories (vitrine) beaucoup plus épuré ont été intégrés 3 .

Améliorations de l'Inspecteur (Inspector) et Réduction des Pistes d'Animation

Dans les projets 3D à grande échelle, l'un des points où les développeurs perdent le plus de temps est le transfert de structures de données complexes entre nœuds. Grâce à un nouvel outil de panneau ajouté à l'Inspecteur dans Godot 4.7, au lieu de copier et de transférer un à un des variables entre des nœuds similaires (par exemple, des rotations X, Y, Z ou des codes couleur de matériaux), il est devenu possible de copier collectivement une section entière de propriétés (property section) et de la coller en un seul clic sur le même champ d'un autre nœud 1 . Ce mécanisme réduit à zéro la marge d'erreur manuelle, en particulier lors du transfert en bloc de paramètres de matériaux ou de configurations physiques hiérarchiques, et permet un gain de temps considérable 2 .

Le panneau AnimationPlayer et Pistes d'Animation (Animation Tracks), utilisé pour gérer les animations de scènes complexes, a également été repensé sur le plan ergonomique. Lors de l'animation d'un squelette de personnage complexe comportant 40 à 50 pistes différentes, la fonction de « réduction des pistes de nœuds inutilisées » (track collapsing) a été introduite afin d'éviter l'encombrement de l'écran par les pistes et la complexité du défilement (scrolling) 1 . Les images clés (keyframes) situées sur les pistes réduites sont présentées sur une seule ligne sous forme de « représentation globale » (aggregate representation) ; ainsi, les animateurs conservent un guide visuel sur le minutage (timing) global de l'animation, même sans voir les détails spécifiques à l'intérieur des pistes réduites 3 .

Alignement de Scène 3D (Snapping) et Améliorations des Règles

Pour les artistes 3D et les level designers effectuant de la conception de niveaux et de la construction de mondes (world building), les outils de manipulation de scène ont été considérablement renforcés. Avant Godot 4.7, l'assemblage d'actifs et le placement sur des sols s'effectuaient généralement à l'œil ou en saisissant des valeurs numériques. La nouvelle version propose trois ensembles d'outils essentiels conformes aux normes de l'industrie :

1. Alignement par les Sommets (Vertex Snapping) : en maintenant enfoncé le raccourci clavier assigné dans l'éditeur ('B' par défaut), le développeur peut sélectionner directement un sommet spécifique d'un maillage 3D (mesh) et l'accrocher (snap) avec une précision millimétrique aux sommets d'autres objets 1 . Cela évite les espaces vides lors de la conception de donjons modulaires ou de blocs de construction.

2. Chemin 3D et Alignement de Collision (Collider Snapping) : les points du nœud Path3D utilisés pour tracer des trajectoires dans les scènes peuvent désormais être alignés non seulement sur le plan de la caméra (camera plane) du viseur, mais aussi directement sur la surface des Collisionneurs physiques (colliders) présents dans la scène 1 . Cette fonctionnalité offre une facilité vitale lors du traçage de patrouilles d'intelligence artificielle (patrol paths) ou de trajectoires de pistes de course se déplaçant sur des terrains montagneux ou en pente 3 .

3. Règle Avancée (Ruler) : l'outil de mesure 3D utilisé avec la touche modificatrice Shift n'affiche plus seulement la distance absolue entre deux points (par exemple, 15 mètres), mais aussi séparément les vecteurs de longueur relatifs le long de chaque axe de coordonnées dans l'espace tridimensionnel (X, Y, Z) (par exemple, 10m sur l'axe X, 5m sur Y, 10m sur Z) 1 . Ce retour géométrique est tout à fait critique lors de la phase initiale de conception de niveau appelée blockout. De plus, les commandes de la caméra 3D ont été unifiées (unified) avec la fenêtre de jeu intégrée (embedded game view) du moteur, garantissant que le raccourci clavier ou la disposition de navigation du développeur reste identique des deux côtés 3 . Pour faciliter la recherche des objets souhaités dans de longues listes, une barre de recherche a été ajoutée aux fenêtres PopupMenu ; des mécanismes de filtrage tels que « Afficher les éléments personnalisés » (Show Custom) ont quant à eux été intégrés aux écrans de création de nouveau nœud ou de ressource (Create Dialog) 1 . Lorsqu'un développeur travaillant dans l'éditeur de code double-clique sur le nom du fichier en haut de la fenêtre de script, l'emplacement du fichier dans le système de fichiers situé à gauche est automatiquement mis en surbrillance (highlighted), ce qui évite de se perdre dans de grands arbres de données 3 . Enfin, dans l'écran Remote Scene Inspector (Inspecteur de scène à distance), les valeurs Enum ne sont plus affichées uniquement sous forme d'entiers dénués de sens (0, 1, 2), mais avec les noms de chaînes (string names) qu'ils représentent dans le code 3 .

Développement mobile, Réalité Virtuelle (XR) et Optimisations de Performance

Alors que la part des appareils mobiles et des casques de réalité virtuelle (plateformes) dans l'industrie du jeu vidéo ne cesse de croître, Godot 4.7 intègre des crochets (hooks) logiciels dédiés répondant aux contraintes matérielles de ces appareils en tant que fonctionnalités standard du noyau.

Intégration d'un VirtualJoystick natif

Les équipes développant des jeux d'action ou de rôle pour les plateformes mobiles dépendaient depuis longtemps de plugins tiers pour les commandes tactiles virtuelles à l'écran ou de codes de saisie (input) écrits de zéro et difficiles à maintenir. Les plugins communautaires risquent de se briser à chaque mise à jour du moteur. Godot 4.7 résout radicalement cette fragmentation en introduisant un nœud VirtualJoystick directement intégré au noyau du moteur1.

Cette intégration prend en charge trois modèles d'interaction différents, parfaitement compatibles avec les schémas de contrôle classiques de la conception de jeux mobiles :

Mode JoystickMécanisme et Comportement de l'UtilisateurScénario d'Utilisation IdéalFixe (Fixed)La position du joystick sur l'écran est fixe. Le joueur doit faire glisser son pouce vers cette zone spécifique de l'écran. Un réglage classique de « zone morte » (dead zone) se trouve en son centre.Portages rétro arcade, contrôleurs fixes de type console1.Dynamique (Dynamic)Dès que le joueur touche une zone désignée de l'écran, le joystick apparaît à cet endroit. Lorsque le doigt est levé, il disparaît instantanément et réinitialise sa position.Jeux de tir (shooter) nécessitant une réactivité rapide1.Suivi (Following)Il commence selon le même principe que le mode dynamique, mais lorsque le pouce du joueur dépasse les limites de mouvement, l'axe central du joystick glisse également pour suivre le doigt, garantissant que le joueur reste constamment en contact.Jeux de rôle (RPG) ou endless runners où le personnage se déplace sans interruption1.

De plus, il est désormais possible de lire les données de l'accéléromètre et du gyroscope provenant des manettes (gamepads) via l'API, ce qui rend stable l'intégration des commandes d'inclinaison et de mouvement offertes par les manettes de jeu mobiles ou de console3.

GABE (Godot Android Build Environment) et développement sur appareil

La vision de Godot – qui ne se limite pas au développement de jeux pour Android, mais pose comme position philosophique le « développement de jeux directement sur des tablettes et appareils mobiles fonctionnant sous le système d'exploitation Android » (Godot Editor for Android) – a fait un bond en avant majeur dans la version 4.7. Grâce à une application compagnon spéciale appelée GABE (Godot Android Build Environment), l'Éditeur Godot fonctionnant sur des appareils Android (par exemple une Samsung Galaxy Tab) dispose directement de la prise en charge de l'exportation Gradle nécessaire pour créer des fichiers APK ou AAB au sein même de l'appareil3. Cela signifie qu'un développeur peut compiler le code qu'il écrit sur l'appareil directement sur celui-ci, sans avoir besoin d'ordinateur, et créer des paquets de version complète (APK)4.

Les contraintes ergonomiques de l'éditeur fonctionnant sur Android ont également été surmontées. La fenêtre de jeu intégrée (embedded game window) à l'exécution n'est plus fixe, mais devient redimensionnable et déplaçable ; ainsi, différents rapports de format d'écran (aspect ratios) tels que les formats paysage, portrait ou tablette peuvent désormais être testés sur un seul et même appareil1. L'écran de rédaction de scripts est devenu pivotable (landscape coding) en réagissant aux capteurs de paysage/portrait de l'appareil, ce qui améliore l'ergonomie lorsqu'un clavier est connecté4. De plus, grâce à la fonctionnalité Picture-in-Picture (Image dans l'image), les processus de test sont devenus beaucoup plus modulaires et le jeu peut être surveillé même lorsqu'il tourne en arrière-plan1. Les options d'exportation ont été élargies afin que les écrans de démarrage (splash screens) des projets Android puissent désormais adopter une structure personnalisable1.

Cependant, il convient d'attirer l'attention à ce stade sur les avertissements de performance émanant de l'écosystème des développeurs. Bien que le moteur 3D de Godot dispose de fonctionnalités avancées, l'utilisation du moteur de compatibilité (Compatibility - GLES3/OpenGL), en particulier sur les appareils mobiles équipés de GPU de milieu de gamme tels que le Mali G68, peut entraîner des limitations de rendu. Des analyses sectorielles (par exemple les rapports de tests Reddit) montrent que sur une scène simple comportant très peu d'objets en arrière-plan et seulement 3 000 polygones, la fréquence d'images peut chuter jusqu'à 38 FPS à moins de réduire l'échelle de résolution16. Par conséquent, les développeurs doivent accorder une importance maximale à l'échelle de résolution de la vue (viewport resolution scale), à la simplicité des matériaux et à la diversité des appareils de test lors du développement de produits 3D destinés à la plateforme Android16.

Réalité Étendue (XR) : Couches de Composition et Rendu Fovéal

L'architecture OpenXR, devenue la norme industrielle sur le marché de la Réalité Virtuelle (VR) et de la Réalité Augmentée (AR), est rendue encore plus orientée vers la production avec Godot 4.72. Alors qu'un support prêt pour la production (production-ready) est fourni pour les plateformes Steam Frame et Android XR, les mappages d'actions OpenXR (action maps) ont été réduits aux quatre profils les plus essentiels afin d'atténuer la complexité des intégrations de contrôleurs1.

Dans les processus de développement VR, la lisibilité de l'interface utilisateur (UI) est le problème ergonomique le plus critique. Placer des affichages tête haute (HUD) ou du texte dans la scène comme de la géométrie 3D standard (eye-buffer rendering) entraîne des textes tremblants, flous et illisibles en raison de la distance focale et de la densité de pixels des lentilles. Le système de couches de composition (composition layer) OpenXR retire les interfaces du tampon (buffer) du monde de jeu standard pour les dessiner directement sur la couche de projection du visuel (sur le projecteur)3.

Godot 4.7 a approfondi le contrôle sur ces couches de composition. Les développeurs peuvent désormais :

• Attacher (lock) et fixer les couches de composition directement au nœud XRCamera3D de la scène, concevant ainsi des écrans HUD ultra-nets qui restent fixes dans le champ de vision sans subir la moindre milliseconde de retard, peu importe la vitesse à laquelle le joueur tourne la tête3.

• Associer (pairing) les objets de la couche de composition à la géométrie du monde (world geometry), laissant ainsi les couches de texte ancrées à des coordonnées spécifiques dans l'espace (world-locked)3.

Dans le contexte des performances graphiques, les casques VR (tels que Meta Quest) sont des appareils aux résolutions gigantesques, et l'économie de chaque milliseconde y est d'une importance vitale pour le confort4. La technologie d'images sous-échantillonnées (Subsampled images) de Vulkan a été intégrée au moteur Mobile de Godot 4.71. Cette technologie réduit de manière spectaculaire la largeur de bande mémoire du GPU (memory bandwidth) en stockant à plus faible densité les pixels traités lors des processus de rendu fovéal (où le centre sur lequel l'œil se focalise est rendu net, tandis que le champ de vision périphérique est rendu à basse résolution)3. On obtient ainsi un gain majeur en termes de performances et de consommation de

batterie des appareils mobiles 1 . Il est recommandé d'utiliser le moteur de rendu Mobile par défaut pour les projets XR 1 .

Philosophie de la Physique et Ensemble d'Outils 2D Avancés

Les systèmes physiques et les algorithmes de collision constituent le cœur comportemental des moteurs de jeu. Avec la version 4.6, Godot avait intégré le plugin haute performance Jolt Physics comme moteur physique 3D par défaut dans l'écosystème de base. Contrairement à certaines rumeurs dans l'industrie, la version 4.7 n'a ni remplacé ni annulé Jolt Physics ; le moteur Jolt maintient sa stabilité en environnement de production en tant que moteur physique par défaut pour les nouveaux projets 3D et l'architecture de 4.7 1 . Cependant, la véritable révolution physique de la version 4.7 s'accomplit en surmontant une limitation fondamentale des architectures de collision 2D.

Liberté de Direction de Collision Unidirectionnelle (One-way Collision)

Dans les jeux de plateforme 2D (tels que Mario ou Hollow Knight, où le personnage peut sauter par en dessous, traverser une plateforme et atterrir dessus comme des nuages ou des ponts de singe), les collisions unidirectionnelles sont un mécanisme fréquemment utilisé. Avant Godot 4.7, le moteur physique supposait de manière rigide et inchangeable que le vecteur de collision unidirectionnelle pointait vers le « Haut » (Up) local propre au nœud CollisionShape2D concerné (vecteur 0, -1) 3 . Lorsque les concepteurs de jeux voulaient modifier la direction de la collision (par exemple un mur que le personnage peut traverser par la droite mais contre lequel il entre en collision par la gauche), ils devaient recourir à des astuces douloureuses (painful) telles que faire pivoter la structure physique ou la rotation du collisionneur (collider) totalement indépendamment des nœuds graphiques visuels et synchroniser ces deux structures 3 .

Avec la mise à jour 4.7, une nouvelle variable nommée one_way_collision_direction (direction de collision unidirectionnelle) a été ajoutée à la classe CollisionShape2D 3 . Grâce à cette fonctionnalité, le vecteur de direction des interactions unidirectionnelles peut être assigné librement dans un espace local à 360 degrés, sans jamais altérer la géométrie globale de la forme de collision (structure de boîte ou de capsule) 3 . Cette situation libère le codage des courants de vent violents, des bandes transporteuses poussant le personnage, des zones de gravité inclinées ou des mécanismes de glissement depuis les plates-formes des calculs de rotation superflus, les rendant beaucoup plus élégants et mathématiquement corrects.

### Lissage CSG Dynamique (Autosmooth)

La Géométrie de Solide Constructif (Constructive Solid Geometry - CSG) est un outil qui permet aux concepteurs de jeux d'effectuer du prototypage instantané de niveaux 3D directement dans le moteur en utilisant des formes géométriques simples qui s'intersectent (cube, sphère, cylindre) via des opérations d'union, de soustraction et d'intersection, sans avoir besoin de programmes de modélisation 3D externes tels que Blender ou Maya 3 . Cependant, les sols CSG générés ont toujours semblé tranchants, peu polygonaux et rugueux.

La nouvelle fonction Autosmooth (Lissage automatique) ajoutée aux nœuds racines CSG de Godot 4.7 rend ces structures polygonales anguleuses lisses de manière procédurale au niveau matériel 3 . Le paramètre d'angle de lissage (Smoothing Angle) est réglé par défaut sur 50 degrés ; les jonctions de surfaces inférieures à ce seuil sont automatiquement traitées comme des surfaces lisses (smooth faces), tandis que les intersections plus raides et à angle élevé continuent de préserver leurs arêtes vives (sharp faces) 3 . Plus la valeur est augmentée, plus un profil de lissage agressif est appliqué ; cette fonctionnalité permet non seulement aux équipes faisant du prototypage, mais aussi aux studios produisant du low-poly (faible nombre de polygones), d'importer leurs structures CSG directement dans leurs jeux avec une qualité de produit final (final asset) 3 .

Modifications d'API, Scripting et

Stratégies de Migration Chaque mise à jour mineure d'une version .x (minor release), tout en ajoutant de nouvelles fonctionnalités, modifie certaines signatures d'API (Interface de Programmation d'Application) afin d'accroître les performances du moteur en arrière-plan et comporte des changements cassants (breaking changes) au niveau du code 3 . Bien que la philosophie fondamentale de Godot 4.7 soit de préserver la rétrocompatibilité, il existe une hiérarchie de migration stricte que les développeurs doivent prendre en compte lors de la mise à jour de leurs projets 4.6 (ou plus anciens) existants.

La méthodologie la plus vitale du processus de migration consiste à ne jamais ouvrir directement le répertoire actuel du projet sur lequel on travaille activement avec la nouvelle version 4.7 du moteur, mais plutôt à ouvrir une nouvelle branche de test sur le système de contrôle de version du projet (VCS - ex. Git) ou à faire une copie complète de l'ensemble du dossier 1 . Lorsque l'éditeur ouvre le projet pour la première fois au format 4.7, il réécrit de zéro tous les processus d'importation de textures, de textes et de modèles (import pipeline) ; cette opération étant irréversible, l'isolation prévient les pertes de données critiques et les dommages à la rétrocompatibilité 13 .

Nouveautés en Matière de Programmation et d'Écriture de Scripts

GDScript, le langage de script dynamique propre à Godot, s'est renforcé du côté du contrôle de flux et de l'intégration système dans la version 4.7 :

1. Implémentation des Interfaces Java : Auparavant, pour accéder au matériel spécifique des appareils Android (API caméra, capteurs spéciaux ou systèmes de paiement), il était nécessaire d'écrire des plugins intermédiaires en C++ ou en Java. Avec la version 4.7, GDScript a acquis la capacité d'intégrer directement les interfaces Java depuis le moteur, allégeant considérablement le besoin de plugins externes 1 .

2. Mise en Pause de Tween (tween_await) : Le système Tween, utilisé pour créer des animations basées sur le code, peut désormais suspendre (pause) son propre temps d'exécution en appelant une fonction tween_await() jusqu'à ce qu'un signal provenant d'un autre objet du système soit déclenché. Cette fonctionnalité représente une facilité immense pour créer des chaînes d'animations asynchrones (asynchronous) 1 .

Pour les utilisateurs de C# (.NET), le système structurel est préservé. Godot 4.7 continue de proposer deux distributions binaires exécutables distinctes : « Standard » (qui prend en charge C++ via GDScript et GDExtension) et « .NET » (qui prend en charge C# et nécessite le SDK .NET) 1 . Si un projet basé sur C# par le passé est ouvert avec le nouveau moteur Standard, les scripts ne compileront pas et cela entraînera des dysfonctionnements ; il est donc essentiel de télécharger la version correcte 1 .

Tableau des modifications cassantes (Breaking Changes) en vedette

Le tableau suivant résume les modifications essentielles qui affectent les structures de code existantes, les types de données et les appels d'API lors du passage de Godot 4.6 à Godot 4.7, nécessitant ainsi un refactorisation (nettoyage du code) :

Classe concernée / Caractéristique du systèmeMéthode modifiée / État de modification et description détailléeÉtat de compatibilité de l'architecture (GDScript / C#)Object (Noyau - Core)is_class() Le type du paramètre class est passé du type String général au type StringName, beaucoup plus rapide au niveau C++ et utilisant une mémoire statique18. Améliore les performances lors des requêtes d'objets.GDScript : Compatible.
C# : Compatible au niveau binaire et source.ZIPPacker (Noyau)start_file() Deux nouveaux paramètres nommés permissions (autorisations de fichiers) et modified_time (heure de modification) ont été ajoutés à l'API pour plus de sécurité18.GDScript : Compatible.
C# : Compatible au niveau binaire et source.OptimizedTranslationgenerate() Afin que la fonction de localisation puisse signaler l'état de réussite, le type de valeur de retour est passé de vide (void) à booléen (bool)18.GDScript : Compatible.
C# : Incompatible au niveau binaire, compatible au niveau source.GPU/CPUParticles2D et 3Drequest_particles_process() Le paramètre process_time_residual a été ajouté pour affiner les simulations de particules afin d'accroître la précision physique18.Compatible pour tous les langages.Control (Interface - GUI)accessibility_live Les fonctionnalités d'accessibilité telles que les lecteurs d'écran ont été rendues indépendantes du serveur d'affichage graphique (DisplayServer) et déplacées vers leur propre type AccessibilityServer.AccessibilityLiveMode18.GDScript : Compatible.
C# : Totalement incompatible (refactorisation manuelle requise).RichTextLabel (Interface)Constant (Constante) Enum Le nom de la variable ImageUpdateMask.UPDATE_UPDATE_WIDTH_IN_PERCENT, qui est le paramètre de définition de la largeur, a été mis à jour en ImageUpdateMask.UPDATE_WIDTH_UNIT, ce qui correspond mieux à la structure logique18.GDScript : Incompatible.
C# : Incompatible au niveau binaire et source.RichTextLabel (Interface)add_image() / update_image() Les paramètres width et height sont passés du type Entier (int) au type Nombre décimal (float) afin d'offrir une flexibilité de dimensionnement et de prendre en charge des échelles relatives décimales telles que 1em18.Compatible pour tous les langages.

Procédures de validation et de test après la mise à jour

Une fois le projet ouvert avec succès dans l'environnement 4.7 sur le système de contrôle de version, même si la compilation est effectuée, les modules spécifiques doivent passer par des tests de régression à l'exécution (runtime) :

1. Hiérarchie de l'interface (UI) : Étant donné que la nouvelle dynamique de offset_transform peut affecter les algorithmes de calcul de certains agencements de nœuds parents-enfants imbriqués de longue date, des barres de défilement (scroll views) ou des menus contextuels (popup menus), le menu principal, l'inventaire et les écrans de paramètres (HUD) doivent être testés de bout en bout 1 .

2. Expression de matériau et canal de rendu : Des décalages de couleur (color shifting), des fuites de lumière ou des différences d'ombrage peuvent être observés sur les apparences de matériaux PBR en raison de la transition de la plage dynamique standard (SDR) vers les canaux de rendu prenant en charge le HDR inclus dans l'environnement et de l'algorithme de vernis (clearcoat) ; toutes les structures d'éclairage doivent être validées 1 .

3. Paramètres Android et profils XR : Dans les préréglages d'exportation (export presets), les écrans de démarrage (splash) Android, les modifications de la mise en paquets des données OBB et les mappages d'actions OpenXR (action maps), réduits à quatre profils de base simplifiés, doivent être validés à partir de zéro 1 .

4. Extensions C++ GDExtension : Si les bibliothèques (GDExtensions) utilisées dans le projet et liées (bind) au code source C++ du moteur n'ont pas été mises à jour pour prendre en charge la nouvelle signature d'API de Godot 4.7, le moteur risque de planter. Avant la mise à niveau, les extensions inutiles doivent être désactivées et il convient de confirmer sous les Paramètres du projet que chaque extension a été chargée avec succès 1 .

Conclusion

La version 4.7 de Godot s'éloigne de la philosophie marketing consistant simplement à « ajouter des fonctionnalités médiatiques » à un moteur de jeu, pour s'affirmer comme une mise à jour d'ingénierie mature qui cible systématiquement les douleurs chroniques des cycles de production de jeux professionnels 4 . Comme le montrent clairement les analyses de l'industrie et des centres de communautés indépendantes tels que Reddit, une stabilité et une praticité de production capables de répondre aux attentes des développeurs migrant de moteurs établis comme Unity ont été atteintes 8 .

Alors que AreaLight3D et l'intégration d'images HDR prouvent la compétence du moteur dans la visualisation architecturale et les projets photoréalistes 3D de haute qualité, l'inclusion de l'infrastructure de Traçage de Rayons (Ray Tracing) matérielle au cœur du système symbolise la préparation stratégique du moteur aux normes visuelles de l'avenir 2 . D'autre part, les transformations de décalage dans les nœuds Control ont éliminé le problème de la « rupture de mise en page », l'un des plus grands cauchemars des développeurs d'interface utilisateur ; et les intégrations de VirtualJoystick et GABE ont mis fin à la dépendance externe (aux extensions) pour le marché mobile 1 . Les limites de performances sur le matériel XR ont également été maximisées grâce aux systèmes d'images sous-échantillonnées (subsampled images) Vulkan prenant en charge le rendu fovéal (foveated rendering) 1 .

Façonné par la philosophie de l'open source et le travail de centaines de contributeurs, le moteur Godot présente avec la version 4.7 la variante la plus stable, la plus conviviale pour les développeurs (developer-friendly) et la plus exploitante des capacités du matériel moderne de toute la génération 4.x

Une stratégie de transition de version (migration) isolée, réalisée en tenant compte des modifications d'API détaillées, des limites de compatibilité et des procédures de test des projets existants, élèvera incontestablement la vitesse de production (iteration time) des studios de développement, les coûts de maintenance des produits et la qualité graphique du jeu aux yeux de l'utilisateur final.

*Information : Les visuels ont été générés par Google Gemini.