Preguntas Frecuentes

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

Godot es Software Libre y de Código Abierto, disponible bajo la licencia MIT 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 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
  • 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 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 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 fueron las motivaciones detrás de GDScript?

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, JS, AS, etc.).
  2. No hay un buen soporte para extensión de clases en las VMs de la mayoría de los scripts, y adaptarlos a la forma en que Godot funciona es altamente ineficiente (Lua, Python, JS).
  3. Muchos lenguajes existentes tienen interfaces horribles para hacer binding 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, JS, AS, 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 es 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 del exportador OpenCollada (Maya, 3DSMax).

Si estás usando Blender, dale un vistazo a nuestro propio`Mejor Exportador Collada <https://godotengine.org/download>`_.

A partir de Godot 3.0, glTF es soportado.

FBX SDK tiene una licencia restrictiva, que es incompatible con la licencia abierta proporcionada por Godot. Dicho esto, el soporte de FBX podría ser proporcionado por terceros como un plugin. (Ver la sección de Plugins a continuación.)

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

¿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 Multiple resolutions 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 Multiple resolutions.
  4. Para las interfaces de usuario, utilice el anclaje para determinar cuales controles deberían moverse y cuales deberían quedarse estáticos. Si sus interfaces son mas complejas, debería considerar aprender sobre Contenedores.

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.

¡Me gustaría contribuir! ¿Cómo puedo empezar?

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

El primer lugar para comenzar es el de discusión. Encuentra un problema que te suene familiar, entonces proceda a la guía 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 al nucleo, algo como imitar lo que otro motor de juego hace, o flujos de trabajo que te gustaria implementar en el editor. Estos son grandiosos y estamos agradecidos de tener gente motivada en querer contribuir, pero el enfoque de Godot siempre sera la funcionalidad del nucleo como mencionado en “el mapa vial<https://github.com/godotengine/godot-roadmap/blob/master/ROADMAP.md>`_, 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).

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.