Revisión de la Versión de Godot 4.7: Innovaciones Arquitectónicas, Ecosistema de Desarrollo y Estándares de Producción

Godot, uno de los representantes más importantes e innovadores del ecosistema de motores de juegos de código abierto, ha alcanzado un nivel crítico de madurez en términos de flexibilidad arquitectónica, fidelidad gráfica y ergonomía para el desarrollador con su versión estable (stable release) lanzada el 18 de junio de 2026 1. Mientras que las versiones anteriores se centraban en la estabilización de los sistemas principales del motor y la corrección de errores críticos, la versión 4.7 presenta una estructura "orientada a la producción y al flujo de trabajo" que pretende resolver directamente los cuellos de botella diarios con los que se encuentran los estudios profesionales y los desarrolladores independientes en la fase de producción 3. Junto con la actualización de mantenimiento 4.7.2 lanzada el 18 de agosto de 2026, también se han solucionado las coordenadas de las sombras PCSS, el rendimiento en Windows de los ratones con alta tasa de sondeo (polling rate) y los pequeños inconvenientes en los escenarios de replicación multijugador (multiplayer), consolidando así la estabilidad del motor en entornos de producción (production-ready) 5.

Godot 4.7, más que ofrecer un motor de física completamente nuevo o una canalización de renderizado rehecha desde cero, es un paquete de mejoras exhaustivo que amplía las infraestructuras de renderizado Forward+ y Mobile existentes, resuelve los problemas crónicos de las animaciones de la interfaz de usuario (UI), estandariza los procesos de desarrollo móvil y satisface los requisitos de hardware moderno como el Alto Rango Dinámico (HDR) 2. En las evaluaciones realizadas por la comunidad y los profesionales de la industria, se observa que especialmente los desarrolladores que llevan muchos años utilizando diferentes motores de código cerrado (por ejemplo, Unity) quedan impresionados por las capacidades de renderizado y las posibilidades de creación rápida de prototipos de Godot 4.7 2. Este informe examina las innovaciones técnicas que ofrece Godot 4.7, los efectos de estas innovaciones en la arquitectura del software, los comentarios de la comunidad y las evaluaciones estratégicas de los proyectos durante los procesos de transición a esta nueva versión en un marco analítico sumamente exhaustivo.

Innovaciones en el Motor de Renderizado y la Infraestructura de Gráficos 3D

La canalización de procesamiento gráfico se encuentra entre las áreas en las que Godot 4.7 ha logrado los avances más notables. El delicado equilibrio entre el fotorrealismo y la optimización del rendimiento en el desarrollo de juegos moderno depende de la variedad de herramientas que ofrece el motor de renderizado y de su capacidad de aceleración por hardware. La nueva versión ofrece características analíticas que se adaptan a los estándares de la industria en muchas capas, desde los cálculos de iluminación hasta la gestión de materiales.

Luces de Área (AreaLight3D) y Física de Iluminación

Los modelos de iluminación son el elemento más fundamental que determina la credibilidad visual de los motores de renderizado 3D. Antes de Godot 4.7, los desarrolladores se veían obligados a agrupar luces puntuales (point lights) o a utilizar materiales emisivos (emissive) respaldados por Iluminación Global (Global Illumination) para simular fuentes de luz rectangulares o de superficie amplia (por ejemplo; carteles de neón, enormes ventanas industriales, pantallas de televisión, luces fluorescentes o iluminación de estudio suave) 1. Estas soluciones provisionales e indirectas no solo generaban un coste innecesario en la GPU en términos de rendimiento, sino que también resultaban insuficientes en cuanto a la suavidad de los bordes de las sombras generadas (penumbra) y su precisión física.

Junto con Godot 4.7, el nodo AreaLight3D añadido a la arquitectura de nodos central ofrece una solución de renderizado en tiempo real analítica que permite que la luz se propague no desde un único punto infinitamente pequeño, sino desde un área de superficie rectangular bidimensional con límites definidos 1. Esta arquitectura estructural produce transiciones de sombra naturales y que se suavizan gradualmente en función del tamaño físico de la fuente de luz, al tiempo que garantiza que la forma rectangular de la fuente de luz se refleje correctamente en las superficies lisas y reflectantes (specular reflections) de la escena 1. Este enfoque, que no requiere trazado de rayos (ray tracing), aumenta drásticamente la calidad de iluminación de las escenas sin superar el presupuesto de rendimiento. En términos de visualización arquitectónica, juegos de terror en espacios cerrados (indoor horror) y diseño de atmósfera cinemática, este desarrollo proporciona a los diseñadores de escenas un flujo de trabajo mucho más limpio y una calidad visual superior.

Soporte de Salida de Imagen en Alto Rango Dinámico (HDR)

Con los avances en las tecnologías de visualización, el hardware que supera los límites del espacio de color sRGB estándar ha comenzado a convertirse en la norma en el mercado de consumo final. Godot 4.7 ha adquirido la capacidad de transferir directamente los datos de iluminación de alto rango dinámico, que el motor calcula internamente en formato de punto flotante (floating point), a las pantallas compatibles a través de las API de HDR a nivel del sistema operativo 2. Esta característica, que teóricamente admite valores de brillo de hasta 10.000 nits, permite que elementos como explosiones, luces de neón, efectos de magia o la luz solar directa se presenten en la pantalla con un brillo cegador, negros profundos y una gama de colores (color gamut) mucho más amplia 3.

