Attention: Here be dragons

This is the latest (unstable) version of this documentation, which may document features not available in or compatible with released stable versions of Godot.

Checking the stable version of the documentation...

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 comme dans "liberté d'expression" et gratuit comme dans "bière gratuite."

En bref :

Vous êtes libre de télécharger et d'utiliser Godot pour tout usage : personnel, sans but lucratif, 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 cette documentation est publié sous la licence permissive Creative Commons Attribution 3.0 (CC-BY 3.0), avec attribution à "Juan Linietsky, Ariel Manzur et la communauté du moteur Godot."

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 les fichiers COPYRIGHT.txt ainsi que LICENSE.txt et LOGO_LICENSE.txt dans le dépôt 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
Linux, *BSD
Android (expérimental)
Web (expérimental)

Pour exporter vos jeux:

Windows
macOS
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. Les builds officiels de macOS supportent nativement les Apple Silicon aussi bien que les x86_64.

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.

L'équipe Godot ne peut pas fournir un exporteur de jeux pour console open-source à cause des termes de licence imposées par les fabricants de consoles. Indépendamment du moteur que vous utilisez, sortir des jeux sur consoles représente toujours beaucoup de travail. Vous pouvez en lire plus ici : Support des consoles dans Godot.

Pour plus d'informations à ce sujet, voir les sections sur exporting et la compiling Godot yourself.

Note

Godot 3 supportait la Plateforme Windows Universelle (UWP). Cette plateforme a été retiré dans Godot 4 à cause du peu de maintenance et de son abandon progressif par Microsoft. La plateforme est toujours disponible dans la version stable de Godot 3 pour les utilisateurs intéressés.

Quels langages de programmation sont supportés par Godot ?

Les langages officiellement supportés par Godot sont le GDScript, 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.

Notez que la prise en charge du langage C# est encore relativement récente et qu'il est donc possible que vous rencontriez des problèmes en cours de route. La prise en charge du langage C# est également absente de la plate-forme web. Notre communauté de développeurs, amicale et travailleuse, est toujours prête à s'attaquer aux nouveaux problèmes dès qu'ils se présentent, mais comme il s'agit d'un projet open source, nous vous recommandons d'abord de faire preuve de diligence raisonnable par vous-même. Une recherche dans les discussions sur les open issues est un excellent moyen de commencer votre dépannage.

Pour 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 avec un minimum de code, permettant aux 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 et une présentation détaillée de la puissance offerte par GDScript, reportez-vous au manuel GDScript.

There are several reasons to use GDScript, but the most salient reason is the overall reduction of complexity.

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 éléments : 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, diminuer la dimension des problèmes, et permettre aux 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.

Since Godot is an open source project, it was imperative from the start to prioritize a more integrated and seamless experience over attracting additional users by supporting more familiar programming languages, especially when supporting those more familiar languages would result in a worse experience. We understand if you would rather use another language in Godot (see the list of supported options above). That being said, if you haven't given GDScript a try, try it for three days. Just like Godot, once you see how powerful it is and how rapid your development becomes, we think GDScript will grow on you.

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 de jeu utilisait le langage de scripts Lua . Lua peut être rapide grâce à LuaJIT, 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 :

Mauvais support des threads dans la plupart des scripts de machines virtuelles, et Godot utilise des threads (Lua, Python, Squirrel, JS, AS, etc.).
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).
Bon nombre de langages existants possèdent d'horribles interfaces de liaison avec 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 avons souhaité nous concentrer sur un moteur robuste, pas sur une grande quantité d'intégrations.
Pas de types vectoriels natifs (vector3, matrix4, etc.), résultant en une performance considérablement réduite lors de l'utilisation de types personnalisés (Lua, Python, Squirrel, JavaScript, ActionScript, etc.).
Le ramasse-miette entraîne des délais ou une utilisation inutilement importante de la mémoire (Lua, Python, JavaScript, ActionScript, etc.).
Difficulté d'intégration avec l'éditeur de code pour la complétion du code, l'édition en direct, etc.

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

Which programming language is fastest?

