Questions fréquentes

Que puis-je faire avec Godot ? Combien coûte-t-il ? Quels sont les termes de la licence ?

Godot est un logiciel libre et à code source ouvert (open source) disponible sous licence MIT, approuvée par l'OSI. Cela veut dire qu'il est à la fois libre et gratuit.

En bref :

  • Vous êtes autorisé à télécharger et à utiliser Godot pour tout usage, qu'il soit personnel, libre, commercial ou autre.
  • Vous êtes libre de modifier, distribuer, redistribuer et remixer Godot comme bon vous semble, pour quelque raison que ce soit, à la fois de manière non commerciale et commerciale.

Tout le contenu de la documentation est publié sous la licence Creative Commons Attribution 3.0 (CC-BY 3.0), avec attribution à "Juan Linietsky, Ariel Manzur et la communauté Godot Engine".

Les logos et icônes sont généralement sous la même licence Creative Commons. Notez que certaines bibliothèques de tiers incluses avec le code source de Godot peuvent avoir des licences différentes.

Pour tous les détails, voir COPYRIGHT.txt ainsi que LICENSE.txt et LOGO_LICENSE.txt qui se trouvent dans le dépôt de Godot.

Voir aussi la page de la licence sur le site de Godot.

Quelles plateformes sont supportées par Godot ?

Pour l'éditeur:

  • Windows
  • macOS
  • X11 (Linux, *BSD)

Pour exporter vos jeux:

  • Windows (et UWP)
  • macOS
  • X11 (Linux, *BSD)
  • Android
  • iOS
  • Web

Les formats binaires 32 et 64 bits sont supportés quand appropriés. Le format 64 bits est utilisé par défaut.

Certains utilisateurs ont aussi reporté avoir compilé et utilisé Godot avec succès sur des systèmes basés sur l'architecture ARM avec Linux, tels que le Raspberry Pi.

De plus, des travaux tiers non officiels sont en cours pour permettre à Godot de fonctionner sur certaines consoles. Cependant, aucun ajout de ce type n'est pour l'instant inclus dans les scripts de compilation ou modèles d'exportation par défaut.

Pour plus d'informations à ce sujet, voir les sections sur l'export de projet et la compilater Godot soi-même.

Quels langages de programmation sont supportés par Godot ?

Les langages officiellement supportés par Godot sont le GDScript, le Visual Scripting, C# et C++. Voir les sous-catégories pour chaque langage dans la section script.

Si vous débutez avec Godot ou avec la programmation de jeux vidéo, GDScript est le langage recommandé puisqu'il est natif dans Godot. Bien que les langages de script soient moins performants que ceux bas-niveau à terme, GDScript est un moyen rapide, facile d'utilisation et puissant pour le développement de jeux vidéo, notamment pour obtenir un prototype viable, et réduire les temps de développement.

Il est important de noter que le support du langage C# est récent, et que par conséquent, il est possible de rencontrer des bugs. Notre communauté est accueillante et laborieuse, toujours prête à aborder les problèmes qui se présentent, mais comme il s'agit d'un projet open source, nous vous recommandons de d'abord faire les vérifications nécessaires. Une bonne manière de résoudre les problèmes consiste à chercher parmi les problèmes connus.

Pour de d'autres langages, le support est possible via des tiers utilisant les fonctionnalités GDNative / NativeScript / PluginScript. (Voir la question sur les plugins ci-dessous.) Des travaux sont actuellement en cours, par exemple, sur les liaisons non officielles pour Godot à Python et Nim.

Qu'est-ce que le GDScript et pourquoi devrais-je l'utiliser ?

GDScript est le langage de scripting intégré à Godot. Il a été conçu à partir de zéro afin de maximiser le potentiel de Godot en un minimum de code, permettant aux développeuses et développeurs de tous niveaux d'expertise de s'appuyer sur les atouts de Godot aussi vite que possible. Si vous avez déjà utilisé Python ou un langage similaire auparavant, vous devriez vous y retrouver rapidement. Pour voir des exemples, l’historique et une présentation complète de la puissance offerte par GDScript, reportez vous au manuel GDScript.

L'utilisation de GDScript présente de nombreux avantages lors du prototypage dans les phases alpha ou bêta de votre projet ou dans le cas où vous ne créez pas le prochain blockbuster, mais l'avantage le plus évident est la réduction de la complexité générale.

L'idée directrice ayant conduit à la mise en place d'un langage de script étroitement intégré et sur mesure dans Godot découle de deux raisons : d'une part, réduire le temps nécessaire pour la prise en main de Godot, avec une attention particulière accordée à la productivité, d'autre part faciliter la maintenance, atténuer la dimension des problèmes, et permettre aux développeuses et développeurs du moteur de jeu de se concentrer sur la résolution de bugs et l'amélioration de fonctionnalités, au lieu de devoir passer beaucoup de temps à créer un nombre restreint de fonctionnalités dans de nombreux langages de programmation.