Dado que la compatibilidad con la salida HDR requiere una integración de muy bajo nivel con los controladores de hardware y los administradores de ventanas del sistema operativo (window manager), las dependencias de la plataforma y del motor de renderizado son específicas. La matriz de configuración relativa a la integración de esta característica se detalla en la tabla siguiente:

Sistema Operativo / PlataformaEstado de compatibilidad con HDRMotor de Renderizado RequeridoNotas de Arquitectura e IntegraciónWindowsTotalmente CompatibleForward+ o MobileLos ajustes de Windows HD Color a nivel del sistema operativo deben estar activados y se debe utilizar un monitor compatible.macOSTotalmente CompatibleForward+ o MobileEstá integrado directamente con las API de gestión de HDR nativas de Apple y la interfaz Metal.iOS y visionOSTotalmente CompatibleForward+ o MobileEs compatible con las capacidades de alta brillo y las estructuras de pantalla XDR de los dispositivos móviles de Apple.Linux (Wayland)Totalmente CompatibleForward+ o MobileFunciona únicamente bajo compositores modernos de Wayland. Requiere un protocolo de gestión de ventanas exhaustivo.Linux (X11)No compatibleNo aplicableEstá desactivado debido a las restricciones de profundidad de color en la antigua arquitectura X11. Los desarrolladores deben migrar a Wayland.AndroidNo compatibleNo aplicableNo está disponible actualmente debido a la amplia fragmentación del hardware de Android (fragmentation).Web (HTML5)No compatibleNo aplicableLas limitaciones de las API gráficas de los navegadores WebGL y WebGPU aún no han estandarizado la salida HDR.

Como puede deducirse de la tabla, el uso de HDR no debe considerarse un requisito holístico (requirement), sino una capa de enriquecimiento visual opcional que se activa en las plataformas compatibles 4. En lugar de hacer de HDR la base de toda la dirección artística (art direction), los desarrolladores deben evaluarlo como un pulido que enriquecerá aún más los proyectos que ya se ven bien con un rango dinámico estándar (SDR) 4.

Infraestructura de Trazado de Rayos por Hardware (Ray Tracing) de Vulkan

Una de las mayores rupturas tecnológicas en la industria de los juegos, la tecnología de trazado de rayos por hardware, se ha integrado en Godot 4.7 junto con la arquitectura Vulkan como una infraestructura de fontanería (plumbing) de bajo nivel (low-level) 2. Esta versión no incluye características directas para el usuario final, como "Reflejos Trazados por Rayos" (Ray-traced reflections) o "Trazado de Caminos" (Path tracing), que los jugadores o desarrolladores puedan activar con un solo clic 10. En su lugar, se han dotado al motor las capacidades de construir estructuras de aceleración (acceleration structures), que son los requisitos fundamentales del trazado de rayos, y de lanzar rayos directamente (ray dispatch) desde el interior de la canalización de renderizado de Vulkan 2.

Este movimiento de ingeniería estratégica ofrece una base estandarizada para que los estudios a gran escala escriban sus propias soluciones de trazado de rayos personalizadas (por ejemplo, sombreadores de iluminación especiales o sistemas de espejos). En años anteriores, los equipos que querían utilizar el trazado de rayos por hardware dependían de bifurcaciones (forks) especiales de Godot de código cerrado mantenidas por NVIDIA o por desarrolladores independientes 2. Esta integración central aportada con la 4.7 es una prueba definitiva de que las características de trazado de rayos integradas (built-in) funcionarán directamente en el motor principal (mainline) en futuras versiones como Godot 4.8 y 4.9 2.

DrawableTexture2D y Procesamiento de Texturas en Tiempo de Ejecución

La operación de "dibujar sobre una textura en tiempo de ejecución" (runtime texture drawing), que se necesita con frecuencia en las mecánicas de juego, se realizaba en versiones anteriores mediante operaciones indirectas y de alto costo, como crear un Viewport independiente para renderizar la escena dentro de ese viewport o enviar comandos de GPU de bajo nivel a través de las complejas API de RenderingDevice. Godot 4.7 ha abstraído estas dificultades introduciendo la clase DrawableTexture2D, que es una API sumamente accesible y de alto rendimiento 2.

DrawableTexture2D permite a los desarrolladores escribir datos de píxeles o trazos de pincel directamente sobre una textura mediante llamadas de transferencia (blit) estándar 2. Esta característica permite que incluso los desarrolladores que no dominan en profundidad las API de renderizado puedan crear efectos complejos con facilidad. Por ejemplo; máscaras de niebla de guerra explorables (fog of war) en juegos de estrategia, marcas de neumáticos dinámicas en juegos de carreras, mecánicas donde los caracteres arrojan pintura a las superficies (paint tools), herramientas donde los jugadores pueden dibujar libremente, juegos de rascar/revelar (reveal mask) o texturas de armadura que se deforman a medida que reciben daño (scratch effects) se pueden desarrollar utilizando esta API sin sobrecargar el sistema principal 1.

Arte de Píxeles y Visuales 3D: Escalado Nearest-Neighbor

Los motores de renderizado 3D tradicionales utilizan por defecto el filtrado bilineal (bilinear) al proyectar en pantalla texturas, revestimientos o salidas de pantalla de baja resolución. Aunque este algoritmo de suavizado ofrece resultados perfectos en gráficos fotorrealistas, provoca un emborronamiento (blurring) no deseado, especialmente en juegos de arte de píxeles 3D de baja resolución o que imitan el estilo retro de los años 90 (estética de PS1) 2 . Muchos desarrolladores de la comunidad se veían obligados a escribir sombreadores (shaders) personalizados solo para eliminar estas imperfecciones. Godot 4.7 integra la opción de escalado Nearest-Neighbor (vecino más cercano) para las áreas de visualización 3D (viewport) como una característica estándar del motor, ofreciendo una excelente herramienta de control estético que preserva la nitidez y los trazos cortantes de los píxeles incluso cuando se reduce la resolución 1 . Esta característica ha creado una infraestructura indispensable para las producciones independientes que combinan características 3D modernas con un enfoque nostálgico de arte de píxeles.

