Up to date

This page is up to date for Godot 4.2. If you still find outdated information, please open an issue.

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

Both 32- and 64-bit binaries are supported where it makes sense, with 64 being the default. Official macOS builds support Apple Silicon natively as well as 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 je jeux pour console open-source à cause des termes de licence imposées par les fabricants de la console. 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.

Note that C# support is still relatively new, and as such, you may encounter some issues along the way. C# support is also currently missing on the web platform. Our friendly and hard-working development community is always ready to tackle new problems as they arise, but since this is an open source project, we recommend that you first do some due diligence yourself. Searching through discussions on open issues is a great way to start your troubleshooting.

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 is Godot's integrated scripting language. It was built from the ground up to maximize Godot's potential in the least amount of code, affording both novice and expert developers alike to capitalize on Godot's strengths as fast as possible. If you've ever written anything in a language like Python before, then you'll feel right at home. For examples and a complete overview of the power GDScript offers you, check out the GDScript scripting guide.

L'utilisation de GDScript présente de nombreux avantages lors du prototypage dans les phases alpha/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.

The original intent of creating a tightly integrated, custom scripting language for Godot was two-fold: first, it reduces the amount of time necessary to get up and running with Godot, giving developers a rapid way of exposing themselves to the engine with a focus on productivity; second, it reduces the overall burden of maintenance, attenuates the dimensionality of issues, and allows the developers of the engine to focus on squashing bugs and improving features related to the engine core, rather than spending a lot of time trying to get a small set of incremental features working across a large set of languages.

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

  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. Many existing languages have horrible interfaces for binding to C++, resulting in a large amount of code, bugs, bottlenecks, and general inefficiency (Lua, Python, Squirrel, JavaScript, etc.). We wanted to focus on a great engine, not a great number of integrations.

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

  5. Le ramasse-miette entraîne des délais ou une utilisation inutilement importante de la mémoire (Lua, Python, JavaScript, ActionScript, etc.).

  6. Difficulty integrating with the code editor for providing code completion, live editing, etc. (all of them).

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

What 3D model formats does Godot support?

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 ?

The aim of Godot is to create a free and open source MIT-licensed engine that is modular and extendable. There are no plans for the core engine development community to support any third-party, closed-source/proprietary SDKs, as integrating with these would go against Godot's ethos.

That said, because Godot is open source and modular, nothing prevents you or anyone else interested in adding those libraries as a module and shipping your game with them, as either open- or closed-source.

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

If you know of a third-party SDK that is not supported by Godot but that offers free and open source integration, consider starting the integration work yourself. Godot is not owned by one person; it belongs to the community, and it grows along with ambitious community contributors like you.

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.

Also, see the official blog post on GDExtension, a way to develop native extensions for Godot:

You can also take a look at the GDScript implementation, the Godot modules, as well as the Jolt physics engine integration for Godot. This would be a good starting point to see how another third-party library integrates with 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 <https://store.steampowered.com/app/404790/Godot_Engine/>'__ (toutes les plates-formes), 'Scoop <https://scoop.sh/>'__ (Windows), 'Homebrew <https://brew.sh/>'__ (macOS) ou 'Flathub <https://flathub.org/apps/details/org.godotengine.Godot>'__ (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.

  • Move the created shortcut to %APPDATA%\Microsoft\Windows\Start Menu\Programs. This is the user-wide location for shortcuts that will appear in the Start menu. You can also pin Godot in the task bar by right-clicking the executable and choosing Pin to Task Bar.

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.

  • Save this .desktop file to $HOME/.local/share/applications/. If you have administrator privileges, you can also save the .desktop file to /usr/local/share/applications to make the shortcut available for all users.

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 utilise-t-il Vulkan ou OpenGL au lieu de Direct3D ?

Godot aims for cross-platform compatibility and open standards first and foremost. OpenGL and Vulkan are the technologies that are both open and available on (nearly) all platforms. Thanks to this design decision, a project developed with Godot on Windows will run out of the box on Linux, macOS, and more.

Comme Godot n'a que quelques personnes qui travaillent sur son moteur de rendu, nous préférerions avoir moins de backends de rendu à maintenir. De plus, l'utilisation d'une API unique sur toutes les plates-formes permet une plus grande cohérence avec moins de problèmes spécifiques à la plate-forme.

In the long term, we may develop a Direct3D 12 renderer for Godot (mainly for Xbox), but Vulkan and OpenGL will remain the default rendering backends on all platforms, including Windows.

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

Godot intentionally does not include features that can be implemented by add-ons unless they are used very often. One example of something not used often is advanced artificial intelligence functionality.

