Preguntas Frecuentes

¿Qué puedo hacer con Godot? ¿Cuánto cuesta? ¿Dónde están los términos de licencia?

Godot es un Software libre y de código abierto disponible bajo la licencia MIT aprobada por la OSI . Esto significa que es gratuito en el sentido de "libertad de expresión" así como en "libre acceso."

En pocas palabras:

Eres libre de descargar y usar Godot para cualquier propósito: personal, sin ánimo de lucro, comercial o de otro tipo.
Eres libre de modificar, distribuir, redistribuir y mezclar Godot como quieras, por cualquier razón, ya sea no comercial o comercialmente.

Todo el contenido que acompaña esta documentación está publicado bajo la licencia permisiva Creative Commons Attribution 3.0 (CC-BY 3.0), con atribución a "Juan Linietsky, Ariel Manzur y la comunidad Godot Engine."

Los logos e iconos están generalmente bajo la misma licencia Creative Commons. Ten en cuenta que algunas bibliotecas de terceros, incluídas en el código fuente de Godot, pueden tener licencias diferentes.

Para más detalles, revisa los archivos COPYRIGHT.txt al igual que LICENSE.txt y LOGO_LICENSE.txt en el repositorio de Godot.

Mira también la página de la licencia en el sitio web de Godot.

¿Que plataformas soporta Godot?

Para el editor:

Windows
macOS
Linux, *BSD
Android (experimental)
Web (experimental)

Para exportar tus juegos:

Windows
macOS
Linux, *BSD
Android
iOS
Web

Binarios de 32 y 64 bits son soportados donde corresponda, siendo la de 64 bits la predeterminada. Binarios oficiales para macOS soportan Apple Silicon de manera nativa así como x86_64.

Algunos usuarios también reportan haber compilado y usado Godot en sistemas basados en ARM con Linux, como la Raspberry Pi.

El equipo de Godot no puede proporcionar una exportación de código abierto a consolas debido a los términos de licencia impuestos por los fabricantes de las mismas. Independientemente del motor que use, lanzar juegos en consolas siempre implica mucho trabajo. Puedes leer más sobre eso aquí Soporte de consolas en Godot.

Para más información sobre este tema, consulta las secciones sobre exportación y compilación de Godot.

Nota

Godot 3 también tenía soporte para la Plataforma universal de Windows (UWP). Este puerto de la plataforma se eliminó en Godot 4 debido a la falta de mantenimiento y Microsoft lo dejó obsoleto. Todavía está disponible en la versión estable actual de Godot 3 para los usuarios que estén interesados.

¿Qué lenguajes de programación están soportados en Godot?

Los lenguajes soportados oficialmente por Godot son GDScript, C# y C++. Consulta las subcategorías para cada lenguaje en la sección de scripting.

Si estás empezando con Godot o con el desarrollo de juegos en general, GDScript es el lenguaje recomendado para aprender y usar ya que es nativo de Godot. Mientras que los lenguajes de scripting tienden a ser menos eficientes que los lenguajes de bajo nivel a largo plazo, para la creación de prototipos, el desarrollo de Productos Mínimos Viables (MVPs) y el enfoque en el Plazo de Comercialización (TTM), GDScript proveerá de una manera rápida, amigable y capaz para el desarrollo de tus videojuegos.

Hay que tener en cuenta que el soporte para C# todavía es relativamente nuevo y, como tal, es posible que encuentres algunos inconvenientes en el camino. El soporte de C# también no tiene soporte para plataforma wev. Nuestra amigable y trabajadora comunidad de desarrollo siempre está dispuesta a abordar nuevos problemas a medida que surjan, pero como se trata de un proyecto de código abierto, recomendamos que primero hagas tú mismo las comprobaciones necesarias. Buscar en las discusiones sobre problemas abiertos es una buena manera de empezar a resolver problemas.

En cuanto a los nuevos lenguajes, el soporte es posible a través de terceros utilizando las funciones GDExtension. (Véase la pregunta sobre los plugins más abajo.) Se está trabajando, por ejemplo, en los conectores no oficiales de Godot a Python y Nim.

¿Qué es GDScript y por qué debería usarlo?