Sombreadores (Shaders), Efectos y Mejoras de Materiales

Los efectos de post-procesamiento (post-processing) y los sistemas de partículas que definen el lenguaje visual del juego también han pasado por optimizaciones detalladas. Para los desarrolladores que trabajan en sombreadores de texto basados en código (text shaders), la mayor novedad son las vistas previas de sombreadores en línea (inline) dentro del editor. Ahora, cuando se realiza un cambio matemático en el código del sombreador (por ejemplo, al cambiar la frecuencia de una función de onda), los cambios se pueden previsualizar en tiempo real directamente en el fondo del editor de código sin necesidad de recompilar el motor o cambiar a un espacio de trabajo diferente 2 . Este es un desarrollo que aumenta la velocidad de iteración a dimensiones extraordinarias.

Por el lado de los materiales de renderizado basado en física (PBR), se han mejorado los algoritmos de renderizado de barniz (clearcoat) utilizados para simular superficies como pintura de automóviles o suelos húmedos; la refracción de la luz sobre estas capas transparentes se ha vuelto más precisa 1 . Las pasadas de renderizado (render passes) ahora pueden albergar sus propios tampones uniformes (uniform buffers) ambientales independientes, lo que proporciona flexibilidad en las cadenas complejas de post-procesamiento 1 . En los sistemas de partículas 3D, se han ofrecido a los desarrolladores controles ampliados sobre la escala (scale) y las rotaciones (rotation) de las partículas, y se han aplicado correcciones matemáticas dirigidas a las velocidades angulares (angular velocity) de las partículas para lograr que las simulaciones se vean más orgánicas 1 .

Ingeniería de Interfaz de Usuario (UI) y Animación

Sistemas

En los procesos de desarrollo de videojuegos, el diseño de la interfaz de usuario es un área que suele consumir mucho más tiempo que la codificación de la mecánica central del juego, es muy abierta a la iteración y posee una estructura sumamente frágil 9 . Para que los elementos de la interfaz puedan adaptarse a las diferentes resoluciones en la pantalla del juego, Godot ofrece un sistema de diseño basado en nodos (node-based) muy sólido desde el principio. Sin embargo, la versión 4.7 resuelve un problema estructural profundo en la interacción de los elementos de la interfaz con las animaciones, presentando así uno de los conjuntos de herramientas de UI más capaces de la industria 9 .

Transformaciones de Desplazamiento del Nodo Control (Offset Transforms)

El sistema de diseño (layout) de UI de Godot se basa en nodos Container (Contenedor) jerárquicos. Los nodos Control (botones, paneles, barras de desplazamiento, etc.) colocados dentro de un HBoxContainer (contenedor de caja horizontal) o VBoxContainer (contenedor de caja vertical) son administrados rígidamente por los algoritmos de clasificación y posicionamiento automático del contenedor 1 . En versiones anteriores, cuando un diseñador utilizaba una animación Tween para aumentar la escala, la rotación o la posición de un botón con el fin de crear una respuesta visual al pasar el cursor sobre él (estado hover), el contenedor principal percibía este cambio como una "ruptura del diseño". El contenedor realizaba un recálculo instantáneo e intentaba reposicionar los elementos de la interfaz según su propia lógica algorítmica, lo que provocaba que los botones sufrieran saltos indeseados (snap back), que los menús parpadearan y que los desarrolladores prácticamente tuvieran que luchar contra el sistema de contenedores (fighting layout) 1 .

La solución más crítica que Godot 4.7 aporta a la ingeniería de UI es el sistema de transformaciones de desplazamiento de Control (offset transforms), que separa las transformaciones visuales del modelo de caja lógico (box model). Las nuevas propiedades añadidas offset_transform_* (posición, rotación, escala) determinan cómo se dibujará visualmente el elemento de la interfaz, mientras dejan sus coordenadas lógicas y el espacio que ocupa en su estado original 1 . Es decir, cuando un botón se amplía visualmente un 20% o se desplaza en la pantalla utilizando transformaciones de desplazamiento, el contenedor principal no percibe este cambio como una actualización del diseño y mantiene los cálculos de posicionamiento 4 . Este aislamiento permite por completo que los programadores de UI y los artistas técnicos diseñen animaciones de interfaz fluidas, dinámicas y flexibles sin romper la estructura del contenedor ni la lógica de anclaje (anchoring) 4 . Los comentarios de la comunidad confirman que esta característica elimina cientos de líneas de código de solución temporal (workaround) en los diseños de menús y resulta ser "salvadora" 9 .

Etiquetas de Texto Enriquecido (RichTextLabel) y Degradados Cónicos

Las capacidades de visualización de datos de las interfaces de usuario se han mejorado para responder a los requisitos de dimensionamiento dinámico de fuentes de los juegos modernos. Las imágenes incrustadas dentro de un RichTextLabel utilizando la etiqueta [img] (por ejemplo, el botón "A" de un mando de Xbox o un símbolo de emoji especial mostrado dentro del texto) ahora se pueden posicionar de manera que respondan al tamaño del texto en línea 1 . Los utilizadores y desarrolladores pueden usar definiciones relativas similares a CSS como [img height=1em] para garantizar que, al cambiar la resolución del juego, las traducciones de idiomas o la configuración de accesibilidad, la imagen también se escale de forma proporcional junto con la fuente del texto 3 .

