Preguntas Frecuentes

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

Godot es aprobada por la OSI. Esto significa que es libre como en "libre expresión" y gratis como en "cerveza gratis".

En pocas palabras:

  • Eres libre de descargar y usar Godot para cualquier propósito, personal, sin fines de lucro, comercial o de otro tipo.

  • Eres libre para modificar, distribuir, redistribuir y mezclar Godot como quieras, por cualquier razón, ya sea no comercial o comercialmente.

Todos los contenidos de esta documentación acompañante son publicados bajo la permisiva licencia Creative Commons Attribution 3.0 (CC-BY 3.0), con atribución a "Juan Linietsky, Ariel Manzul y a la comunidad de 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 diferentes licencias.

Para más detalles, revisa los archivos 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

  • X11 (Linux, *BSD)

Para exportar tus juegos:

  • Windows (y UWP)

  • macOS

  • X11 (Linux, *BSD)

  • Android

  • iOS

  • Web

Ambos binarios de 32 y 64 bits son compatibles según tu sistema, siendo 64 el predeterminado.

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

Además, hay algunos trabajos no oficiales de terceros que se están llevando a cabo para compilar en algunas consolas. Sin embargo, nada de esto está incluido en los scripts de compilación o en las plantillas de exportación por defecto en este momento.

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

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

Los lenguajes soportados oficialmente por Godot son GDScript, Visual Scripting, C# y C++. Ve 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. 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 GDNative / NativeScript / PluginScript. (Véase la pregunta sobre los plugins más abajo.) Se está trabajando, por ejemplo, en los conectores no oficiales de Godot a 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 scripteo en GDScript.

Hay varias razones para usar GDScript--especialmente cuando estás haciendo prototipos, en 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 es rápido, 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, matrix4, 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). Esto está muy bien soportado por GDScript.

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

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

Godot soporta Collada a través de Exportador mejorado de Collada.

A partir de Godot 3.0, glTF es soportado.

FBX es compatible a través de la biblioteca Open Asset Import. Sin embargo, FBX es propietario, por lo que recomendamos utilizar otros formatos enumerados anteriormente, si son idóneos para su flujo de trabajo.

¿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, justo como vos.

Por qué usa Godot Vulkan o OpenGL en vez de Direct3D?

Godot apunta a la compatibilidad entre plataformas y a los estándares abiertos ante todo. OpenGL y Vulkan son las tecnologías que están abiertas y disponibles (casi) en todas las plataformas. Gracias a esta decisión de diseño, un proyecto desarrollado con Godot en Windows se ejecutará de inmediato 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 para Godot (principalmente para el desarrollo en Xbox), pero Vulkan y OpenGL se mantendrán como los renderizadores por defecto para todas las plataformas, incluido Windows.

Why does Godot aim to keep its core feature set small?

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

There are several reasons for this:

  • Code maintenance and surface for bugs. Every time we accept new code in the Godot repository, existing contributors often take the reponsibility 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.

  • Ease of contribution. By keeping the codebase small and tidy, it can remain fast and easy to compile from source. This makes it easier for new contributors to get started with Godot, without requiring them to purchase high-end hardware.

  • Keeping the binary size small for the editor. Not everyone has a fast Internet connection. Ensuring that everyone can download the Godot editor, extract it and run it in less than 5 minutes makes Godot more accessible to developers in all countries.

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

For all the reasons above, we have to be selective of what we can accept as core functionality in Godot. This is why we are aiming to move some core functionality to officially supported add-ons in future versions of Godot. In terms of binary size, this also has the advance of making you pay only for what you actually use in your project. (In the meantime, you can compile custom export templates with unused features disabled to optimize the distribution size of your project.)

¿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 usar la cámara XFov o YFov.

  1. Elige una única resolución base para tu juego. Incluso si hay dispositivos que llegan hasta los 2K 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 2D funciona mejor si mantienes la relación de aspecto. Consulta el tutorial Múltiples resoluciones 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.

Si deseas que tu juego también funcione en dispositivos antiguos con pantallas muy pequeñas (menos de 300 píxeles de ancho), puedes usar la opción de exportar para reducir el tamaño de las imágenes y configurar esa compilación para que se use en determinados tamaños de pantalla en el App Store o en Google Play.

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

También puedes echar un vistazo a la implementación de GDScript, los módulos de Godot, así como el soporte no oficial de Python para Godot. Este sería un buen punto de partida para ver cómo otra librería de terceros se integra con Godot.

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

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

El primer lugar para comenzar es el de Como contribuir la guía te enseña como hacer un “fork”, modificar y enviar un “Pull Request (PR)” con tus cambios.

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

Puede ser tentador querer proponer ideas para Godot, como las que resultan en cambios masivos del nucleo: ideas como imitar lo que otro motor de juego hace, o flujos de trabajo que te gustaria implementar en el editor. Estas propuestas son fantásticas y estamos agradecidos de tener gente motivada en querer contribuir, pero el enfoque de Godot siempre será la funcionalidad del nucleo como mencionado en 'el mapa vial<corrigiendo errores y resolviendo problemas, y conversaciones entre miembros de la comunidad Godot.

La mayor parte de los desarrolladores de la comunidad de Godot estarán más interesados en aprender sobre cosas como esta:

  • Tu experiencia usando el software y los problemas que tengas (Nos importa mucho más, que las ideas de como mejorarlo).

  • Las características que te gustarían ver implementadas porque las necesitas para tu proyecto.

  • Los conceptos que eran difíciles de entender mientras se aprendía el software.

  • Las partes de tu flujo de trabajo que te gustaría ver optimizadas.

  • Partes donde no hay tutoriales claros o donde la documentación no estaba clara.

Por favor, no sientas que tus ideas sobre Godot no son bienvenidas. En su lugar, intenta reformularlas como un problema primero, así los desarrolladores y la comunidad tienen una base sobre cual discutir.

Una buena manera de compartir tus ideas y problemas con la comunidad es como un conjunto de acciones de usuario. Explica qué intentas hacer, qué esperas que suceda, y también qué es lo que está ocurriendo realmente. Dividir las ideas y problemas de esta forma ayuda a toda la comunidad a estar más enfocada en mejorar las experiencias de los desarrolladores en general.

Puntos extras por traer capturas de pantallas, números concretos, casos de pruebas o proyectos de ejemplos (Si se aplica).

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

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

Así como muchas otras librerías(Qt por ejemplo), Godot no hace uso de STL. 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 crashear 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 del ejecutable.

¿Por qué Godot no enforza RTTI?

Godot provee su propio sistema de casteo de tipos, el cual puede opcionalmente usar RTTI internamente. Deshabilitar RTTI en Godot significa que se pueden conseguir archivos binarios muchos más pequeños, con un pequeño coste en el rendimiento.

¿Pro 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 obtener mejoras significativas en el rendimiento cuando se trata de docenas de miles de objetos (que se procesan en cada cuadro con poca modificación). Como tal, si está moviendo unos cientos de sprites o enemigos por cuadro, DoD no lo ayudará y deberá 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 partes en las que se necesite alto rendimiento y GDScript (o C#) para 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.