GDScript es el lenguaje de scripting integrado de Godot. Fue desarrollado desde cero para maximizar el potencial de Godot con la mínima cantidad de código, permitiendo que tanto desarrolladores principiantes como expertos aprovechen sus ventajas rápidamente. Si alguna vez has escrito algo en un lenguaje como Python, te sentirás como en casa. Para ver ejemplos y una descripción completa de las posibilidades que ofrece GDScript, consulta la Guía de scripting de GDScript.

Hay varias razones para usar GDScript, Pero la razón más sobresaliente es la reducción de complejidad.

La intención original de crear un lenguaje de scripts estrechamente integrado para Godot tenía dos propósitos: primero, reduce la cantidad de tiempo necesaria para prepararse y arrancar con Godot, dando a los desarrolladores una manera rápida de exponerse al motor con un enfoque en la productividad; segundo, reduce la carga de mantenimiento en general, atenúa la dimensión de los problemas y permite a los desarrolladores enfocarse en deshacerse de bugs y mejorar características relacionadas al núcleo del motor, en vez se pasar un montón de tiempo tratando de hacer funcionar un pequeño conjunto de características incrementales a través de diferentes lenguajes.

Dado que Godot es un proyecto de código abierto, era imperativo desde el principio priorizar una experiencia más integrada y sin fisuras por encima de la atracción de usuarios adicionales mediante el soporte de lenguajes de programación más familiares, especialmente cuando el soporte de esos lenguajes más familiares resultaría en una experiencia peor. Entendemos si prefieres usar otro lenguaje en Godot (ver lista de opciones soportadas arriba). Dicho esto, si no has probado GDScript, inténtalo durante tres días. Al igual que Godot, una vez que veas lo poderoso que es y lo rápido que se vuelve tu desarrollo, creemos que GDScript te gustará.

Puedes encontrar más información sobre GDScript, y los lenguajes de tipo dinámico en general, en el tutorial GDScript: Introducción a los lenguajes dinámicos.

¿Cuáles son las motivaciones detrás de la creación de GDScript?

En los primeros días, el motor utilizaba el lenguaje de scripting Lua <https://www.lua.org> __. Lua puede ser rápido debido a LuaJIT, pero crear enlaces a un sistema orientado a objetos (mediante el uso de retrocesos) fue complejo y lento y requirió una enorme cantidad de código. Después de algunos experimentos con Python <https://www.python.org> __, también resultó difícil de insertar.

Las razones principales para crear un lenguaje de scripts personalizado para Godot fueron:

No hay buen soporte de hilos en la mayoría de las VMs, y Godot usa hilos (Lua, Python, Squirrel, JavaScript, ActionScript, etc.).
El bajo soporte para extensión de clases en la mayoria de las VMs de scripts, y adaptarlos a la forma en que Godot funciona es altamente ineficiente (Lua, Python, JavaScript).
Muchos lenguajes existentes tienen interfaces horribles para enlazar a C++, lo que resulta en una gran cantidad de código, errores, cuellos de botella e ineficiencia general (Lua, Python, Squirrel, JS, etc.). Queríamos centrarnos en un gran motor, no en una gran cantidad de integraciones.
No hay tipos nativos para vectores (Vector3, Transform3D, etc.), lo que resulta en un desempeño bastante reducido al usar tipos personalizados (Lua, Python, Squirrel, JavaScript, ActionScript, etc.).
El recolector de basura da como resultado paradas o un uso innecesariamente grande de memoria (Lua, Python, JS, AS, etc.).
Dificultad para integrarse con el editor de código para proporcionar completado de código, edición en vivo, etc. (todos ellos).

GDScript fue diseñado para acabar con los problemas anteriores y más.

¿Qué lenguajes de programación es mas rapido?

En la mayoría de juegos, el lenguaje de scripting no es en si mismo la causa de los problemas de rendimiento. Es probable que un rendimiento pobre se deba al uso de algoritmos ineficientes (lentos con independencia del lenguaje usado), al rendimiento de la GPU, o al código común del motor C++, como el responsable de la física y la navegación. Todos los lenguajes soportados por Godot son lo suficientemente rápidos para tareas de scripting de propósito general. Deberías elegir un lenguaje en función de otros factores, como la facilidad de uso, familiaridad, soporte de la plataforma o las prestaciones del lenguaje.