Además, en el campo de los efectos 2D y el diseño de UI, se ha añadido el modo FILL_CONIC (llenado cónico) a la clase GradientTexture2D utilizada para crear espectros de color. A diferencia de los degradados lineales o circulares estándar, esta característica de degradado cónico distribuye los colores barriéndolos alrededor del centro (sweep), de manera similar a los estilos CSS. Este añadido matemático constituye una base sumamente práctica para crear barras de progreso circulares, indicadores de munición, efectos de escaneo de radar o ilusiones de sombreado cilíndrico 3D falso (fake 3D shading) al escribir shaders 2D 3 .

Ecosistema del Editor y Mejoras en el Flujo de Trabajo del Desarrollador

Los motores de juegos no son solo motores compiladores que producen archivos ejecutables; también son software de productividad y desarrollo (IDE) donde los diseñadores, artistas y programadores pasan miles de horas. En este contexto, la fluidez de la propia interfaz del editor afecta directamente el tiempo de desarrollo. Godot 4.7 incluye numerosas actualizaciones de Calidad de Vida (Quality of Life - QoL) que optimizan la experiencia del editor, reducen la cantidad de clics y aligeran la carga cognitiva en proyectos grandes.

El Nacimiento de la Asset Store (Antigua Asset Library)

La Asset Library (Biblioteca de recursos), que durante muchos años ofreció a los desarrolladores de Godot un servicio para descargar herramientas creadas por la comunidad, ha dado paso al concepto de la Asset Store (Tienda de recursos), reescrita desde cero y con estándares de API modernos 2 . Esto no es solo un cambio de nombre cosmético, sino una revisión arquitectónica de la infraestructura. En el antiguo sistema, al descargar enormes paquetes de recursos del servidor o al procesar consultas de búsqueda, el hilo principal del editor (main thread) se bloqueaba, lo que provocaba congelamientos. La nueva API de la tienda utiliza activamente hilos en segundo plano (background threading) 1 . De este modo, mientras se descargan los contenidos, la interfaz del editor permanece completamente receptiva (responsive) 3 . Además, se ha integrado la capacidad de hacer zoom en las imágenes de vista previa para examinar los recursos más de cerca, visualizaciones de valoraciones (ratings) actualizadas por la comunidad y un árbol de categorías (escaparate) mucho más limpio 3 .

Mejoras del Inspector y Colapsado de Pistas de Animación

En los proyectos 3D a gran escala, uno de los puntos donde los desarrolladores pierden más tiempo es en la transferencia de estructuras de datos complejas entre nodos. Gracias a una nueva herramienta de panel añadida al panel Inspector en Godot 4.7, en lugar de copiar y transferir variables una por una (por ejemplo, rotaciones X, Y, Z o códigos de color de materiales) entre nodos similares, ahora es posible copiar todo un grupo de propiedades (property section) de forma colectiva y pegarla con un solo clic en el mismo campo de otro nodo 1 . Esta mecánica reduce a cero el margen de error manual, especialmente al transferir parámetros de materiales o configuraciones físicas jerárquicas de forma masiva, y proporciona un enorme ahorro de tiempo 2 .

El panel AnimationPlayer y Animation Tracks (Pistas de animación), utilizado para administrar las animaciones de escenas complejas, también ha sido rediseñado ergonómicamente. Al animar un esqueleto de personaje complejo (skeleton) que contiene entre 40 y 50 pistas diferentes, se ha introducido la función de "colapsado de pistas" (track collapsing) para evitar que la pantalla se sature de pistas y se produzca un caos al desplazar (scrolling) 1 . Los fotogramas clave (keyframes) situados en las pistas colapsadas se presentan en una sola línea como una "representación agregada" (aggregate representation); de este modo, los animadores siguen teniendo una guía visual sobre la sincronización general de la animación (timing) sin necesidad de ver los detalles específicos dentro de las pistas colapsadas 3 .

Alineación de Escenas 3D (Snapping) y Mejoras en la Regla

Las herramientas de manipulación de escenas se han potenciado enormemente para los artistas 3D y diseñadores de niveles que realizan diseño de niveles y construcción de mundos (world building). Antes de Godot 4.7, unir recursos y asentarlos en el suelo se hacía principalmente a ojo o introduciendo valores numéricos. La nueva versión ofrece tres conjuntos de herramientas principales que alcanzan los estándares de la industria:

1. Alineación de Vértices (Vertex Snapping): Al mantener presionada la tecla de atajo asignada en el teclado en el editor (por defecto 'B'), el desarrollador puede seleccionar directamente el punto de vértice específico de una malla 3D (mesh) y ajustarlo (snap) a los puntos de vértice de otros objetos con precisión milimétrica 1 . Esto evita que queden espacios al crear diseños de mazmorras modulares o bloques de construcción.

2. Path3D y Alineación de Colisionadores (Collider Snapping): Los puntos del nodo Path3D, utilizados para dibujar trayectorias en las escenas, ya no solo se pueden alinear con el plano de la cámara del visor (camera plane), sino también directamente con las superficies de los colisionadores físicos (colliders) en la escena 1 . Esta característica proporciona una facilidad vital al trazar patrullas de inteligencia artificial (patrol paths) o trayectorias de pistas de carreras que se mueven sobre terrenos montañosos o inclinados 3 .