Godot étant un logiciel libre, il était impératif de prioriser dès le départ une expérience de développement plus intégrée et unie plutôt que d'attirer plus d'utilisatrices et d'utilisateurs en ajoutant le support de langages de programmation plus familiers -- tout particulièrement quand le support de ces langages aurait résulté en une expérience plus désagréable du moteur. Nous comprendrions si vous préfériez utiliser un autre langage dans Godot (voir les options supportées ci-dessus), mais nous vous suggérons de l'essayer vous-même pour en constater les avantages.

Vous trouverez plus d'informations sur la façon de se familiariser avec GDScript ou les langages à typage dynamique dans le tutoriel GDScript : Une introduction aux langages dynamiques.

Qu'est-ce qui a motivé la création de GDScript ?

Au début, le moteur utilisait le langage de scripts Lua . Lua est rapide, mais créer des bindings (liaisons) vers un système orienté objet (en utilisant des fallbacks) était complexe, lent et demandait une énorme quantité de code. Après quelques expérimentations avec Python, il s’avéra lui aussi difficile a intégrer.

Les principales raisons de la création d'un langage de script personnalisé pour Godot étaient :

  1. Mauvais support des threads dans la plupart des scripts de machines virtuelles, et Godot utilise des threads (Lua, Python, Squirrel, JS, AS, etc.).
  2. Mauvais support d'extension de classes dans la plupart des scripts de machines virtuelles, et les adapter à la façon dont Godot fonctionne est très inefficace (Lua, Python, JS).
  3. Bon nombre de langages existants possèdent d'horribles interfaces de liaison au C++, entraînant une grande quantité de code, des bogues, des goulots d'étranglement et une inefficacité générale (Lua, Python, Squirrel, JavaScript, etc.). Nous souhaitons nous concentrer sur un moteur robuste, pas sur une grande quantité d'intégrations.
  4. Pas de types vectoriels natifs (vector3, matrix4, etc.), ce qui réduit considérablement les performances lors de l'utilisation de types personnalisés (Lua, Python, Squirrel, JavaScript, ActionScript, etc.).
  5. Le ramasse-miette entraîne des délais ou une utilisation inutilement importante de la mémoire (Lua, Python, JavaScript, ActionScript, etc.).
  6. Difficulté d'intégration dans l'éditeur de code pour fournir la complétion de code, édition en direct, etc. Ceci est très bien supporté par le GDScript.

GDScript a été conçu pour réduire les problèmes ci-dessus et plus encore.

Quels types de formats de modèles 3D sont pris en charge par Godot ?

Godot supporte Collada via l'exportateur OpenCollada (Maya, 3DSMax). Si vous utilisez Blender, jetez un œil à notre propre Better Collada Exporter.

À partir de Godot 3.0, glTF est pris en charge.

FBX, pris en charge via la bibliothèque Open Asset Import. Cependant, FBX est propriétaire, nous vous recommandons donc d'utiliser d'autres formats listés ci-dessus, si cela convient à votre flux de travail.

Est-ce que [Insérer un SDK fermé tel que FMOD, GameWorks, etc.] sera un jour, supporté dans Godot ?

Le but de Godot est de créer un moteur de jeu modulaire, extensible, libre et open-source couvert par la licence MIT. La communauté autour du moteur de jeu ne prévoit aucun support de projets tiers/SDK propriétaire, du fait que leur intégration irait à l'encontre de l'éthique de Godot.

Cela dit, parce que Godot est open source et modulaire, rien n'empêche que vous ou toute autre personne intéressée ajoutiez ces bibliothèques en tant que module et que vous les livriez avec votre jeu -- qu'ils soient open-source ou non.

Pour voir comment votre SDK préféré pourrait être supporté, jetez un œil à la question sur les plugins ci-dessous.

Si vous connaissez un SDK externe qui n'est pas supporté par Godot mais qui permet une intégration libre et open source, n'hésitez pas à commencer cette intégration vous-même. Godot n'est pas la propriété d'une personne ; il appartient à la communauté, et il grandit avec des contributeurs ambitieux comme vous.

Comment créer des ressources pour gérer plusieurs résolutions et rapports d'aspect ?

Cette question revient souvent et c'est probablement à cause du malentendu créé par Apple lorsqu'ils ont doublé la résolution de leurs appareils. Cela a fait croire aux gens que le fait d'avoir les mêmes ressources dans des résolutions différentes était une bonne idée, et beaucoup ont continué dans cette voie. À l'origine, cela fonctionnait et seulement pour les appareils Apple, mais ensuite plusieurs appareils Android et Apple avec des résolutions et des rapports d'aspect différents ont été créés, avec une très large gamme de tailles et de DPIs.