In most games, the scripting language itself is not the cause of performance problems. Instead, performance is slowed by inefficient algorithms (which are slow in all languages), by GPU performance, or by the common C++ engine code like physics or navigation. All languages supported by Godot are fast enough for general-purpose scripting. You should choose a language based on other factors, like ease-of-use, familiarity, platform support, or language features.

In general, the performance of C# and GDScript is within the same order of magnitude, and C++ is faster than both.

Comparing GDScript performance to C# is tricky, since C# can be faster in some specific cases. The C# language itself tends to be faster than GDScript, which means that C# can be faster in situations with few calls to Godot engine code. However, C# can be slower than GDScript when making many Godot API calls, due to the cost of marshalling. C#'s performance can also be brought down by garbage collection which occurs at random and unpredictable moments. This can result in stuttering issues in complex projects, and is not exclusive to Godot.

C++, using GDExtension, will almost always be faster than either C# or GDScript. However, C++ is less easy to use than C# or GDScript, and is slower to develop with.

You can also use multiple languages within a single project, with cross-language scripting, or by using GDExtension and scripting languages together. Be aware that doing so comes with its own complications.

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

Vous pouvez trouver des informations détaillées sur les formats suporté, comment les exporter de votre logiciel de 3D et comment les importer dans Godot dans la Importation de scènes 3D documentation.

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, Godot étant un logiciel libre et modulaire, rien ne vous empêche vous ou toute autre personne intéressée d'ajouter ces bibliothèques en tant que module et d'expédier votre jeu avec elles, en tant que logiciel libre ou fermé.

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 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.

Consultez également l'article du blog officiel sur GDExtension, un moyen de développer des extensions natives pour Godot :

Voici le successeur de GDNative, GDExtension

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. Ce serait un bon point de départ pour observer comment les bibliothèques tierces s'intègrent dans Godot.

Comment installer l'éditeur Godot sur mon système (pour l'intégration du bureau) ?

Étant donné que vous n’avez pas besoin d’installer Godot sur votre système pour l’exécuter, cela signifie que l’intégration du bureau (voir Godot dans la liste des programmes) n’est pas effectuée automatiquement. Il y a deux façons de surmonter cela. Vous pouvez installer Godot à partir de Steam (toutes les plates-formes), Scoop (Windows), Homebrew (macOS) ou Flathub (Linux). Cela effectuera automatiquement les étapes requises pour l’intégration de bureau.

Sinon, vous pouvez faire ces étapes manuellement qu'un installeur ferait à votre place :

Windows

Déplacez l’exécutable Godot vers un emplacement stable (c’est-à-dire en dehors de votre dossier Téléchargements), afin de ne pas le déplacer accidentellement et de casser le raccourci à l’avenir.
Cliquez-droit sur l'exécutable Godot et choisissez Créer un raccourci.
Déplacez le raccourci créé vers %LOCALAPPDATA%\Microsoft\Windows\Start Menu\Programs. Il s’agit de l’emplacement propre à chaque utilisateur pour les raccourcis qui apparaîtront dans le menu Démarrer. Vous pouvez également épingler Godot dans la barre des tâches en cliquant avec le bouton droit sur l’exécutable et en choisissant Épingler à la barre des tâches.

macOS

Faites glisser l’application Godot extraite vers /Applications/Godot.app, puis faites-la glisser vers le Dock si vous le souhaitez. Spotlight sera en mesure de trouver Godot tant qu’il est dans /Applications ou ~/Applications.

Linux

Déplacez l’exécutable de Godot vers un emplacement stable (c’est-à-dire en dehors de votre dossier Téléchargements), afin de ne pas le déplacer accidentellement et de casser le raccourci à l’avenir.
Renommez et déplacez l’exécutable de Godot vers un emplacement présent dans votre variable d'environnement PATH. Il s'agit généralement de /usr/local/bin/godot ou /usr/bin/godot. Cette opération nécessite des privilèges d'administrateur, mais elle vous permet également d'exécuter l'éditeur Godot à partir d'un terminal en saisissant godot.
- Si vous ne pouvez pas déplacer le binaire de l'éditeur de Godot vers un emplacement sécurisé, vous pouvez le garder dans votre dossier personnel puis modifier la ligne Path= dans le fichier .desktop en lien ci-dessous pour contenir le chemin absolu du binaire de Godot.
Enregistrez ce fichier .desktop dans $HOME/.local/share/applications/. Si vous avez les privilèges administrateurs, vous pouvez plutôt enregistrer le fichier .desktop dans /usr/local/share/applications pour rendre ce raccourci disponible pour tous les utilisateurs de votre système.

