Mise à jour Godot 4.1

 (godotengine.org)
1 points par GN⁺ 2023-07-07 | 1 commentaires | Partager sur WhatsApp
  • Godot 4.1 est une version incrémentale publiée quatre mois après la 4.0, qui affine la stabilité, les performances et le niveau de finition tout en ajoutant des fonctionnalités comme l’évitement pour la navigation IA et un éditeur de code détachable
  • Cette version corrige plus de 900 problèmes signalés lors de l’utilisation de Godot 4 ou découverts dans les préversions de 4.1, et repose sur les contributions de plus de 300 personnes
  • Les gains de performance viennent surtout du passage de l’ajout et de la suppression de nœuds enfants à une approche fondée sur une hashmap rapide ; cela accélère les projets complexes, au prix de quelques opérations rares et d’une hausse de l’utilisation mémoire de Node
  • Variables statiques GDScript, [GlobalClass] en C#, extensions GDExtension, éditeur de scripts détachable : les workflows de scripting et d’édition s’élargissent
  • La migration des projets 4.0 vers 4.1 est globalement sûre, mais les utilisateurs de C# et de GDExtension doivent d’abord vérifier les éventuelles incompatibilités ainsi que le portage et la recompilation nécessaires

Vue d’ensemble de la sortie de Godot 4.1

  • Godot 4.1 est une mise à jour issue de 4 mois de travail depuis Godot 4.0, dans la continuité de l’objectif d’améliorer la 4.0 par des versions incrémentales fréquentes
  • Cette version met l’accent sur la stabilité, les performances et la qualité de finition, tout en incluant de nouvelles fonctionnalités
    • Évitement amélioré pour la navigation IA
    • Possibilité de détacher l’éditeur de code pour le placer sur un autre écran
  • Plus de 900 problèmes signalés par les utilisateurs de Godot 4 ou trouvés lors des tests des préversions de 4.1 ont été corrigés
  • La plupart des jeux et applications créés avec la 4.0 peuvent migrer vers la 4.1 de façon relativement sûre
    • Les utilisateurs de C# et de GDExtension doivent s’attendre à quelques incompatibilités
    • Avant la migration, une sauvegarde est nécessaire, et il est recommandé de valider l’état du projet dans un système de gestion de versions comme Git
    • Un guide de migration est en préparation
  • Godot 4.1 est disponible sur la page de téléchargement

Contributions de la communauté et financement du développement

  • Godot est un projet porté par sa communauté, où des contributeurs individuels participent à l’amélioration du moteur
  • Ces dernières années, les dons d’utilisateurs et d’entreprises ont permis d’employer à temps plein certains contributeurs clés, ce qui a rendu possibles des sorties plus rapides
  • Les dépenses mensuelles actuelles dépassent les dons mensuels, si bien que le financement du développement dépend encore de dons ponctuels importants de la part d’entreprises
  • Pour maintenir le rythme des mises à jour de Godot 4 et recruter davantage de mainteneurs capables de relire plus de contributions, davantage de dons mensuels sont nécessaires
  • Au-delà du soutien financier, il existe plusieurs façons de contribuer au projet
    • Rédiger des rapports de bug détaillés
    • Contribuer à la base de code
    • Rédiger de la documentation
    • Écrire des guides dans la documentation officielle ou sur des sites personnels
    • Répondre aux questions et partager des astuces sur les plateformes communautaires
  • Cette version a été réalisée grâce aux contributions de plus de 300 personnes, et la liste complète des corrections de bugs et améliorations est disponible dans l’interactive changelog