La façon la plus courante et la plus appropriée d'y parvenir est d'utiliser une unique résolution de base pour le jeu et de ne gérer que les différents aspects d'écran. C'est principalement nécessaire pour la 2D, puisque c'est juste une question de champ de XFov ou YFov en 3D.

  1. Choisissez une seule résolution de base pour votre jeu. Même s'il y a des appareils qui vont jusqu'à 2K et des appareils qui descendent jusqu'à 400p, la mise à l'échelle matérielle habituelle de votre appareil s'en chargera avec un coût négligeable sur les performances. Les choix les plus courants sont proches de 1080p (1920x1080) ou de 720p (1280x720). Gardez à l'esprit que plus la résolution est élevée, plus vos ressources seront volumineuses, plus elles prendront de mémoire et plus le temps de chargement sera long.
  2. Utilisez les options d'étirement dans Godot ; l'étirement 2D avec maintien de l'aspect fonctionne le mieux. Consultez le tutoriel Résolutions multiples sur la façon d'y parvenir.
  3. Déterminez une résolution minimale et décidez ensuite si vous souhaitez que votre jeu s'étire verticalement ou horizontalement pour différents rapports d'aspect, ou s'il y a une résolution minimale et que vous souhaitez que des barres noires apparaissent à la place. Ceci est également expliqué dans Résolutions multiples.
  4. Pour les interfaces utilisateur, utilisez l'ancrage pour déterminer où les contrôles doivent rester et se déplacer. Si l'UI est plus complexe, songez à vous renseigner sur les conteneurs.

Et c'est tout ! Votre jeu devrait fonctionner en plusieurs résolutions.

Si vous souhaitez également faire fonctionner votre jeu sur des appareils anciens avec de petits écrans (moins de 300 pixels de largeur), vous pouvez utiliser l'option d'exportation pour réduire les images, et définir l'utilisation de ce build pour certaines tailles d'écran dans l'App Store ou Google Play.

Comment puis-je améliorer Godot ?

Pour améliorer Godot, par exemple en créant des plugins pour l'éditeur ou supporter un langage supplémentaire, consultez les Extensions pour l’éditeur et les outils de scripting.

Voir aussi les articles du blog officiel sur ces sujets :

Vous pouvez également jeter un coup d’œil à l'implémentation de GDScript, aux modules de Godot ainsi qu'au support non-officiel de Python pour Godot. C'est un bon point de départ pour observer comment les bibliothèques tierces s'intègrent dans Godot.

J'aimerai contribuer ! Où puis-je commencer ?

Super ! En tant que logiciel libre, Godot progresse grâce aux améliorations et innovations apportées par des développeuses et développeurs comme vous.

La première page à consulter pour commencer est la section des problèmes. Trouvez une question qui vous interpelle, puis référez-vous au guide Comment Contribuer pour déterminer comment récupérer le projet, le modifier, puis soumettre une Pull Request (PR) contenant vos modifications.

J'ai une super idée pour Godot. Comment puis-je la partager ?

Il pourrait être tentant de vouloir apporter des idées à Godot, comme celles qui entraînent des changements importants dans le cœur même, une sorte de mimétisme de ce que ferait un autre moteur de jeu, ou encore d'autres méthodes de travail que vous souhaiteriez intégrer dans l'éditeur. Celles-ci sont appréciables et nous sommes reconnaissants d'avoir des personnes aussi motivées qui veulent contribuer, mais Godot est, et sera toujours, concentré sur les fonctions de base telles que décrites dans la feuille de route, sur la correction des bugs et la résolution des problèmes, et sur les discussions entre membres de la communauté Godot.

La plupart des développeuses et développeurs de la communauté préféreront entendre parler de :

  • Votre expérience lors de l'utilisation du logiciel et les problèmes que vous rencontrez (nous nous soucions de cela bien plus que des idées sur la façon de l'améliorer).
  • Les fonctionnalités que vous aimeriez voir mises en œuvre parce que vous en avez besoin pour votre projet.
  • Les concepts que vous avez eu du mal à appréhender lors de votre utilisation du logiciel.
  • Les parties de votre flux de travail que vous aimeriez voir optimisées.
  • Les parties où vous avez manqué de tutoriels clairs ou bien où la documentation n'était pas à la hauteur.

Ne pensez surtout pas que vos idées pour Godot ne sont pas les bienvenues. Essayez plutôt de les reformuler en mettant l'accent sur le problème auquel vos idées tenteraient de répondre, afin que les développeurs et la communauté aient des arguments sur lesquels s'appuyer pour en débattre.