En general, el rendimiento de C# y GDScript está dentro del mismo orden de magnitud, siendo C++ más rápido que ambos.

Comparar el rendimiento de GDScript y C# no es sencillo, debido a que C# puede ser más rápido en casos específicos. C# por si mismo suele ser más rápido que GDSCript, lo que significa que C# puede ser más rápido en situaciones donde se realicen pocas llamadas al motor de Godot. Sin embargo, C# puede ser más lento que GDScript cuando se producen muchas llamadas a la API de Godot, debido al coste del marshalling. El rendimiento de C# también puede verse afectado por el recolector de basura, que entra en funcionamiento en momentos aleatorios e impredecibles. Esto puede dar lugar a problemas de tartamudeo en proyectos complejos, y no es exclusivo de Godot.

C++, utilizando GDExtension,casi siempre será más rápido que C# o GDScript. Sin embargo, C++ no es tan fácil de usar como C# o GDScript y es más lento desarrollar con este lenguaje.

También puedes utilizar varios idiomas dentro de un solo proyecto, con cross-language scripting, o usando GDExtension y scripting idiomas juntos. Ten en cuenta que hacerlo viene con sus propias complicaciones.

¿Qué tipo de formatos para modelos 3D soporta Godot?

Puedes encontrar información detallada sobre los formatos admitidos, cómo exportarlos desde su software de modelado 3D y cómo importarlos para Godot en la documentación Importando escenas 3D.

¿Será [Inserte aquí un SDK cerrado como PhysX, GameWorks, etc.] soportado por Godot?

El objetivo de Godot es crear un motor con licencia MIT, libre y de código abierto que sea modular y ampliable. No hay planes para que la comunidad central de desarrollo de motores admita ningún SDK de código cerrado/propietario de terceros, ya que la integración con ellos iría en contra del espíritu de Godot.

Dicho esto, como Godot es de código abierto y modular, nada te impide a ti ni a nadie interesado en añadir esas bibliotecas como módulo y distribuir tu juego con ellas, ya sea como código abierto o como código cerrado.

Para ver cómo se puede seguir ofreciendo soporte para el SDK de tu elección, consulta la sección de Plugins a continuación.

Si conoces algún SDK de terceros que no es soportado por Godot, pero que ofrece integración gratuita y de código abierto, considera iniciar el trabajo de integración por ti mismo. Godot no es propiedad de una persona; pertenece a la comunidad y crece junto con los contribuyentes ambiciosos de la comunidad, como tú.

¿Cómo puedo extender Godot?

Para extender Godot, como crear plugins de Godot Editor o añadir soporte para lenguajes adicionales, echa un vistazo a EditorPlugins y tool scripts.

Mira también las publicaciones del blog oficial sobre GDExtension, una manera de desarrollar extensiones nativas para Godot:

Introduciendo el sucesor de GDNative, GDExtension

También puedes revisar la implementación de GDScript, los módulos de Godot, así como la integración del motor de física Jolt para Godot. Este sería un buen punto de partida para ver cómo otra biblioteca de terceros se integra con Godot.

¿Cómo instalo el editor de Godot en mi sistema (para la integración de escritorio)?

Dado que no necesita instalar Godot en su sistema para ejecutarlo, esto significa que la integración del escritorio no se realiza automáticamente. Hay dos formas de superar esto. Puedes instalar Godot desde Steam (todas las plataformas), Scoop (Windows), Homebrew (macOS) o Flathub (Linux). Esto realizará automáticamente los pasos necesarios para la integración de escritorio.

Como alternativa, puedes realizar manualmente los pasos que un instalador haría por ti:

Windows

Mueve el ejecutable de Godot a una ubicación estable (es decir, fuera de tu carpeta de descargas), para que no lo muevas accidentalmente y rompas el acceso directo en el futuro.
Haz click derecho sobre el archivo ejecutable de Godot y selecciona Crear acceso directo.
Mueva el acceso directo creado a %LOCALAPPDATA%\Microsoft\Windows\Start Menu\Programs. Esta es la ubicación de todo el usuario para los accesos directos que aparecerán en el menú Inicio. También puedes anclar a Godot en la barra de tareas haciendo clic con el botón derecho en el ejecutable y seleccionando Anclar a la barra de tareas.