Est-ce que Godot est une application portable ?

Dans sa configuration par défaut, Godot est semi-portable. Son exécutable peut fonctionner depuis n'importe quel emplacement (emplacements non inscriptibles inclus) et ne requiert aucun privilège administrateur.

Cependant, les fichiers de configuration seront écrits dans le répertoire de données ou de configuration propre à l'utilisateur. C'est généralement une bonne approche, cependant cela implique que les fichiers de configuration ne seront pas transférés entre les appareils si vous copier le répertoire contenant l'exécutable de Godot. Consultez Chemins d'accès aux fichiers dans les projets Godot pour plus d'information.

Si un fonctionnement véritablement portable est désirée (ex : pour utilisation sur une clé USB), suivez les étapes décrites dans Mode autonome.

Pourquoi Godot privilégie Vulkan et OpenGL plutôt que Direct3D ?

Godot vise avant tout la compatibilité multi-plateformes et les normes ouvertes. OpenGL et Vulkan sont des technologies qui sont à la fois ouvertes et disponibles sur toutes les plates-formes (ou presque). Grâce à cette décision de conception, un projet développé avec Godot sur Windows fonctionnera sans problème sur Linux, macOS, et plus encore.

While Vulkan and OpenGL remain our primary focus for their open standard and cross-platform benefits, Godot 4.3 introduced experimental support for Direct3D 12. This addition aims to enhance performance and compatibility on platforms where Direct3D 12 is prevalent, such as Windows and Xbox. However, Vulkan and OpenGL will continue as the default rendering drivers on all platforms, including Windows.

Pourquoi Godot s'efforce-t-il de garder peu de fonctionnalités de base ?

Godot n'inclut pas intentionnellement des fonctionnalités qui peuvent être implémentées par des add-ons à moins qu'elles ne soient utilisées très souvent. Un exemple de ceci serait une fonctionnalité d'intelligence artificielle avancée.

Il y a plusieurs raisons à cela :

Maintien du code et recherche de bogues. Chaque fois que nous acceptons du nouveau code dans le dépôt Godot, les contributeurs existants prennent souvent la responsabilité de le maintenir. Certains contributeurs ne restent pas toujours dans les parages après avoir fait fusionner leur code, ce qui peut rendre difficile la maintenance du code en question. Cela peut conduire à des fonctionnalités mal maintenues avec des bogues qui ne sont jamais corrigés. En outre, la "surface de l'API" qui doit être testée et contrôlée pour éviter les régressions ne cesse d'augmenter au fil du temps.
Facilité de contribution. En gardant la codebase petite et ordonnée, elle peut rester rapide et facile à compiler à partir des sources. Il est ainsi plus facile pour les nouveaux contributeurs de se lancer dans Godot, sans qu'ils aient à acheter du matériel haut de gamme.
Garder la taille du binaire de l'éditeur à un faible niveau Tout le monde ne dispose pas d'une connexion Internet rapide. S'assurer que tout le monde peut télécharger l'éditeur Godot, l'extraire et l'exécuter en moins de 5 minutes rend Godot plus accessible aux développeurs de tous les pays.
Maintenir une petite taille du fichier binaire pour les modèles d'exportation. Cela a un impact direct sur la taille des projets exportés avec Godot. Sur les plates-formes mobiles et web, il est primordial de maintenir des fichiers de petite taille pour garantir une installation et un chargement rapides sur les appareils peu puissants. Encore une fois, il existe de nombreux pays où l'Internet à haut débit n'est pas facilement disponible. En outre, des plafonds stricts d'utilisation des données sont souvent en vigueur dans ces pays.