Une bonne manière de partager avec la communauté vos idées et problèmes que vous avez rencontrés consiste à raconter une expérience utilisateur. Racontez ce que vous essayez de réaliser, à quels comportements vous vous attendez, et enfin ce qui s'est produit. Créer un cadre autour des idées et des problèmes de cette manière permettra à la communauté de rester concentrée sur l'amélioration de l'expérience utilisateur dans son ensemble.

Point bonus si vous ajoutez des captures d'écran, des chiffres concrets, des cas de test ou des exemples de projets le cas échéant.

Est-il possible d'utiliser Godot comme bibliothèque ?

Godot est destiné à être utilisé avec son éditeur. Nous vous recommandons de l'essayer, car il vous fera très probablement gagner du temps à long terme. Il n'est pas prévu de rendre Godot utilisable comme bibliothèque, car cela rendrait le reste du moteur plus alambiqué et difficile à utiliser pour les utilisateurs occasionnels.

Si vous souhaitez utiliser une bibliothèque de rendu, envisagez plutôt d'utiliser un moteur de rendu établi. Gardez à l'esprit que les moteurs de rendu ont généralement des communautés plus petites que Godot. Il sera donc plus difficile de trouver des réponses à vos questions.

Pourquoi Godot n'utilise pas la STL (Standard Template Library)

Comme beaucoup d'autres bibliothèques (Qt par exemple), Godot n'utilise pas la STL. Nous pensons que la STL est une très bonne bibliothèque pour un usage général, mais nous avons des besoins spécifiques pour Godot.

  • Les templates de la STL créent de grands symboles, engendrant d'énormes binaires de debogage. Nous utilisons quelques templates avec des noms très courts à la place.
  • La plupart des conteneurs répondent a des besoins spécifiques. Par exemple il y a le conteneur Vector, qui utilise le "copy on write" (copie l'objet lorsqu'il est modifié) et que nous utilisons pour manipuler des données. Ou encore, il y a le système de RID, avec un temps d'accès d'une complexité en O(1). De la même manière, l'implémentation des HashMap (table de hashage),est conçue pour s'intégrer parfaitement avec les types internes au moteur.
  • Les conteneurs intègrent un système de traçage de la mémoire, ce qui permet le suivi de l'utilisation de la mémoire au cours du temps.
  • Pour les grands tableaux, nous utilisons un pool de mémoire (réservoir en quelque sorte), qui peut être attaché soit à de la mémoire virtuelle, soit à une mémoire tampon.
  • La gestion des String offerte par la STL étant basique et ne permettant pas de supporter l'internationalisation (i18n pour l'abbréviation), nous utilisons notre propre type de String (chaîne de caractère).

Pourquoi n'y a-t-il pas de gestion d'exceptions dans Godot ?

Nous pensons que les jeux ne doivent pas planter, peu importe la raison. Dans le cas où une erreur se produit, Godot va afficher un message d'erreur (qui va vous permettre de remonter jusqu'au script fautif), puis il va essayer de continuer de fonctionner en mode dégradé.

De plus, gérer des exceptions nécessiterait d'avoir des fichiers exécutables bien plus lourds.

Pourquoi Godot n'applique-t-il pas le RTTI (Run-time type information) ?

Godot a possède son propre système de casting, qui peut occasionnellement utiliser le RTTI en interne. Désactiver le RTTI dans Godot Engine réduit considérablement la taille des fichiers binaires mais impact légèrement les performances.

Pourquoi Godot Engine ne force-t-il pas les utilisateurs a implémenter le DoD (Data oriented Design) ?

Bien que Godot en interne pour beaucoup de tâches gourmandes en performance tente d'utiliser la cohérence du cache le mieux possible, nous pensons que la plupart des utilisateurs n'ont pas vraiment besoin d'être forcés à utiliser les pratiques DoD.

Le DoD est efficace lorsque vous l'utilisez pour manipuler des douzaines de milliers d'objets (qui sont traités à chaque frame avec peu de modifications). Dans le cas où vous êtes amené à déplacer des centaines de Sprites (ou d'ennemis), le DoD ne vous sera pas utile et vous devrez adopter une approche différente.

Dans la plupart des cas, vous n'aurez pas besoin du DoD. Et Godot va vous fournir des fonctions pratiques pour vous aider dans ce que vous voulez faire.

Si pour un jeu, vous avez besoin de manipuler un grand nombre d'objets, nous vous recommandons d'utiliser du C++ ou un module écrit en GDNative. Pour les autres parties du jeu, qui ne sont pas autant demandantes en terme de performance, le GDScript ou le C# feront l'affaire.

Comment puis-je soutenir le développement de Godot ou y contribuer ?

Voir Façons de contribuer.

Qui travaille sur Godot ? Comment puis-je vous contacter ?

Voir la page correspondante sur le site web de Godot.