Améliorations des performances

  • Les jeux Godot sont construits sous forme d’arbre de nœuds, composant de base des entités de jeu, et l’ajout ou la suppression de nœuds est une opération très fréquente dans le moteur
  • Dans la 4.1, l’algorithme d’ajout et de suppression de nœuds enfants a été remplacé par une approche fondée sur une hashmap rapide, rendant ces opérations plusieurs fois plus rapides
    • Certaines opérations rares sur les nœuds deviennent légèrement plus lentes
    • L’utilisation mémoire de la classe Node de base augmente de 10 %
    • Les projets complexes qui manipulent beaucoup de nœuds en tirent un bénéfice particulièrement important
  • Un multithreading expérimental a été ajouté pour les scènes
    • Une nouvelle propriété de nœud permet de contrôler si le traitement des nœuds se fait de manière séquentielle ou parallèle
    • Comme il s’agit encore d’une fonctionnalité expérimentale, elle nécessite des tests étendus pour identifier les cas limites
    • Son utilisation en production n’est pas recommandée
  • De nombreux problèmes et limitations ont également été corrigés dans le chargement multithread
  • Un cache de pipelines a été ajouté au renderer Vulkan
    • Le cache de shaders existant réduisait les saccades liées à la compilation des shaders, mais la compilation des pipelines pouvait encore provoquer des saccades et des temps de chargement longs
    • Les saccades dues à la compilation des pipelines ne sont pas totalement résolues, mais les temps de chargement peuvent être légèrement réduits avec les backends de rendu basés sur RenderingDevice
    • Ce cache peut être désactivé dans les paramètres du projet et est activé par défaut dans Godot 4.1
    • Il ne résout pas toutes les causes de blocage, et le travail se poursuivra dans les prochaines versions

Changements du moteur cœur

  • Lors de l’import de modèles dans Godot, il arrivait souvent que le modèle soit orienté vers l’arrière
  • Plusieurs changements ont été apportés dans la 4.1 pour réduire ce problème
    • Les directions avant/arrière de la caméra ont été inversées dans l’éditeur
    • Un argument a été ajouté à la fonction look_at() pour utiliser l’espace du modèle comme référence d’orientation vers l’avant, plutôt que l’axe -Z de la caméra
    • Ce changement aide aussi à corriger un ancien bug de suivi de chemin
  • Un lissage du delta de frame a été ajouté à Godot 4
    • Il peut améliorer fortement la fluidité des mouvements et offrir un gameplay plus fluide
    • Il est activé par défaut
    • Il ne fonctionne que lorsque VSync est activé

Améliorations du scripting

  • GDScript

    • Jusqu’ici, pour partager des données entre plusieurs instances d’un même script, il fallait utiliser des ressources ou un autoload
    • À partir de Godot 4.1, il est possible de créer et d’utiliser des variables statiques
    • Les variables statiques stockent les données dans la classe, et non dans chaque instance, et toutes les instances d’une même classe partagent leur valeur
    • Elles s’utilisent en ajoutant le mot-clé static devant la définition d’une variable au niveau supérieur du script
    • La génération automatique de documentation pour les classes nommées, ajoutée dans Godot 4, a également été améliorée
    • Les énumérations sont traitées comme des types, ce qui rend la documentation générée plus précise
    • En plus des docstrings placées uniquement au-dessus des définitions de variables ou de fonctions, les docstrings inline sont désormais possibles

  • C#/.NET

    • Pour cette version, l’accent côté C# est mis sur un meilleur alignement fonctionnel avec GDScript
    • En GDScript, il était possible d’ajouter un nom de classe global à un script pour définir un nouveau type de nœud utilisable dans l’éditeur
    • À partir de Godot 4.1, la même chose est possible en C# en ajoutant l’attribut [GlobalClass] à un fichier
    • L’attribut [Icon] permet aussi d’assigner une icône propre à une classe globale
    • Toutefois, à la 4.1, les projets créés en C# ne peuvent pas encore être exportés vers les plateformes mobile et web
    • Le travail de prise en charge est en cours
    • La résolution de cette limitation dépend probablement de la sortie de .NET 8 fin 2023
    • Les travaux sur la prise en charge du mobile et du web ne pourront vraisemblablement vraiment commencer qu’au second semestre 2023

  • GDExtension

    • Godot fournit une technologie permettant d’utiliser des langages bas niveau comme C++ comme langage de scripting de jeu, sans recompiler le moteur
    • GDExtension reste encore en bêta dans cette version
    • Dans la 4.1, les capacités de scripting de GDExtension se rapprochent davantage de celles de GDScript et C#
    • Il est possible d’implémenter de nouveaux nœuds de shader visuel
    • Il est possible de créer des plugins d’éditeur avec GDExtension
    • Un système de compatibilité ascendante a été implémenté pour aider le code destiné à Godot 4.1 à continuer de fonctionner malgré de futurs changements d’API
    • Cependant, la correction de problèmes fondamentaux de GDExtension a nécessité d’importantes ruptures de compatibilité en 4.1
    • Les extensions Godot 4.0 existantes doivent être portées et recompilées pour la 4.1
    • Beaucoup de travail architectural a aussi été repris pour rendre l’API GDExtension extensible à l’avenir