Pour les raisons ci-dessus, nous nous devons d'être sélectifs quant aux fonctionnalités à considérer comme essentielles dans Godot. C'est pourquoi nous avons l'intention de déplacer certaines fonctionnalités essentielles vers des modules complémentaires officiellement pris en charge dans les futures versions de Godot. En termes de taille de binaire, cela a également l'avantage de vous faire payer uniquement pour ce que vous utilisez réellement dans votre projet. (En attendant, vous pouvez compiler des modèles personnalisés sans les fonctionnalités inutilisées pour optimiser la taille de distribution de votre projet.)

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.

Choisissez une seule résolution de base pour votre jeu. Même s'il y a des appareils qui vont jusqu'à 1440p 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 les temps de chargement seront long.
Utilisez les options d'étirement dans Godot ; étirer les élément du canevas en gardant leurs proportions est l'une de vos meilleures options. Consultez le tutoriel Résolutions multiples pour savoir comment y parvenir.
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.
Pour les interfaces utilisateur, utilisez l'anchoring 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.

Quand sortira la prochaine version de Godot ?

Quand elle sera prête ! Voir Quand sortira le prochain version ? pour plus d'informations.

Quelle version de Godot devrais-je utiliser pour un nouveau projet ?

Nous recommandons l'utilisation de Godot 4.x pour les nouveaux projets, mais en fonction des fonctionnalités dont vous avez besoin, il serait peux-être mieux d'utiliser Godot 3.x . Voir Quelle version dois-je utiliser pour un nouveau projet ? pour plus d'informations.

Devrais-je mettre à jour mon projet pour utiliser les nouvelles versions de Godot ?

Certaines mises à jour logicielles sont plus sûr à faire que d'autre. De manière générale, faire une mise à jour ou non dépends des circonstance de votre projet. Voir Dois-je mettre à niveau mon projet pour utiliser les nouvelles versions du moteur ? pour plus d'informations.

Should I use the Forward+, Mobile, or Compatibility renderer?

You can find a detailed comparison of the renderers in Renderers.

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

Génial ! En tant que projet open source, Godot se nourrit de l'innovation et de l'ambition des développeuses et développeurs comme vous.

Le meilleur moyen de commencer à contribuer à Godot est de l'utiliser et de signaler les quelconques problèmes que vous pourriez rencontrer. Un bon rapport d'erreur avec des étapes de reproduction claires permet aux autres contributeur de corriger les bugs rapidement et efficacement. Vous pouvez aussi signaler les problèmes que vous trouvez dans la documentation en ligne.

Si vous vous sentez prêt à soumettre votre première pull request (PR), choisissez n'importe quel problème qui vous intéresse parmi les liens ci-dessus et essayez de le résoudre. Vous devrez apprendre comment compiler le moteur à partir des sources ou comment construire la documentation. Vous devrez également vous familiariser avec Git, un système de gestion de version utilisé par les développeurs de Godot.

Nous expliquons comment travailler avec la source du moteur, comment éditer la documentation, et quelles autres façons de contribuer sont disponibles dans notre documentation pour les contributeurs.

Est-il possible d'utiliser Godot pour créer des applications sans rapport avec le jeu vidéo ?

Oui ! Godot dispose d'un système d'interface utilisateur intégré étendu, et la petite taille de distribution de Godot peut en faire une alternative appropriée à des frameworks comme Electron ou Qt.

Lors de la création d'une application sans rapport avec le jeu vidéo, assurez-vous d'activer low-processor mode dans les paramètres du projet pour réduire l'utilisation du CPU et du GPU.

Consultez Material Maker et Pixelorama pour des exemples d'applications open source créées avec Godot.

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.

Quelle boîte à outils d'interface utilisateur Godot utilise-t-il ?

Godot n'utilise pas de boîte à outils standard GUI comme GTK, Qt ou wxWidgets. Au lieu de cela, Godot utilise sa propre boîte à outils d'interface utilisateur, rendue à l'aide d'OpenGL ES ou de Vulkan. Cette boîte à outils est exposée sous la forme de nœuds Control, qui sont utilisés pour rendre l'éditeur (qui est écrit en C++). Ces nœuds Control peuvent également être utilisés dans des projets à partir de n'importe quel langage de script pris en charge par Godot.