3. Regla Avanzada (Ruler): La herramienta de medición 3D, utilizada con la tecla modificadora Shift, ahora muestra por separado no solo la distancia absoluta entre dos puntos (por ejemplo, 15 metros), sino también los vectores de longitud relativa a lo largo de cada eje de coordenadas en el espacio tridimensional (X, Y, Z) (por ejemplo, 10 m en el eje X, 5 m en Y, 10 m en Z) 1 . Esta retroalimentación geométrica es muy crítica en el diseño de niveles en su fase inicial, conocido como blockout. Asimismo, los controles de cámara 3D se han unificado (unified) con la ventana de juego integrada dentro del motor (embedded game view), lo que garantiza que los atajos de teclado o el diseño de navegación del desarrollador sigan siendo los mismos en ambos lados 3 . Se ha añadido una barra de búsqueda a las ventanas PopupMenu para facilitar la búsqueda de los objetos deseados en listas largas; y se han integrado mecanismos de filtrado como "Mostrar personalizados" (Show Custom) en las pantallas de creación de nuevos nodos (Node) o recursos (Create Dialog) 1 . Cuando un desarrollador que trabaja en el editor de código hace doble clic en el nombre del archivo situado en la parte superior de la ventana de scripts, la ubicación del archivo en el sistema de archivos del lado izquierdo se resalta automáticamente (highlighted), evitando así perderse en árboles de datos extensos 3 . Por otro lado, en la pantalla Remote Scene Inspector (Inspector de escena remota), los valores de enumeración (Enum) han comenzado a mostrarse no solo como números enteros sin sentido (0, 1, 2), sino con los nombres de cadena (string names) que representan dentro del código 3 .

Desarrollo móvil, Realidad Virtual (XR) y Optimizaciones de Rendimiento

A medida que la participación de los dispositivos móviles y los visores de realidad virtual (plataformas) en la industria de los videojuegos sigue creciendo, Godot 4.7 ha convertido en características estándar del núcleo los ganchos de software dedicados que responden a las restricciones de hardware de estos dispositivos.

Integración nativa de VirtualJoystick (Joystick virtual)

Los equipos que desarrollan juegos de acción o rol para plataformas móviles han dependido durante mucho tiempo de complementos de terceros para los controles táctiles en pantalla o de código de entrada escrito desde cero y difícil de mantener. Los complementos de la comunidad conllevan el riesgo de romperse con cada actualización del motor4. Godot 4.7 resuelve esta fragmentación de raíz al ofrecer un nodo VirtualJoystick integrado directamente en el núcleo del motor1.

Esta integración admite tres modelos de interacción diferentes totalmente compatibles con los esquemas de control clásicos en el diseño de juegos móviles:

Modo de JoystickMecanismo y Comportamiento del UsuarioEscenario de Uso IdealFijo (Fixed)La posición del joystick en la pantalla es fija. El jugador debe arrastrar su pulgar a esta área específica de la pantalla. Cuenta con un ajuste clásico de "zona muerta" (dead zone) en su centro.Puertos retro de arcade, controladores fijos de estilo consola1.Dinámico (Dynamic)El joystick aparece en ese punto en el momento exacto en que el jugador toca un área designada de la pantalla. En cuanto se levanta el dedo, desaparece instantáneamente y restablece su posición.Juegos de disparos (shooters) que requieren una respuesta rápida1.De Seguimiento (Following)Comienza con la misma lógica que el modo dinámico, pero cuando el pulgar del jugador supera los límites de movimiento, el eje central del joystick también se desplaza siguiendo al dedo, lo que garantiza que el jugador mantenga un contacto continuo.Juegos de rol (RPG) o endless runners donde el personaje se mueve sin parar1.

Además, se ha habilitado la lectura de los datos del acelerómetro y el giroscopio provenientes de los gamepads a través de la API, lo que estabiliza la integración de los controles de inclinación y movimiento que ofrecen los mandos de juegos móviles o de consola3.

GABE (Godot Android Build Environment) y Desarrollo Directamente en el Dispositivo

La visión de Godot de no limitarse a desarrollar juegos para Android, sino de adoptar como postura filosófica el "desarrollo de juegos directamente en tabletas y dispositivos móviles con el sistema operativo Android" (Godot Editor for Android), ha dado un gran salto en la versión 4.7. Gracias a una aplicación compañera (companion) especial llamada GABE (Godot Android Build Environment), el Editor de Godot que se ejecuta en dispositivos Android (por ejemplo, una Samsung Galaxy Tab) ahora cuenta con el soporte de exportación de Gradle necesario para crear archivos APK o AAB directamente dentro del dispositivo3. Esto significa que el desarrollador puede compilar el código escrito en el dispositivo directamente en él, sin necesidad de una computadora, y crear paquetes de versiones completos (APK)4.

También se han superado las limitaciones ergonómicas del editor que se ejecuta en Android. La ventana de juego incrustada (embedded game window) en tiempo de ejecución ya no permanece estática, sino que ahora se puede redimensionar y arrastrar; de este modo, se pueden probar diferentes relaciones de aspecto de pantalla (aspect ratios), como el formato horizontal, vertical o de tableta, en un solo dispositivo1. La pantalla de escritura de scripts se ha vuelto giratoria (landscape coding) al responder a los sensores horizontal/vertical del dispositivo, lo que mejora la ergonomía al conectar un teclado4. Asimismo, gracias a la función Picture-in-Picture (Imagen en Imagen), los procesos de prueba se han vuelto mucho más modulares y el juego se puede supervisar incluso mientras se ejecuta en segundo plano1. Se han ampliado las opciones de exportación para que las pantallas de inicio (splash) de los proyectos de Android ahora tengan una estructura personalizable1.

