Pour mieux comprendre les raisons de cette décision, il faut remonter l'histoire de VisualScript. En effet, selon l’équipe de Godot, le script visuel était l’une des fonctionnalités les plus demandées à l’époque de Godot 2.1. Et pour mieux répondre à cette demande, les mainteneurs du projet ont effectué un sondage afin de déterminer quel type de script visuel les utilisateurs souhaitaient avoir. À la suite du sondage, le style Blueprint a été celui le plus mentionné. Avec ces informations, VisualScript a été créé et publié pour Godot 3.0. Il a été implémenté à la manière de GDscript, mais avec un style graphique et basé sur des nœuds.
Toutefois, bien que cette fonctionnalité ait été fortement demandée à l’époque, cela ne signifiait pas qu’il était nécessaire pour des projets réels du moteur et que beaucoup d’utilisateurs allaient effectivement l’adopter. Et cette réalité, l’équipe de Godot l’a apprise à ses dépens. Après maintenant presque cinq ans qu’il a été ajouté à Godot 3, VisualScript n’a pas connu le succès escompté. En essayant de comprendre les raisons de cet échec, l’équipe de Godot a obtenu deux réponses principales :
- Pour de nombreux utilisateurs potentiels qui souhaitaient cette fonctionnalité, ils ont découvert que GDScript convenait parfaitement et ils ont fini par le préférer à VisualScript. Ils ne s’attendaient pas à trouver GDScript aussi facile à apprendre et à utiliser (même s’ils n’avaient pas de connaissances préalables en programmation), étant donné qu’aucun des moteurs populaires de l’époque n’offrait ce type de script de haut niveau. Pour beaucoup de ces utilisateurs, Godot a fini par être un outil pour apprendre la programmation à la place ;;
- Même si la fonctionnalité de base, le script visuel, était là, Godot manquait de composants de haut niveau pour l’utiliser. Des moteurs comme Unreal, Game Maker ou Construct offrent des fonctionnalités de jeu de haut niveau associées à la solution de script visuel. C’est ce qui le rend utile. Godot est un moteur de jeu extrêmement polyvalent où il est facile de créer ces fonctionnalités vous-même, mais elles ne sont pas prêtes à l’emploi. En tant que tel, VisualScript en lui-même était de peu d’utilité, reconnaît l’équipe de Gotdot.
À ces deux réponses, l’équipe de Godot en a ajouté une troisième issue de ses observations personnelles. Selon les mainteneurs du moteur de jeu, la documentation n’a pas suivi. En effet, la documentation officielle de Godot contient des exemples en GDScript et C#, mais les développeurs du projet n’ont jamais réussi à inclure des exemples de VisualScript pour des raisons techniques. La raison avancée est qu’il faudrait faire des captures d’écran des graphiques VisualScript pour chaque exemple et les maintenir serait très difficile. Par ailleurs, bien que quelques projets de démonstration étaient en réflexion, cela ne suffisait pas pour permettre aux utilisateurs de maîtriser un langage, même visuel - et pour apprendre l’API de Godot, ils devraient se familiariser avec GDScript ou C # pour comprendre les exemples, avance l’équipe derrière Godot.
Toutes ces difficultés ont fait que VisualScript n’a jamais gagné en popularité et la voie pour l’améliorer n’a jamais été claire. Selon un récent sondage mené par l’équipe de développement du projet, le plus récent (avec plus de 5000 répondants), seulement 0,5 % de la base d’utilisateurs a utilisé VisualScript comme langage de moteur principal.
Au vu des résultats de ce sondage, il n’est pas étonnant pour l’équipe de constater que pour à peu près toutes les fonctionnalités implémentées dans Godot, des retours d’expérience des utilisateurs étaient reçus via des problèmes ou des propositions. Mais pour ce qui concerne VisualScript, quasiment aucun retour n’a été reçu pour l’améliorer de manière significative. La conclusion qui s’est imposée de manière inéluctable est que l’approche adoptée pour les scripts visuels n’était tout simplement pas la bonne. Cette fonctionnalité semble avoir été demandée par des personnes qui n’en avaient pas vraiment besoin. Plusieurs utilisateurs de Godot se réjouissent de cette décision, car pour eux VisualScript n’a jamais été très bon et même pour un débutant complet, il est loin d’être aussi facile à utiliser que GDScript. En outre, de nombreux utilisateurs d’autres moteurs de jeu comme Unity ou Unreal Engine trouvent le choix d’un langage non standard très rebutant. Et même parfois plus que celui de revenir aux cauchemars que donne C++ en travaillant avec Unreal Engine.
Pour toutes ces raisons, l’équipe de Godot annonce que pour la version 4.0 du moteur de jeu, VisualScript sera supprimé de la base de code. À ne surtout pas confondre avec les shaders visuels. Les shaders visuels fonctionnent bien et sont appréciés par de nombreux utilisateurs, ils continuent d’être développés dans le moteur. Pour les utilisateurs qui souhaitent continuer à utiliser VisualScript dans le moteur de jeu, deux options s’offrent à eux. Soit, ils restent sur la version 3.x ou soit ils compilent le code pour l’utiliser dans la version 4.x ou supérieure, d'autant plus qu'il sera déplacé vers un référentiel dédié. Une dernière option serait de trouver des bénévoles intéressés par ce projet afin de le convertir en une extension officielle, ce qui permettrait de la maintenir facilement.
Source : Godot
Et vous ?
Quels commentaires faites-vous de cette décision ;?
Utilisez-vous un langage de script visuel avec votre moteur de jeu ;? Lequel ? Et pourquoi ;ce choix ?
Voir aussi
Le moteur de jeux vidéo libre et multiplateforme Godot est disponible en version 3.5
Le moteur de jeux vidéo libre et multiplateforme Godot est disponible en version 3.4
Le moteur de jeux vidéo Godot reçoit 250 000 dollars de la part d'Epic Games
Le moteur de jeux Godot intègre un éditeur graphique de shaders