macOS

Arrastra la aplicación Godot extraída a /Applications/Godot.app, luego arrástrala al Dock si lo deseas. Spotlight podrá encontrar a Godot siempre que esté en /Aplicaciones o ~/Aplicaciones.

Linux

Mueve el archivo ejecutable de Godot a una localización definitiva (por ejemplo fuera de tu directorio de descargas), de esta forma después nunca lo moverás accidentalmente y romperás los accesos directos en el futuro.
Renombra y mueve el binario de Godot a una ubicación presente en tu variable de entorno PATH. Esto suele ser /usr/local/bin/godot o /usr/bin/godot. Hacer esto requiere privilegios de administrador, pero también te permite ejecutar el editor de Godot desde una terminal ingresando godot.
- Si no puede mover el binario del editor de Godot a una ubicación protegida, puede mantener el binario en algún lugar de su directorio de inicio y modificar la línea Path= en el archivo .desktop vinculado a continuación para que contenga la ruta absoluta completa al binario de Godot.
Guarda este archivo .desktop en $HOME/.local/ compartir/aplicaciones/. Si tienes privilegios de administrador, también puede guardar el archivo .desktop en /usr/local/share/applications para que el acceso directo esté disponible para todos los usuarios.

¿El editor de Godot es una aplicación portátil?

En su configuración por defecto, Godot es semi-portátil. Su ejecutable puede ejecutarse desde cualquier ubicación (incluidas las ubicaciones en las que no se puede escribir) y nunca requiere privilegios de administrador.

Sin embargo, los archivos de configuración se escribirán en el directorio de datos o configuración de todo el usuario. Este suele ser un buen enfoque, pero esto significa que los archivos de configuración no se transferirán a través de las máquinas si copia la carpeta que contiene el ejecutable de Godot. Consulta Rutas de archivo en proyectos de Godot para obtener más información.

Si se desea una operación portátil verdadera (por ejemplo, para usar en una memoria USB), siga los pasos en Modo autónomo.

¿Por qué Godot da prioridad a Vulkan y OpenGL frente a Direct3D?

Godot busca compatibilidad entre plataformas y estándares abiertos como primero y principal. OpenGL y Vulkan son las tecnologías, que, en simultáneo, son abiertas y se encuentran disponibles en (casi) todas las plataformas. Gracias a esta decisión de diseño, un proyecto desarrollado con Godot en Windows funcionará inmediatamente en Linux, macOS, y más.

Si bien Vulkan y OpenGL siguen siendo nuestro principal objetivo por sus ventajas de estándar abierto y multiplataforma, Godot 4.3 introdujo compatibilidad experimental con Direct3D 12. Esta incorporación busca mejorar el rendimiento y la compatibilidad en plataformas donde Direct3D 12 es predominante, como Windows y Xbox. Sin embargo, Vulkan y OpenGL seguirán siendo los controladores de renderizado predeterminados en todas las plataformas, incluido Windows.

¿Por qué Godot tiene como objetivo mantener a baja escala sus características principales?

Godot no incluye intencionadamente características que puedan ser implementadas por addons, a menos que se utilicen muy a menudo. Un ejemplo de esto sería la funcionalidad de inteligencia artificial avanzada.

Hay varias razones para esto:

Mantenimiento de código y superficie para errores. Cada vez que aceptamos nuevo código en el repositorio de Godot, los colaboradores existentes a menudo toman la reponsibilidad de mantenerlo. Algunos colaboradores no siempre se quedan después de combinar su código, lo que puede dificultar que mantengamos el código en cuestión. Esto puede conducir a características mal mantenidas con errores que nunca se corrigen. Además de eso, la "superficie de la API" que debe probarse y comprobarse en busca de regresiones sigue aumentando con el tiempo.
Facilidad de contribución. Al mantener la base de código pequeña y ordenada, puede permanecer rápido y fácil de compilar desde el origen. Esto hace que sea más fácil para los nuevos contribuidores comenzar con Godot, sin necesidad de que compren hardware de gama alta.
Mantener pequeño el peso del ejecutable del editor. No todos tienen una conexión a internet rapida. Asegurando que todos puedan descargar el editor de Godot, extraerlo y ejecutarlo en menos de 5 minutos hace a Godot mas accesible a desarrolladores en todos los países.
Mantener el tamaño pequeño de las plantillas de exportación. Esto impacta directamente al tamaño de los proyectos exportados con Godot. En los dispositivos moviles y plataformas web, mantener el tamaño pequeño de los archivos es primordial para garantizar una rapida instalación y tiempos de carga cortos en dispositivos poco potentes. De nuevo, hay muchos paises en los que no se dispone de internet de alta velocidad. Para añadir a esto, estrictos limites de bajada afectan a estos países.