Workflow de l’éditeur

  • Godot 4 prenait déjà en charge plusieurs fenêtres pour les paramètres du projet, les paramètres de l’éditeur et diverses fenêtres contextuelles
  • À partir de la 4.1, la documentation peut être détachée dans une fenêtre flottante, et l’éditeur de scripts, y compris l’éditeur de shaders, peut aussi être détaché pour être placé sur un écran séparé
  • L’éditeur suit la disposition des fenêtres afin de conserver l’emplacement de travail précédent lors de la fermeture puis de la réouverture
  • Godot 4.0 prenait en charge la définition et l’export de tableaux typés ainsi que l’export dans l’inspecteur de nœuds individuels, mais il n’était pas possible de combiner les deux
  • À partir de Godot 4.1, les tableaux de nœuds peuvent être exportés dans l’inspecteur, ce qui facilite la connexion des objets de jeu entre eux
  • Le gestionnaire de projets ajoute la possibilité d’attribuer des tags à chaque projet et de filtrer par tag
    • Cela facilite la recherche parmi des dizaines, voire des centaines, de projets Godot

Changements de rendu

  • La turbulence des particules a été retravaillée à partir des retours d’artistes, offrant davantage de contrôle créatif
  • La turbulence est largement utilisée pour créer les effets riches et diffus que l’on voit dans les jeux modernes
  • Une nouvelle texture de bruit 3D permet de contrôler facilement la densité du brouillard volumétrique
    • Elle permet de rendre le brouillard plus léger dans certaines zones
  • NoiseTexture3D peut aussi servir à créer des champs vectoriels d’attracteurs de particules
    • C’est utile pour simuler du vent influençant les particules
  • De nombreuses améliorations sont encore prévues pour le renderer de Godot, et la plupart arriveront dans de prochaines versions
  • L’équipe rendu et les contributeurs donnent la priorité aux corrections de bugs et à la stabilité plutôt qu’aux nouvelles fonctionnalités
  • Le renderer 3D GLES3 n’est pas encore terminé, et un travail important est prévu dans les prochains mois

Améliorations de la navigation

  • Godot 4.0 a introduit l’évitement en temps réel pour la navigation IA, mais celui-ci était limité à un seul plan
  • Godot 4.1 inclut un algorithme d’évitement entièrement réécrit
    • Il offre un meilleur comportement et davantage de contrôle
    • L’évitement peut désormais fonctionner en 2D ou en 3D
    • Les agents volants peuvent passer au-dessus des agents marchant au sol
  • Les couches permettent de contrôler quels agents doivent éviter quels autres agents
  • Des priorités peuvent être définies afin que certains agents repoussent les autres
  • Le comportement de navigation amélioré est présenté dans la documentation mise à jour

Prise en charge des plateformes et contraintes web

  • Le périmètre de prise en charge des plateformes de Godot 4.1 est identique à celui de Godot 4.0
  • Les exports vers toutes les plateformes desktop sont possibles avec le moteur standard comme avec la version .NET
  • Si un projet n’utilise pas C#, il peut être exporté vers mobile et web
  • À la 4.1, l’export web présente certaines limitations dues à l’insuffisance de prise en charge par les fournisseurs pour certaines fonctionnalités modernes
    • Des problèmes surviennent dans les navigateurs dont la prise en charge de WebGL 2 est médiocre, comme Chrome sur macOS
    • Ils seront difficiles à résoudre sans correctif de Google ou sans effort important pour prendre en charge un renderer WebGL 1 / GLES2 dédié
  • La configuration des jeux web est complexe sur les plateformes d’hébergement qui ne permettent pas de définir les en-têtes CORS nécessaires à la prise en charge de SharedArrayBuffer
    • Ce problème dépend surtout de l’implémentation de l’en-tête coep:credentialless dans Safari
    • Les navigateurs basés sur Chromium et Firefox fonctionnent déjà correctement
    • Cela fonctionne particulièrement bien pour les déploiements sur itch.io
    • Des contournements possibles sont à l’étude