Il y a plusieurs raisons à cela :

  • Code maintenance and surface for bugs. Every time we accept new code in the Godot repository, existing contributors often take the responsibility of maintaining it. Some contributors don't always stick around after getting their code merged, which can make it difficult for us to maintain the code in question. This can lead to poorly maintained features with bugs that are never fixed. On top of that, the "API surface" that needs to be tested and checked for regressions keeps increasing over time.

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

  • Keeping the binary size small for export templates. This directly impacts the size of projects exported with Godot. On mobile and web platforms, keeping file sizes low is important to ensure fast installation and loading on underpowered devices. Again, there are many countries where high-speed Internet is not readily available. To add to this, strict data usage caps are often in effect in those countries.

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.

The most common and proper way to achieve this is to, instead, use a single base resolution for the game and only handle different screen aspect ratios. This is mostly needed for 2D, as in 3D, it's just a matter of camera vertical or horizontal FOV.

  1. Choose a single base resolution for your game. Even if there are devices that go up to 1440p and devices that go down to 400p, regular hardware scaling in your device will take care of this at little or no performance cost. The most common choices are either near 1080p (1920x1080) or 720p (1280x720). Keep in mind the higher the resolution, the larger your assets, the more memory they will take and the longer the time it will take for loading.

  2. Use the stretch options in Godot; canvas items stretching while keeping aspect ratios works best. Check the Résolutions multiples tutorial on how to achieve this.

  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'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 Which version should I use for a new project? pour plus d'informations.

Should I upgrade my project to use new Godot versions?

Some new versions are safer to upgrade to than others. In general, whether you should upgrade depends on your project's circumstances. See Should I upgrade my project to use new engine versions? for more information.

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

Awesome! As an open source project, Godot thrives off of the innovation and the ambition of developers like you.

The best way to start contributing to Godot is by using it and reporting any issues that you might experience. A good bug report with clear reproduction steps helps your fellow contributors fix bugs quickly and efficiently. You can also report issues you find in the online documentation.

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.

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

Nous sommes toujours à la recherche de suggestions pour améliorer le moteur. Les retours des utilisateurs sont la principale force motrice derrière notre processus décisionnel, et les limitations que vous pourriez rencontrer en travaillant sur votre projet sont des données précieuses pour nous lorsque nous envisageons des améliorations du moteur.

Si vous rencontrez un problème d'utilisation ou si vous avez besoin d'une fonctionnalité manquante dans la version actuelle de Godot, commencez par en discuter avec notre communauté community. Il se peut qu'il existe d'autres moyens, peut-être meilleurs, pour obtenir le résultat souhaité, que les membres de la communauté pourraient suggérer. Vous pouvez également découvrir si d'autres utilisateurs rencontrent le même problème et trouver ensemble une bonne solution.

Si vous avez un idée d'amélioration bien définie pour le moteur de jeu, vous pouvez ouvrir un ticket pour la proposer. Essayez d'être précis et concret lorsque vous décrivez votre problème et votre solution — seules les modifications réalisables seront prises en considération. Ce n'est pas obligatoire, mais si vous voulez l'implémenter vous-même, cela sera toujours apprécié !

If you only have a general idea without specific details, you can open a proposal discussion. These can be anything you want, and allow for a free-form discussion in search of a solution. Once you find one, a proposal issue can be opened.

Please, read the readme document before creating a proposal to learn more about the process.

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 uses the SCons build system. There are no plans to switch to a different build system in the near future. There are many reasons why we have chosen SCons over other alternatives. For example:

  • 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 will never break a build no matter how many changes, configurations, additions, removals etc.

  • Godot's build process is not simple. Several files are generated by code (binders), others are parsed (shaders), and others need to offer customization (modules). This requires complex logic which is easier to write in an actual programming language (like Python) rather than using a mostly macro-based language only meant for 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 chacun.

Please try to keep an open mind and get at least a little familiar with SCons if you are planning to build Godot yourself.

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

Like many other libraries (Qt as an example), Godot does not make use of STL (with a few exceptions such as threading primitives). We believe STL is a great general-purpose library, but we had special requirements for 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é.

Additionally, exceptions significantly increase the binary size for the executable and result in increased compile times.

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

Godot does not use an ECS and relies on inheritance instead. While there is no universally better approach, we found that using an inheritance-based approach resulted in better usability while still being fast enough for most use cases.

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 run-time to dynamically add and remove behaviors.

More information about Godot's design choices can be found in this article.

Why does Godot not force users to implement DOD (Data-Oriented Design)?

While Godot internally attempts to use cache coherency as much as possible, we believe users don't need to be forced to use DOD practices.

DOD is mostly a cache coherency optimization that can only provide significant performance improvements when dealing with dozens of thousands of objects which are processed every frame with little modification. That is, if you are moving a few hundred sprites or enemies per frame, DOD won't result in a meaningful improvement in performance. In such a case, you should consider a different approach to optimization.

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.

If a game needs to process such a large amount of objects, our recommendation is to use C++ and GDExtensions for performance-heavy tasks and GDScript (or C#) for the rest of the game.

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.