Por todas las razones anteriores, tenemos que ser selectivos con lo que podemos aceptar como funcionalidad central en Godot. Es por eso que nuestro objetivo es mover algunas funciones básicas a extensiones oficialmente soportadas en las futuras versiones de Godot. En términos de tamaño binario, también tiene la ventaja de hacer que pague solamente por lo que en realidad usa Si modificas . (Por el momento, puede Compilar plantillas de exportación personalizadas con características sin usar desactivadas para optimizar el tamaño de distribución de su proyecto.)

¿Cómo deberían crearse los recursos para manejar múltiples resoluciones y relaciones de aspecto?

Esta pregunta surge a menudo y es probablemente gracias al malentendido creado por Apple cuando ellos originalmente doblaron la resolución de sus dispositivos. Esto hizo creer a la gente que tener los mismos recursos en diferentes resoluciones era una buena idea, por lo tanto muchos siguieron ese camino. Eso originalmente funcionó hasta un punto y solo para dispositivos Apple, pero después, se crearon muchos dispositivos Android y Apple con diferentes resoluciones y relaciones de aspecto, con una gran variedad de tamaños y DPIs.

La forma más común y correcta de conseguirlo es, en su lugar, utilizar una única resolución base para el juego y manejar únicamente diferentes relaciones de aspecto de pantalla. Esto es necesario sobre todo para 2D, ya que en 3D es sólo cuestión de ajuste del FOV horizontal o vertical de la cámara.

Elige una única resolución base para tu juego. Incluso si hay dispositivos que llegan hasta los 1440p y dispositivos que están por los 400p, el escalado regular del hardware del dispositivo se hará cargo de esto con un costo en el rendimiento bajo o nulo . Las elecciones más comunes son cercanas a 1080p (1920x1080) o 720p (1280x720). Ten en cuenta que cuánto mayor es la resolución, mayor será el tamaño de tus recursos, y esto a su vez aumenta el consumo de memoria y el tiempo de carga.
Usa las opciones de estiramiento en Godot; el estiramiento en canvas funciona mejor si mantienes la relación de aspecto. Consulta el tutorial Múltiples resoluciones para ver sobre cómo conseguir esto.
Determina una resolución mínima y luego decide si quieres que tu juego se extienda vertical u horizontalmente para diferentes relaciones de aspecto, o si hay una relación de aspecto y quieres que aparezcan barras negras en su lugar. Esto también se explica en Múltiples resoluciones.
Para las interfaces de usuario, utiliza el anchoring para determinar hacia donde se deben quedar y mover los controles. Si las interfaces de usuario son más complejas, considera aprender sobre los Containers.

Y eso es todo! Tu juego debería funcionar en múltiples resoluciones.

¿Cuándo sale la proxima versión de Godot?

¡Cuando esté lista! Véase ¿Cuándo sale el próximo lanzamiento? para más información.

¿Qué versión de Godot debería usar para un nuevo proyecto?

Recomendamos usar Godot 4.x para proyectos nuevos, pero, según las características que necesite, puede ser mejor usar la versión 3.x. Consulta ¿Qué versión debería usar para un proyecto nuevo? para más información.

¿Debería actualizar mi proyecto para usar nuevas versiones de Godot?

Algunas versiones nuevas son más seguras para actualizar a que otras. En general, la decision de actualizar depende de las circunstancias de su proyecto. Revisa ¿Debería actualizar mi proyecto a una versión nueva del motor? for more information.

¿Debería utilizar el renderizador Forward+, Mobile o Compatibility?