Problèmes connus et prochaine version

  • Godot 4.1 conserve quelques problèmes qui n’ont pas pu être résolus avant la sortie
  • Le suivi des bugs est disponible dans les issues GitHub de Godot
  • L’un des principaux problèmes connus concerne une nouvelle API permettant de définir des propriétés de configuration personnalisées pour les presets d’export, qui ne conserve pas la configuration utilisateur
    • Après le redémarrage de l’éditeur, les options de configuration sont réinitialisées et disparaissent
    • Le correctif est prévu pour la 4.1.1
    • La PR associée est GH-79025
  • Le travail sur Godot 4.2 a déjà commencé, avec une sortie prévue dans 4 mois
  • Godot entend conserver un cycle de sorties stable afin d’éviter une trop longue attente pour les prochaines améliorations et nouvelles fonctionnalités

À lire aussi

1 commentaires

 
GN⁺ 2023-07-07
Avis de Hacker News

  • Je suis récemment passé presque entièrement de Unity à Godot 4.0 et, même si je ne suis pas développeur de jeux professionnel, pour créer de petits jeux indés / du genre itch.io, j’en suis vraiment satisfait
    C’est léger, rapide, facile à apprendre, et ça permet de faire 90 % de ce dont un développeur solo/indé a besoin
    Cela dit, je n’ai pas encore pu abandonner complètement Unity à cause d’un bug qui fait que, quand les utilisateurs macOS ouvrent le jeu sur itch.io, le chargement prend tellement longtemps qu’ils pensent que c’est cassé et ferment l’onglet
    Les jeux que je crée sont souvent éducatifs ou destinés à des enfants qui utilisent des iPad/MacBook ; donner un lien itch.io est donc beaucoup plus simple que d’expliquer une installation locale et de convaincre le propriétaire de l’appareil
    D’après l’équipe Godot, c’est en cours de résolution, mais d’ici là je dois continuer à utiliser Unity pour certains projets. Une fois ce problème réglé, je pense que Godot pourrait vraiment décoller du côté itch.io / game jams

    As of 4.1 web exports still have some limitations due to poor vendor support of certain modern features. Browsers with bad WebGL 2 support, such as Chrome on macOS, unfortunately suffer from issues which we cannot address without a fix from Google or a significant amount of effort put into supporting a dedicated WebGL 1 / GLES2 renderer.
    We are also aware of the complexity setting up web games on hosting platforms which don’t let you set the required CORS headers for SharedArrayBuffer support. This mostly depends on Safari implementing the coep:credentialless header support, while Chromium-based browsers and Firefox already work fine (especially if you publish on itch.io). There is a possible workaround that we are investigating.

    • J’étais dans une situation similaire, puis j’ai fini par réaliser que Godot 3.5.2 est encore la version à support long terme et que ses exports web fonctionnent très bien. L’exemple qui m’a décidé à faire la transition est ici : https://yet-another-lucas.github.io/plumbing-adventure/
      Depuis, je suis passé de Godot 4.0 C# à Godot 3.5.2 + GDScript, et j’en suis satisfait
      J’ai aussi mis en place un pipeline CI/CD qui build et déploie automatiquement sur Github Pages à chaque commit sur master ; ce genre de pipeline est plutôt agréable
      https://www.reddit.com/r/godot/comments/q25riu/hosting_on_gi...
    • Cette année, j’ai créé avec Godot 3.5 cinq petits jeux jouables dans le navigateur, dans l’esprit game jam[1], et l’expérience a globalement été bonne. En attendant que l’export web de Godot 4 fonctionne correctement, on peut très bien se satisfaire de Godot 3.5
      Godot 4 apporte des améliorations du langage que j’attends avec impatience, comme un meilleur support des types et des changements qui réduisent l’usage des chaînes magiques, par exemple la possibilité de référencer les signaux par leur nom
      Mais si c’est un gros obstacle, il vaut peut-être mieux attendre
      Je trouve parfois frustrant que l’équipe Godot 4 considère le problème macOS comme un bug de Chrome plutôt que comme une régression de Godot[2]
      C’est surtout une question de sémantique et de priorités, mais si une fonctionnalité dont on dépendait dans Godot 3 est cassée dans Godot 4, il est difficile de ne pas y voir une régression
      Cela dit, je suis très reconnaissant pour tout le travail réalisé sur Godot 4 et les versions précédentes, et j’ai hâte de pouvoir utiliser Godot 4 un jour
      [1] Pour les curieux, ils sont tous sur https://eieio.games/
      [2] https://github.com/godotengine/godot/issues/70691
    • La formule « navigateurs avec un mauvais support de WebGL 2, comme Chrome sur macOS » me saute aux yeux
      Je n’ai jusqu’ici jamais rencontré de problème WebGL2 avec Chrome/macOS, donc je me demande de quels problèmes précis il s’agit
      Cela dit, moi aussi j’évite les fonctionnalités WebGL2/GLES3 connues pour poser problème. Il s’agit surtout des uniform buffers, ou de certains schémas de mise à jour de buffers qui fonctionnent bien en natif mais pas en WebGL, comme le « buffer orphaning »
    • Je me demande quel est l’état du support VR de Godot. J’ai utilisé UE4 pendant 9 ans et je n’aime pas vraiment Unity, mais j’aimerais bien essayer Godot
    • Je crée des jeux avec Godot sur macOS et je les publie sur itch.io, mais je n’ai jamais rencontré ce problème. Tu peux donner un exemple où le problème se produit, ainsi que les infos de configuration de l’export du build ?

  • Godot est vraiment un outil impressionnant. Si j’ai une raison de lancer un nouveau projet de jeu, j’aimerais l’apprendre plus sérieusement ; vu ce qu’ils ont accompli avec une équipe relativement petite, Unity aurait presque de quoi rougir
    Le fait d’avoir « corrigé plus de 900 problèmes signalés pendant l’utilisation de Godot 4 et les tests des préversions de 4.1 » est également impressionnant
    Corriger autant de problèmes tout en améliorant les performances et la stabilité mérite en soi des éloges

    • Corriger 900 problèmes est clairement impressionnant, mais Godot est probablement l’un des dépôts avec le plus d’issues ouvertes sur GitHub. Il y en a encore plus de 5 000 ouvertes
      Bien sûr, le nombre d’issues ouvertes n’est pas un bon indicateur de la qualité d’un logiciel

  • J’aime Godot, mais il y a quelques points qui me laissent sur ma faim. GDScript n’est pas Python, et il lui manque les petites fonctionnalités qui rendent Python agréable, comme les compréhensions de listes/dictionnaires, .items(), les ensembles, etc.
    Cela dit, pour le développement de jeux, c’est suffisant, et comme il s’intègre bien à l’environnement, avec les types natifs notamment, c’est un langage plutôt bon.
    J’ai essayé GDNative et je dois encore utiliser davantage GDExtension, mais jusqu’ici, écrire du C++ pour Godot m’a paru assez rugueux. Le programmeur doit utiliser les types Godot et new() un peu partout, ce qui n’est pas très pratique.
    Du coup, Godot ressemble moins à un véritable moteur C++ qu’à un moteur où l’on utilise la plupart du temps un langage de script, puis où l’on optimise en C++ seulement quand le script n’est pas assez rapide.
    J’aimerais aussi vérifier à quel point GDScript est réellement rapide par rapport à d’autres langages, et je ne sais pas non plus si Mono/.NET est plus rapide. J’aime le fait que ce soit un langage parfaitement intégré à la conception de l’environnement, mais je me demande s’il y a des plans pour l’améliorer.
    Je prévois de créer un FPS multijoueur, et Godot ne semble pas fournir de prédiction réseau ; j’aimerais qu’il le fasse.
    Le support d’OpenGL à l’avenir m’inquiète aussi. Ce n’est pas encore complètement terminé, et je crains qu’il soit difficile à implémenter correctement, tant il diffère des nouvelles API comme Vulkan ou DX12.
    Globalement, Godot est ce qui est arrivé de mieux à l’open source et au développement de jeux. Le développement de jeux était un domaine où l’open source avait du mal à s’imposer, et la conception légère de Godot est un vrai soulagement par rapport à d’énormes outils comme Unreal ou Unity.

    • C’est aussi le plus gros problème de Godot. Mais pas parce que GDScript n’est pas Python : le problème est que ce n’est pas un langage généraliste. C’est d’ailleurs presque la seule chose qui me manque de Unity.
      Évidemment, je ne choisirais probablement pas Python directement ; même si c’est un langage que j’aime, je prendrais sans doute un langage davantage axé sur les performances. Go pourrait être un bon choix.
      GDScript n’est pas mauvais en soi, et si on ne le compare pas à d’autres langages, il est même très correct. Mais face à un langage généraliste, on perd beaucoup trop de choses.
      Je sais qu’il existe des bindings, mais après une expérience similaire avec Raylib, le support non officiel de langages m’a semblé pratiquement inexistant. Même Mono, qui est un binding officiel, est assez mauvais.
    • .NET est plus rapide.
      Cela dit, même les jeux AAA utilisent souvent des langages de script lents pour la logique de jeu. Dans beaucoup de jeux, la logique de jeu n’est pas la partie qui consomme beaucoup de CPU, donc ce n’est souvent pas si important.
    • Je me demande à quoi ressemble la prédiction réseau dans un framework de jeu. Est-ce un mécanisme où l’on indique quelles propriétés d’un objet doivent être interpolées, puis le moteur s’en charge automatiquement ?

  • Y a-t-il des usages de Godot pour le développement d’applications cross-platform à la place de choses comme Electron ?

    • Oui. Cela dit, la première génération d’applications commence tout juste à sortir. Voici quelques projets assez aboutis sur GitHub :
      Éditeur de pixel art : https://github.com/Orama-Interactive/Pixelorama
      Outil de dessin à canevas infini : https://github.com/mbrlabs/Lorien
      Tableau kanban façon Trello : https://github.com/alfredbaudisch/Godello
      Outil de conception narrative pour jeux : https://github.com/mhgolkar/Arrow
    • Material Maker : https://www.materialmaker.org
      Je l’ai essayé quand Substance a été racheté par Adobe, et à ma grande surprise, il était beaucoup plus facile et agréable à utiliser. Substance Designer paraît assez lourd en comparaison.
      Bien sûr, Substance Designer a l’avantage propre de son intégration avec Substance Painter. Material Maker propose aussi quelques fonctions de peinture manuelle, mais ce n’est pas une application de peinture complète.
    • L’IDE Godot lui-même est-il fait avec Godot ?
    • Oui.
      OpenSCAD Graph Editor a été réalisé avec une ancienne version de Godot et fonctionne sur Mac OS, Windows et Linux :
      https://github.com/derkork/openscad-graph-editor
    • Certaines personnes utilisent Godot comme framework GUI.

  • L’un des principaux contributeurs/développeurs de Godot a aussi publié un petit outil pratique permettant de décompiler complètement ce qui a été créé avec Godot.
    https://github.com/bruvzg/gdsdecomp

    • C’est un excellent outil, mais le développeur principal, lead et originel de Godot est reduz, c’est-à-dire Juan Linietsky.

  • Godot est vraiment excellent. Je suis profondément impressionné par les progrès de l’équipe et par l’orientation générale du projet
    À l’origine, je me suis toujours intéressé au développement de jeux, et c’est en grande partie parce que je voulais créer des jeux que j’ai étudié l’informatique et suis devenu ingénieur logiciel. Je voulais faire de petits jeux moi-même, mais en pratique je n’y suis jamais vraiment arrivé
    Une fois devenu ingénieur logiciel à plein temps, je n’ai pas trouvé le temps ni les bons outils pour créer de petits jeux en hobby
    Récemment, j’ai découvert Bevy et je l’ai essayé ; ECS est un bon concept, mais Bevy ressemble davantage à une bibliothèque, et il est assez difficile de produire un jeu abouti avec, un peu comme quand on utilise quelque chose comme SDL
    Quand j’ai découvert Godot et que je l’ai essayé, j’ai été vraiment impressionné. Il est accueillant pour les débutants tout en étant suffisamment rapide, et la communauté est excellente. C’est exactement ce que je cherchais, donc je suis très heureux qu’il existe et j’ai hâte de voir son évolution
    Un point qui me déçoit un peu, c’est le choix de langage natif et « officiel ». GDScript est correct, c’est un langage dans l’esprit de Python plutôt bon pour les débutants et le prototypage rapide, et C# peut aussi être intéressant pour les personnes venant de Unity
    Personnellement, j’aurais été plus heureux avec une meilleure prise en charge de C++, ou autre chose. Je sais qu’il existe l’interface GDNative et qu’elle a été améliorée dans la 4.0
    C# est un bon langage, mais j’ai l’impression que sa forte présence dans le développement de jeux vient surtout de Unity. Il est trop verbeux, et en dehors de Visual Studio complet, le support des outils n’est pas si bon
    Cela dit, peut-être que la partie « vraie programmation » dans le développement de jeux n’est pas si importante, et qu’il faudrait simplement l’accepter et utiliser GDScript

  • Godot aura peut-être du mal à rivaliser avec Unreal, mais je l’encourage clairement du côté du remplacement de Unity
    C’est un excellent moteur, et de plus en plus de développeurs en perçoivent correctement le potentiel

    • Unity est son propre écosystème, d’une manière différente d’Unreal. En tant que plateforme, Unity prend en charge la monétisation mobile d’une façon que les autres plateformes ne font pas, et il sera difficile pour Godot de lui prendre cet écosystème à court terme
      En revanche, si l’on parle de développement indé, je suis totalement d’accord. Godot est le framework que les gens attendaient de Unity : léger, non intrusif, et qui permet de se mettre à créer immédiatement. Pour cet usage, Godot est nettement meilleur
    • Vouloir concurrencer Unreal, un moteur vieux de plusieurs décennies centré sur les jeux AAA et doté de grosses équipes à plein temps, serait téméraire. Pour un projet open source, il est difficile de rattraper une cible aussi mouvante
      Heureusement, Unreal Engine est un mauvais choix pour beaucoup de types de jeux, et Godot se construit bien son propre territoire du côté des jeux 2D et des jeux 3D simples
      Le marché des jeux 2D reste vaste, et étonnamment peu de moteurs prennent bien en charge la 2D. Godot se place facilement parmi les meilleurs
    • S’il peut répliquer le marketplace, il me semble qu’il pourra aussi concurrencer Unity

  • Godot est vraiment génial, et j’ai énormément de respect pour toutes les personnes qui consacrent du temps à rendre excellents ce type de logiciel et des outils comme Blender

  • Godot s’améliore vraiment à chaque version. Il y a des fonctionnalités que j’aimerais voir arriver dans Godot
    FSR2, une excellente prise en charge de Wayland, et une intégration des LLM. Les LLM pourraient peut-être rendre les PNJ plus réalistes

    • Je ne suis pas sûr pour l’intégration des LLM. Cela me semble plutôt relever d’une fonctionnalité propre à chaque jeu que du moteur de jeu. L’intégration des LLM pourrait sans doute être gérée par script dans le jeu
      Côté intégration de l’intelligence artificielle, le design assisté par IA est plus intéressant : on décrit un terrain, un personnage ou un scénario, l’IA génère quelque chose, puis l’utilisateur le personnalise et l’ajuste
      Mais même cela a probablement davantage sa place en dehors du cœur du moteur de jeu
    • Et le ray tracing accéléré matériellement ?

  • Y a-t-il des tutoriels Godot à recommander ?
    J’ai un petit prototype de RPG qui fonctionne en console, et j’aimerais lui ajouter une vraie GUI ou des graphismes en sprites

    • Il existe un tutoriel gratuit pour Godot 4, qui permet de partir de zéro et d’arriver à un jeu complet en environ deux heures : https://quiver.dev/tutorials/create-your-first-godot-4-game/
      À préciser : je suis le fondateur de l’entreprise qui a créé ce cours. Cela dit, le tutoriel est gratuit, et les assets personnalisés utilisés dans le tutoriel sont eux aussi fournis sous une licence permissive
    • GD Quest est actuellement considéré comme la référence. C’est un peu le W3Schools de Godot
      Cela dit, en tant que personne passant de Unity à Godot, je trouve que l’écosystème de tutoriels de Godot est encore très en retard
    • J’ai suivi l’un des cours de Heartbeast et je peux le recommander
      Il a aussi récemment publié un cours dédié à Godot 4
      https://www.youtube.com/watch?v=M8-JVjtJlIQ
    • J’ai une liste de tutoriels de programmation sur YouTube, avec aussi quelques tutoriels Godot
      https://www.youtube.com/playlist?list=PLwYfcDZR0fFcROLjkiyBW...
      Beaucoup des tutoriels que vous trouverez seront probablement pour Godot 3, donc il vaut mieux rechercher en filtrant explicitement sur Godot 4
      Sinon, vous devrez adapter vous-même le code du tutoriel pour qu’il fonctionne avec votre version de Godot, ce qui peut aussi être une expérience formatrice en soi
    • La documentation officielle[0] est clairement la voie canonique
      [0] https://docs.godotengine.org/en/stable/getting_started/intro...