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

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 exporting et la compiling Godot yourself.

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 travailleuse, 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/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 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.

  • Déplacez le raccourci créé vers ''%LOCALAPPDATA%MicrosoftWindowsStart MenuPrograms''. 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 utilise-t-il Vulkan ou OpenGL au lieu de Direct3D ?

Godot vise avant tout la compatibilité multi-plateforme et les normes ouvertes. OpenGL et Vulkan sont les technologies qui sont à la fois ouvertes et disponibles (presque) sur toutes les plates-formes. 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.

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.

À long terme, nous pourrions développer un moteur de rendu Direct3D 12 pour Godot (principalement pour les besoins de la Xbox), mais Vulkan et OpenGL resteront les systèmes de rendu par défaut sur toutes les plateformes, y compris 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 de 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.

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

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.

Quand sortira le prochain version ?

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

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

Cela dit, nous ne recommandons pas d'utiliser Godot pour créer une application mobile, car le mode basse consommation du processeur n'est pas encore pris en charge par les plateformes mobiles.

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 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 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 impacte 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 pour beaucoup de tâches gourmandes en performance Godot tente en interne 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 principalement une optimisation de la cohérence du cache qui ne peut vous apporter des améliorations significatives des performances que lorsque vous l'utilisez pour manipuler des dizaines 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 par frame, 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.