Puedes encontrar una comparación detallada de los renderizadores en Overview of renderers.

¡Me gustaría contribuir! ¿Por dónde empiezo?

¡Fantástico! Como proyecto de código abierto, Godot prospera con la innovación y ambición de desarrolladores como tú.

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 te sientes listo para enviar tu primer PR, elige cualquier problema que resuene contigo de uno de los enlaces arriba e intenta arreglarlo. Tendrás que aprender cómo compilar el motor desde su codigo fuente, o cómo construir la documentación. También necesitas familiarizarte con Git, un sistema de control de versiones que usan los desarrolladores de Godot.

Explicamos cómo trabajar con el código fuente del motor, cómo editar la documentación y qué otras formas de contribuir existen en nuestra documentación para contribuyentes.

Es posible usar Godot para ¿hacer aplicaciones que no son juegos?

¡Si! Las características de Godot, el extenso sistema de UI embebido en el motor y el pequeño tamaño de la distribución de Godot puede hacer que sea una alternativa adecuada a los frameworks como Electrón o el Qt.

Cuando crees una aplicación que no sea de juego, asegúrate de habilitarla low-processor mode en la configuración del proyecto para reducir el uso de la CPU y la GPU.

Mira Material Maker y Pixelorama para ejemplos de aplicaciones de código abierto hechas con Godot.

¿Es posible usar Godot como una biblioteca?

Godot está destinado a ser usado con su editor. Le recomendamos que lo pruebe, ya que probablemente le ahorrará tiempo a largo plazo. No hay planes para hacer que Godot sea utilizable como una biblioteca, ya que haría el resto del motor más enrevesado y difícil de usar para usuarios ocasionales.

Si quieres usar una biblioteca de renderizado, busca en su lugar un motor de renderizado orientado a ello. Ten en cuenta que los motores de renderizado suelen tener comunidades más pequeñas en comparación con Godot. Esto hará más difícil encontrar respuestas a tus preguntas.

¿Qué kit de herramientas para la interfaz de usuario usa Godot?

Godot no utiliza un kit de herramientas GUI estándar como GTK, Qt o wxWidgets. En su lugar, Godot utiliza su propio kit de herramientas de interfaz de usuario, que se renderiza utilizando OpenGL ES o Vulkan. Este conjunto de herramientas se expone en forma de nodos de control, que se utilizan para renderizar el editor (que está escrito en C++). Estos nodos de control también pueden ser utilizados en proyectos de cualquier lenguaje de scripting soportado por Godot.

Este kit de herramientas personalizado permite beneficiarse de la aceleración por hardware y tener una apariencia consistente en todas las plataformas. Además, no tiene que lidiar con las advertencias de la licencia LGPL que vienen con GTK o Qt. Por último, esto significa que Godot se está "comiendo su propia comida de perro", ya que el propio editor es uno de los usuarios más complejos del sistema de interfaz de usuario de Godot.

Este kit de herramientas de interfaz de usuario no puede usarse como biblioteca, pero sí puede utilizar Godot para crear aplicaciones que no son juegos mediante el uso del editor.

¿Por qué Godot no usa el sistema de construcción SCons?

Godot utiliza el __ sistema de construcción SCons <https://www.scons.org/>. No hay planes para cambiar a un distinto sistema de construcción en un futuro cercano. Hay muchas razones por las que elegimos SCons sobre otras opciones. Por ejemplo:

Godot se puede compilar para una docena de plataformas diferentes: todas las plataformas de PC, todas las plataformas móviles, muchas consolas y WebAssembly.
Los desarrolladores a menudo necesitan compilar para varias de las plataformas al mismo tiempo, o incluso para diferentes objetivos de la misma plataforma. No pueden permitirse reconfigurar y reconstruir el proyecto cada vez. SCons puede hacer esto sin problemas, sin romper las compilaciones.
SCons nunca romperá una compilación sin importar cuántos cambios, configuraciones, adiciones o eliminaciones etc. haya.
El proceso de compilación de Godot no es sencillo. Varios archivos se generan mediante código (vinculadores), otros se analizan (shaders) y otros requieren personalización (modules). Esto requiere una lógica compleja, que es más fácil de escribir en un lenguaje de programación real (como Python) que usar un lenguaje basado principalmente en macros y diseñado exclusivamente para compilación.
El proceso de compilación de Godot hace un uso intensivo de herramientas de compilación cruzada. Cada plataforma tiene un proceso de detección específico, y todos estos deben tratarse como casos específicos con código especial escrito para cada uno.