Sin embargo, en este punto es necesario llamar la atención sobre las advertencias de rendimiento provenientes de la comunidad de desarrolladores. Aunque el motor 3D de Godot cuenta con características avanzadas, al utilizar el motor Compatibility (GLES3/OpenGL), especialmente en dispositivos móviles, se pueden experimentar limitaciones de renderizado en dispositivos equipados con GPU de gama media como la Mali G68. Los análisis de la industria (por ejemplo, los informes de pruebas de Reddit) muestran que, en una escena simple con muy pocos objetos de fondo y solo 3000 polígonos, las tasas de fotogramas pueden caer hasta 38 FPS a menos que se reduzca la escala de resolución16. Por lo tanto, los desarrolladores deben prestar la máxima atención a la escala de resolución del puerto de vista (viewport resolution scale), la simplicidad de los materiales y la variedad de dispositivos de prueba al desarrollar productos 3D dirigidos a la plataforma Android16.

Realidad Extendida (XR): Capas de Composición y Renderizado Foveated

La arquitectura OpenXR, que se ha convertido en el estándar de la industria en el mercado de la Realidad Virtual (VR) y la Realidad Aumentada (AR), se ha vuelto más orientada a la producción con Godot 4.72. Si bien se proporciona compatibilidad lista para producción (production-ready) para Steam Frame y las plataformas Android XR, los mapas de acción de OpenXR (action maps) se han reducido a los cuatro perfiles principales para mitigar la complejidad en las integraciones de controladores1.

En los procesos de desarrollo de RV, la legibilidad de la interfaz de usuario (UI) es el problema ergonómico más crítico. Colocar indicadores en pantalla (HUD) o textos en la escena como geometría 3D estándar (eye-buffer rendering) provoca textos parpadeantes, borrosos e ilegibles debido a la distancia focal de las lentes y la densidad de píxeles. El sistema de capas de composición (composition layer) de OpenXR traslada las interfaces fuera del búfer del mundo de juego estándar y las dibuja directamente en la capa de proyección del visor (sobre el proyector)3.

Godot 4.7 ha profundizado el control sobre estas capas de composición. Los desarrolladores ahora pueden:

• Vincular (lock) y fijar las capas de composición directamente al nodo XRCamera3D en la escena para diseñar pantallas HUD ultra nítidas (crisp) que permanezcan estáticas sin experimentar ni un solo milisegundo de retraso en el campo de visión, sin importar cuán rápido mueva la cabeza el jugador3.

• Emparejar (pairing) los objetos de las capas de composición con la geometría del mundo (world geometry), dejando las capas de texto suspendidas (world-locked) en una coordenada específica del espacio3.

En el contexto del rendimiento gráfico, los visores de VR (por ejemplo, Meta Quest) son dispositivos con resoluciones masivas, y el ahorro de cada milisegundo es de vital importancia para la comodidad (comfort)4. La tecnología de "Imágenes Submuestreadas" (Subsampled images) de Vulkan se ha integrado en el motor Mobile Render de Godot 4.71. Esta tecnología reduce drásticamente el ancho de banda de memoria de la GPU (memory bandwidth) al almacenar los píxeles procesados con menor densidad durante los procesos de renderizado foveated (renderizar nítidamente el centro en el que se enfoca el ojo y a baja resolución el campo de visión periférico)3. De este modo, se logra una gran ganancia en el rendimiento y en el consumo

de batería del dispositivo móvil 1 . Se recomienda utilizar el motor de renderizado Mobile por defecto para los proyectos XR 1 .

Filosofía de Físicas y Conjunto de Herramientas 2D Avanzadas

Los sistemas de físicas y los algoritmos de colisión constituyen el corazón comportamental de los motores de juegos. Con la versión 4.6, Godot había incorporado el complemento de alto rendimiento Jolt Physics al ecosistema del núcleo como su motor de físicas 3D predeterminado. Al contrario de algunos rumores en la industria, la versión 4.7 no ha reemplazado ni cancelado Jolt Physics; el motor Jolt mantiene su estabilidad en entornos de producción como el motor de físicas predeterminado (default) de los nuevos proyectos 3D y de la arquitectura de 4.7 1 . Sin embargo, la verdadera revolución física de la versión 4.7 se ha producido al superar una limitación fundamental en las arquitecturas de colisión 2D.

Libertad de Dirección de Colisión Unidireccional (One-way Collision)

En los juegos de plataformas 2D (por ejemplo, nubes o puentes colgantes por los que un personaje puede saltar desde abajo, atravesarlos y pisarlos por encima, como en Mario o Hollow Knight), las colisiones unidireccionales son una mecánica utilizada frecuentemente. Antes de Godot 4.7, el motor de físicas asumía de forma rígida e inalterable que el vector de colisión unidireccional apuntaba hacia la propia dirección "Arriba" (Up) local del nodo CollisionShape2D correspondiente (vector 0, -1) 3 . Cuando los diseñadores de juegos querían cambiar la dirección de la colisión (por ejemplo, una pared por la que el personaje puede pasar desde la derecha pero con la que choca desde la izquierda), tenían que recurrir a trucos dolorosos (painful) como girar la estructura física o la rotación del colisionador de manera totalmente independiente de los nodos de gráficos visuales y sincronizar ambas estructuras 3 .

