Foire aux questions

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, certaines personnes travaillent 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 compilation de Godot par vous-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 :ref: script <toc-learn-scripting>.

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.

Notez que le support du langage C# est récent et que, par conséquent, il est possible de rencontrer des bugs. Notre communauté active et bienveillante est toujours prête à s’attaquer aux problèmes qui se présentent, mais comme il s’agit d’un projet open source, nous vous recommandons de faire les vérifications nécessaires par vous même. Chercher parmi les `problèmes connus <https://github.com/godotengine/godot/issues>`est un très bon moyen d’arriver à vous dépanner.

Comme pour les nouveaux 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 exemples, l’histoire et une présentation complète de la puissance offerte par GDScript sont disponibles dans le manuel GDScript.

L’utilisation de GDScript présente de nombreux avantages lors du prototypage dans les phase 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, réduire le nombre de classes d’erreurs, 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 à porter un nombre restreint de fonctionnalités sur 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 ?

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

  1. Pas de bon support des threads dans la plupart des VMs de scripts, et Godot utilise des threads (Lua, Python, Squirrel, JS, AS, etc.).
  2. Pas de bon support d’extension de classes dans la plupart des VMs de scripts, 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 liant à C++, entraînant une grande quantité de code, des bogues, des goulots d’étranglement et une inefficacité générale (Lua, Python, Squirrel, JS, etc.). Nous souhaitons nous concentrer sur un moteur robuste, pas une robuste 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, JS, AS, etc.).
  5. Le ramasse-miette entraîne des délais ou une utilisation inutilement importante de la mémoire (Lua, Python, JS, AS, etc.).
  6. Difficulté d’intégration avec l’éditeur de code pour compléter le code, éditer 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’exporteur OpenCollada (Maya, 3DSMax).

Si vous utilisez Blender, jetez un coup d’œil à notre propre Better Collada Exporter.

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

Le SDK du format FBX a une licence très restrictive, qui est incompatible avec la licence libre fournie par Godot. Ceci étant dit, FBX peut tout de même être fourni par des tiers en tant que plugins. (Voir la section Plugins ci-dessus.)

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’il soient open-source ou non.

Pour voir comment votre SDK préféré pourrait être supporté, jetez un œil à la question des 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 vision caméra X ou Y en 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 Multiple resolutions 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 Multiple resolutions.
  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 EditorPlugins 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 le règlement 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.

Why does Godot not use STL (Standard Template Library)

Like many other libraries (Qt as an example), Godot does not make use of STL. We believe STL is a great general purpose library, but we had special requirements for Godot.

  • STL templates create very large symbols, which results in huge debug binaries. We use few templates with very short names instead.
  • Most of our containers cater to special needs, like Vector, which uses copy on write and we use to pass data around, or the RID system, which requires O(1) access time for performance. Likewise, our hash map implementations are designed to integrate seamlessly with internal engine types.
  • Our containers have memory tracking built-in, which helps better track memory usage.
  • For large arrays, we use pooled memory, which can be mapped to either a preallocated buffer or virtual memory.
  • We use our custom String type, as the one provided by STL is too basic and lacks proper internationalization support.

Why does Godot not use exceptions?

We believe games should not crash, no matter what. If an unexpected situation happens, Godot will print an error (which can be traced even to script), but then it will try to recover as gracefully as possible and keep going.

Additionally, exceptions significantly increase binary size for the executable.

Why does Godot not enforce RTTI?

Godot provides its own type-casting system, which can optionally use RTTI internally. Disabling RTTI in Godot means considerably smaller binary sizes can be achieved, at a little performance cost.

Why does Godot not force users to implement DoD (Data oriented Design)?

While Godot internally for a lot of the heavy performance tasks attempts to use cache coherency as best as possible, we believe most users don’t really need to be forced to use DoD practices.

DoD is mostly a cache coherency optimization that can only gain you significant performance improvements when dealing with dozens of thousands of objects (which are processed every frame with little modification). As in, if you are moving a few hundred sprites or enemies per frame, DoD won’t help you, and you should consider a different approach to optimization.

The vast majority of games do not need this and Godot provides handy helpers to do the job for most cases when you do.

If a game that really needs to process such large amount of objects is needed, our recommendation is to use C++ and GDNative for the high performance parts and GDScript (or C#) for the rest of the game.

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

Voir Ways to contribute.

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

Voir la page correspondante sur le site web de Godot.