Entonces, por favor, trata de mantener una mente abierta y familiarizarte al menos un poco con SCons si tienes la intención de compilar Godot por ti mismo.

¿Por qué Godot no usa STL (Standard Template Library)?

Así como muchas otras bibliotecas (por ejemplo Qt), Godot no hace uso de STL (con algunas excepciones como con primitivas para hilos). Creemos que STL es una gran biblioteca de propósito general, pero tuvimos requerimientos especiales para Godot.

Las plantillas STL crean símbolos muy grandes, lo que da como resultado, enormes binarios de depuración. En cambio, utilizamos pocas plantillas con nombres muy cortos en su lugar.
La mayoría de nuestros contenedores satisfacen necesidades especiales, como Vector, que usa copia en escritura y nosotros lo usamos para pasar datos, o el sistema RID, que requiere tiempo de acceso O (1) para el rendimiento. Del mismo modo, nuestras implementaciones de mapas hash están diseñadas para integrarse perfectamente con los tipos usados internamente por el motor.
Nuestros contenedores tienen seguimiento de memoria incorporado, lo que ayuda a rastrear mejor el uso de memoria.
Para grandes arrays, usamos pooled memory, la cual puede ser mapeada directamente a un buffer prealocado o a memoria virtual.
Usamos nuestro propio tipo de String, puesto que el que provee STL es demasiado básico y carece de soporte para internacionalización.

Revisar Godot's container types para alternativas.

Por qué Godot no usa excepciones?

Creemos que los juegos no deben fallar no importa la situación. Si una situación inesperada sucede, Godot mostrara un error (el cual puede incluso llevarte al script), pero seguidamente intentara recuperarse lo mejor posible y continuar en la medida de lo posible.

Adicionalmente, las excepciones aumentan significativamente el tamaño binario del ejecutable y también resulta en tiempos de compilación mayores.

¿Godot utiliza un ECS (Sistema de Componentes de Entidad)?

Godot no usa un ECS y se basa en la herencia en su lugar. Si bien no existe un enfoque universalmente mejor, descubrimos que el uso de un enfoque basado en la herencia dio como resultado una mejor usabilidad y, al mismo tiempo, lo suficientemente rápido para la mayoría de los casos de uso.

Dicho esto, nada impide usar la composición en tu proyecto creando nodos secundarios con scripts individuales. Estos nodos pueden añadirse y eliminarse en tiempo de ejecución para añadir y eliminar comportamientos dinámicamente.

Se puede encontrar más información sobre las opciones de diseño de Godot en este artículo.

¿Por qué Godot no fuerza a los usuarios a implementar DoD (Diseño orientado a Datos)?

Internamente, para muchas de las tareas de alto rendimiento, Godot intenta usar la coherencia de caché lo mejor posible, por lo que creemos que la mayoría de usuarios no necesitan usar prácticas DoD.

DOD es principalmente una optimización de coherencia de caché que solo puede proveer mejoras significativas en el rendimiento cuando se trata de docenas de miles de objetos que se procesan en cada cuadro con poca modificación. Es decir, si estás moviendo unos pocos cientos de sprites o enemigos por cuadro, DOD no resultará en una mejora significativa en el rendimiento. En ese caso, deberás considerar un enfoque diferente para la optimización.

La gran mayoría de juegos no necesitan esto y Godot proporciona ayudas practicas para hacer el trabajo en la mayoría de los casos en que lo necesites.

Si algún juego necesita procesar una cantidad realmente grande de objetos, nuestra recomendación es usar C++ y GDNative para las tareas en las que se necesite alto rendimiento y GDScript (o C#) durante el resto del juego.

¿Cómo puedo apoyar el desarrollo de Godot o contribuir?

Ver Cómo contribuir.

¿Quien esta trabajando en Godot? ¿Como puedo ponerme en contacto?

Mira la pagina correspondiente en el sitio web de Godot.