Cette boîte à outils personnalisée permet de bénéficier de l'accélération matérielle et d'avoir une apparence cohérente sur toutes les plateformes. En plus de cela, il n'y a pas à gérer les réserves de la licence LGPL fournies avec GTK ou Qt. Enfin, cela signifie que Godot "mange sa propre nourriture pour chiens" puisque l'éditeur lui-même est l'un des utilisateurs les plus complexes du système d'interface utilisateur de Godot.

Cette boîte à outils d'interface utilisateur personnalisée ne peut pas être utilisée comme bibliothèque, mais vous pouvez toujours utiliser Godot pour créer des applications sans rapport au jeu vidéo en utilisant l'éditeur.

Pourquoi Godot utilise-t-il le système de construction SCons ?

Godot utilise le moteur de production SCons . Il n'est pas prévu de changer de moteur de production dans un futur proche. Nous avons choisi SCons plutôt qu'une de ses alternatives pour beaucoup de raisons. Par exemple :

Godot peut être compilé pour une douzaine de plates-formes différentes : toutes les plates-formes PC, toutes les plates-formes mobiles, de nombreuses consoles, et WebAssembly.
Les développeurs ont souvent besoin de compiler pour plusieurs des plateformes en même temps, ou même différentes cibles de la même plateforme. Ils ne peuvent pas se permettre de reconfigurer et de reconstruire le projet à chaque fois. SCons peut le faire sans problème, sans casser les constructions(builds).
SCons ne brisera jamais une construction(build), quel que soit le nombre de modifications, de configurations, d'ajouts, de suppressions, etc.
Le processus de construction(build) de Godot n'est pas simple. Plusieurs fichiers sont générés par du code (binders), d'autres sont analysés (shaders), et d'autres encore doivent offrir de la personnalisation (modules). Cela nécessite une logique complexe qui est plus facile à écrire dans un langage de programmation réel (comme Python) plutôt que d'utiliser un langage principalement basé sur des macros et uniquement destiné à la construction(building).
Le processus de construction Godot fait un usage intensif des outils de compilation croisée. Chaque plate-forme dispose d'un processus de détection spécifique, et tous ces éléments doivent être traités comme des cas spécifiques avec un code spécial écrit pour chacune.

Essayez de garder l'esprit ouvert et de vous familiariser au moins un peu avec SCons si vous envisagez de construire Godot vous-même.

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 (à quelques exceptions près comme les primitives de multi-tâche). 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, les exceptions augmentent considérablement la taille binaire de l’exécutable et entraînent des temps de compilation plus longs.

Est-ce-que Godot utilise un ECS (Système de composants d'entité) ?

Godot n'utilise pas un ECS et utilise l'héritage à la place. Bien qu'il n'y ait pas d'approche universellement meilleure, nous avons constaté que l'utilisation d'une approche fondée sur l'héritage avait entraîné une meilleure utilisabilité tout en étant suffisamment rapide pour la plupart des cas d'utilisation.

That said, nothing prevents you from making use of composition in your project by creating child Nodes with individual scripts. These nodes can then be added and removed at runtime to dynamically add and remove behaviors.

Plus d'informations sur les choix de conception de Godot peuvent être trouvées dans cet article.

Pourquoi Godot ne force-t-il pas ses utilisateurs a implémenter le DOD ("Data-Oriented Design", conception orientée données) ?

Bien que Godot tente en interne d'exploiter le plus possible la cohérence du cache, nous pensons qu'il ne faut pas forcer les utilisateurs à utiliser des pratiques DOD.

Le DOD repose principalement sur une optimisation de la cohérence du cache, qui ne peut apporter d'améliorations significatives des performances que lorsque vous vous retrouver à manipuler des dizaines de milliers d'objets, traités à chaque frame et peu modifiés. Dans le cas où vous ne déplacez quelques centaines de sprites d'ennemis par frame, le DOD n'améliorera que peu les performances de votre jeu. Il serait alors préférable de reconsidérer votre choix d'optimisation des données.

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 un jeu requiert le traitement d'un aussi grand nombre d'objets, nous vous recommandons d'utiliser du C++ et des GDExtensions pour les tâches les plus gourmandes en performances, et du GDScript ou du C# pour le reste du jeu.

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

Voir Comment contribuer.

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

Voir la page correspondante sur le site web de Godot.