Up to date

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

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 Licencia MIT. 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 librerías 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)

  • GitHub

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 uses, 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 scripts integrado en Godot. Fue creado desde cero para maximizar el potencial de Godot hasta la última porción de código, permitiendo a desarrolladores tanto expertos como novatos aprovechar las fortalezas de Godot tan rápido como sea posible. Si alguna vez has escrito algo en un lenguaje como Python, entonces te sentirás como en casa. Para ejemplos, la historia y un resumen completo del poder que GDScript te ofrece, revisa la guía de scripting en GDScript.

Hay varias razones para usar GDScript--especialmente cuando estás haciendo prototipos, versiones alfa/beta de tu proyecto, o no estás creando el próximo título AAA. Pero la razón más sobresaliente es la reducción de complejidad en general.

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:

  1. No hay buen soporte de hilos en la mayoría de las VMs, y Godot usa hilos (Lua, Python, Squirrel, JavaScript, ActionScript, etc.).

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

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

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

  5. El recolector de basura da como resultado paradas o un uso innecesariamente grande de memoria (Lua, Python, JS, AS, etc.).

  6. 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é tipo de formatos para modelos 3D soporta Godot?

Puedes encontrar informacion detallada en formatos soportados, como exportarlos de tu software de modelado 3D, y como importarlos a Godot en la :ref:`doc_importing_3d_scenes`documentacion.

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

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

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 librería 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, puede realizar manualmente los pasos que un instalador haría por usted:

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.

  • Guarde este archivo .desktop en $HOME/.local/ compartir/aplicaciones/. Si tiene 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. Consulte 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 usa Vulkan u OpenGL en vez de 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.

Dado que Godot solo cuenta con un pequeño grupo de personas trabajando en el renderer, preferiríamos tener la menor cantidad posible de backends de renderizado posible que mantener. Además, usando una única API para todas las plataformas permite una mayor consistencia con menos problemas específicos de plataforma.

A largo plazo, podríamos desarrollar un renderizador Direct3D 12 para Godot (principalmente para Xbox), pero Vulkan y OpenGL se mantendrán como los backends de renderizado por defecto en todas las plataformas, incluyendo Windows.

¿Por qué Godot tiene como objetivo mantener a baja escala sus caracteristicas principales?

Godot no incluye intencionadamente características que puedan ser implementadas por complementos, 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 soportados en futuras versiones de Godot. En términos de tamaño binario, también tiene la ventaja de hacer que pagues solamente por lo que en realidad usas en tu proyecto. (Por el momento, puedes Compilar plantillas de exportación personalizadas con características sin usar desactivadas para optimizar el tamaño de distribución de tu 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.

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

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

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

  4. 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! Vea ¿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 utilizar Godot 4.x para proyectos nuevos, pero según la característica que necesites, puede ser mejor utilizar 3.x . Revisa doc_póliza_de emisión_qué_versión_tiene que_i_uso 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.

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

La mejor manera de empezar a contribuir a Godot es mediante su uso y reportando cualquier `problema > https://github.com/godotengine/godot/issues ``_ que experimente. Un buen informe de fallos, con pasos claros de reproducción ayuda a los colaboradores a corregir errores de forma rápida y eficiente. También puede informar sobre problemas que encuentre en la `documentación electrónica <https://github.com/godotengine/godot-docs/issues >`_.

Si se siente listo para enviar su primer PR, elija cualquier problema que resuene con usted de uno de los enlaces arriba y intente arreglarlo. Tendrá que aprender cómo compilar el motor desde su codigo fuente, o cómo construir la documentación. También necesita familiarizarse con Git, un sistema de control de versiones que usan los desarrolladores Godot.

Explicamos cómo trabajar con el Core del motor, cómo editar la documentación, y otras alternativas para contribuir puede encontrarlas en documentation for contributors.

Tengo una idea genial para Godot. ¿Cómo puedo compartirla?

Siempre estamos buscando sugerencias sobre cómo mejorar el motor. Los comentarios de los usuarios son la principal fuerza impulsora detrás de nuestro proceso de toma de decisiones, y las limitaciones que puede enfrentar mientras trabaja en su proyecto son un gran punto de datos para nosotros al considerar las mejoras del motor.

Si detecta algún problema de usabilidad o algún componente de Godot faltante en la versión actual, empiece por discutirlo en nuestra comunidad community. Pueden haber otras, incluso mejores, maneras de obtener soluciones propuestas por los miembros de la comunidad. También puede encontrar si otros usuarios han experimentado el mismo problema, e intentar encontrar una solución juntos.

Si tienes una idea bien definida para el motor, siéntete libre de abrir una issue de propuesta. Intenta ser especifico y concreto al describir tu problema y tu solución propuesta — solo las propuestas factibles serán consideradas. No es requerido pero si quieres implementarlas tu mismo, ¡siempre se aprecia!

Si tienes una idea general sin detalles específicos, puedes abrir una propuesta de discusión. Estas pueden ser de lo que quieras, y permiten una forma libre de discusión en busca de una solución, una ves abierta, una propuesta de problema se abrirá.

Por favor, lea el documento léame antes de crear una propuesta para obtener más información sobre el proceso.

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 biblioteca/librería?

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í puedes 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 `SCons <https://www.scons.org/>`__sistema de construcción. 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. Se generan varios archivos a partir de código (vinculadores), otros se analizan (shaders), y otros necesitan ofrecer personalización (:ref:`modules <doc_custom_modules_in_cpp>). Esto requiere lógica compleja que es más fácil de escribir en un lenguaje de programación real (como Python) en lugar de usar un lenguaje basado principalmente en macros destinado únicamente a la compilación.

  • Godot's build process makes heavy use of cross-compiling tools. Each platform has a specific detection process, and all these must be handled as specific cases with special code written for each.

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 librerías (por ejemplo Qt), Godot no hace uso de STL (con algunas excepciones como con primitivas para hilos). Creemos que STL es una gran librería 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.

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 le impide hacer uso de la composición en su proyecto mediante la creación de nodos secundarios con scripts individuales. Estos nodos se pueden agregar y quitar en tiempo de ejecución para agregar y eliminar comportamientos de forma dinámica.

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?

Mira Formas de contribuir.

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

Mira la pagina correspondiente en el sitio web de Godot.