Con la actualización 4.7, se ha añadido una nueva variable llamada one_way_collision_direction (dirección de colisión unidireccional) a la clase CollisionShape2D 3 . Gracias a esta característica, el vector de dirección de las interacciones unidireccionales se puede asignar libremente en el espacio local de 360 grados sin alterar nunca la geometría general de la forma de colisión (la estructura de caja o cápsula) 3 . Esta situación ha hecho que la codificación de corrientes de viento fuertes, cintas transportadoras que empujan al personaje, zonas de gravedad angulares o mecánicas de planeo a través de plataformas sea mucho más elegante y matemáticamente correcta al librarla de cálculos de rotación innecesarios.

Suavizado CSG Dinámico (Autosmooth)

La Geometría Sólida Constructiva (Constructive Solid Geometry - CSG) es una herramienta que permite a los diseñadores de juegos realizar prototipados instantáneos de niveles 3D (level) utilizando formas geométricas básicas que se intersecan (cubo, esfera, cilindro) dentro del motor mediante operaciones de suma, resta e intersección, sin necesidad de programas de modelado 3D externos como Blender o Maya 3 . Sin embargo, los suelos CSG creados siempre se veían afilados, de bajo poligonaje y rugosos.

La nueva característica Autosmooth (Suavizado Automático) añadida a los nodos raíz CSG en Godot 4.7 suaviza estas estructuras poligonales afiladas de forma procedural a nivel de hardware 3 . El parámetro Smoothing Angle (Ángulo de Suavizado) está configurado por defecto en 50 grados; las uniones de superficies por debajo de este umbral se procesan automáticamente como superficies suaves (smooth faces), mientras que las intersecciones pronunciadas con ángulos mayores continúan conservando las líneas de las esquinas (sharp faces) 3 . A medida que aumenta el valor, se aplica un perfil de suavizado más agresivo; esta característica permite que no solo los equipos que hacen prototipados, sino también los estudios que realizan producciones de bajo poligonaje (low-poly), puedan transferir sus estructuras CSG a sus juegos directamente con la calidad de un producto final (final asset) 3 .

Cambios en la API, Creación de Scripts (Scripting) y

Estrategias de Migración Cada actualización menor (minor release) de la versión .x añade nuevas características mientras modifica simultáneamente algunas firmas de API (Interfaz de Programación de Aplicaciones) y contiene cambios disruptivos (breaking changes) a nivel de código para mejorar el rendimiento del motor en segundo plano 3 . Aunque la filosofía fundamental de Godot 4.7 es mantener la compatibilidad con versiones anteriores, existe una jerarquía de migración estricta que los desarrolladores deben tener en cuenta al actualizar sus proyectos actuales de 4.6 (o anteriores).

La metodología más vital en el proceso de migración es no abrir nunca directamente el directorio actual del proyecto en el que se está trabajando de forma activa con la nueva versión 4.7 del motor, sino abrir una nueva rama de prueba (branch) en el sistema de control de versiones del proyecto (VCS - por ejemplo, Git) o tomar una copia completa de toda la carpeta 1 . Cuando el editor abre el proyecto por formato de 4.7 por primera vez, reescribe desde cero todos los procesos de importación de texturas, textos y modelos (import pipeline); dado que esta operación es irreversible, el aislamiento evita pérdidas de datos críticas y daños en la retrocompatibilidad 13 .

Novedades en Programación y Escritura de Scripts

GDScript, el lenguaje de programación dinámica propio de Godot, se ha fortalecido en el lado del control de flujo y la integración de sistemas en la versión 4.7:

1. Implementación de Interfaces de Java: Anteriormente, para acceder al hardware especial de los dispositivos Android (API de cámara, sensores especiales o sistemas de pago), era necesario escribir complementos intermedios con C++ o Java. Con 4.7, GDScript ha ganado la capacidad de integrar interfaces de Java directamente dentro del motor, aliviando en gran medida la necesidad de complementos externos 1 .

2. Pausa de Tween (tween_await): El sistema Tween, utilizado para crear animaciones basadas en código, ahora puede pausar (pause) su propio tiempo de ejecución hasta que se active una señal proveniente de otro objeto dentro del sistema mediante una llamada a la función tween_await(). Esta característica supone una facilidad tremenda para crear cadenas de animación asíncronas (asynchronous) 1 .

Para los usuarios de C# (.NET), se mantiene el sistema estructural. Godot 4.7 continúa ofreciendo dos distribuciones de binarios ejecutables separados: "Standard" (compatible con GDScript y C++ mediante GDExtension) y ".NET" (compatible con C# y requiere el SDK de .NET) 1 . Si se abre un proyecto anterior basado en C# con el nuevo motor Standard, los scripts no se compilarán y se producirán fallos; por lo tanto, es fundamental descargar la versión correcta 1 .

Tabla de Cambios Destacados (Breaking Changes)

La siguiente tabla resume los cambios clave que afectan a las estructuras de código existentes, los tipos de datos y las llamadas a la API durante la transición de Godot 4.6 a Godot 4.7, requiriendo por lo tanto una refactorización:

Clase Afectada / Característica del SistemaMétodo Modificado / Cómo Ha Cambiado y Descripción DetalladaEstado de Compatibilidad de la Arquitectura (GDScript / C#)Object (Núcleo - Core)is_class() El tipo del parámetro class ha cambiado del tipo String general al tipo StringName, que es mucho más rápido a nivel de C++ y utiliza memoria estática18. Aumenta el rendimiento en las consultas de objetos.GDScript: Compatible.
C#: Compatible a nivel Binario y de Código Fuente.ZIPPacker (Core)start_file() Se han añadido dos parámetros nuevos a la API para mayor seguridad llamados permissions (permisos de archivos) y modified_time (tiempo de modificación) para la marca de tiempo18.GDScript: Compatible.
C#: Compatible a nivel Binario y de Código Fuente.OptimizedTranslationgenerate() El tipo de valor de retorno se ha cambiado del tipo vacío (void) al tipo booleano (bool) para que la función de localización de idiomas pueda informar sobre el estado de éxito18.GDScript: Compatible.
C#: Incompatible a nivel Binario, Compatible a nivel de Código Fuente.GPU/CPUParticles2D y 3Drequest_particles_process() Se ha añadido el parámetro process_time_residual para un ajuste fino con el fin de aumentar la precisión física en las simulaciones de partículas18.Compatible para todos los lenguajes.Control (Interfaz - GUI)accessibility_live Las características de accesibilidad como los lectores de pantalla se han independizado del servidor de pantalla gráfica (DisplayServer) y se han trasladado a su propio tipo AccessibilityServer.AccessibilityLiveMode18.GDScript: Compatible.
C#: Totalmente Incompatible (Se Requiere Refactorización Manual).RichTextLabel (Interfaz)Constant (Constante) Enum El nombre de la variable ImageUpdateMask.UPDATE_WIDTH_IN_PERCENT, que es el parámetro para determinar el ancho, se ha actualizado a ImageUpdateMask.UPDATE_WIDTH_UNIT, lo cual es más adecuado para la estructura lógica18.GDScript: Incompatible.
C#: Incompatible a nivel Binario y de Código Fuente.RichTextLabel (Interfaz)add_image() / update_image() Los parámetros width y height se han convertido del tipo Entero (int) al tipo de Número Decimal (float) para proporcionar flexibilidad de dimensionamiento y admitir escalas relativas (relative) como 1em18.Compatible para todos los lenguajes.

Procedimientos de Verificación y Pruebas Posteriores a la Actualización

Una vez que el proyecto se abre con éxito en el sistema de control de versiones dentro del entorno 4.7, incluso si se compila, los módulos específicos deben someterse a pruebas de regresión en tiempo de ejecución (runtime):

1. Jerarquía de la Interfaz de Usuario (UI): Dado que la nueva dinámica de offset_transform puede afectar los algoritmos de cálculo de algunas posiciones de nodos padre-hijo profundamente anidados, barras de desplazamiento (scroll views) o menús desplegables (popup menus), el menú principal, el inventario y las pantallas de HUD deben probarse de principio a fin 1 .

2. Expresión de Materiales y Canal de Renderizado: Se pueden observar cambios de color (color shifting), fugas de luz o diferencias de sombras en las apariencias de los materiales PBR debido a la transición del rango dinámico estándar (SDR) a los canales de renderizado con soporte HDR incluidos en el entorno; se deben verificar todas las estructuras de iluminación 1 .

3. Configuraciones de Android y Perfiles XR: Es necesario verificar desde cero las pantallas de inicio (splash) de Android en los ajustes de exportación (export presets), los cambios en el empaquetado de datos OBB y los mapas de acciones (action maps) de OpenXR simplificados y reducidos a cuatro perfiles básicos 1 .

4. Extensiones GDExtension en C++: Si las bibliotecas (GDExtensions) utilizadas en el proyecto y vinculadas (bound) al código fuente de C++ del motor no se han actualizado para admitir la nueva firma de API de Godot 4.7, el motor puede bloquearse. Antes de la actualización, se deben desactivar las extensiones innecesarias y se debe confirmar que cada extensión se ha cargado con éxito desde la sección de Configuración del Proyecto 1 .

Conclusión

La versión Godot 4.7 es una actualización de ingeniería madura que se desmarca de la filosofía de marketing de "añadir características mediáticas" a un motor de juegos y se centra sistemáticamente en los dolores crónicos de los ciclos de producción de juegos profesionales 4 . Como muestran claramente los análisis de la industria y de centros de comunidades independientes como Reddit, se ha alcanzado una estabilidad y una practicidad de producción que satisfarán las expectativas de los desarrolladores que migran desde motores consolidados como Unity 8 .

Mientras que AreaLight3D y la integración de imágenes HDR demuestran la competencia del motor en la visualización arquitectónica y proyectos fotorrealistas 3D de alta calidad, la inclusión de la infraestructura de Ray Tracing por hardware en el núcleo simboliza la preparación estratégica del motor para los estándares visuales del futuro 2 . Por otro lado, las transformaciones de desplazamiento en los nodos Control han eliminado el problema de la "ruptura de diseño", uno de los mayores pesadillas de los desarrolladores de UI; y las integraciones de VirtualJoystick y GABE han puesto fin a la dependencia externa (extensiones) para el mercado móvil 1 . Con los sistemas de imágenes submuestreadas de Vulkan que admiten foveated rendering, también se han maximizado los límites de rendimiento en el hardware XR 1 .

Modelado con la filosofía de código abierto y el esfuerzo de cientos de colaboradores (contributors), Godot Engine con su versión 4.7 presenta la variante más estable, amigable para el desarrollador (developer-friendly) y moderna de la generación 4.x que

aprovecha al máximo la capacidad del hardware. Una estrategia de migración aislada llevada a cabo teniendo en cuenta los cambios de API detallados, los límites de compatibilidad y los procedimientos de prueba de los proyectos existentes elevará indiscutiblemente la velocidad de iteración (iteration time) de los estudios de desarrollo en sus proyectos, los costos de mantenimiento del producto y la calidad gráfica del juego ante el usuario final.

*Información: Las imágenes han sido generadas por Google Gemini.