~/devBitácora← Volver al inicio
Devlog #2Ago 2026

Clean Code en UI: Nodos Únicos en Godot 4 para interfaces mantenibles

Cómo el uso de Scene Unique Nodes (%) y Themes en Godot reduce la fragilidad del código al iterar y rediseñar la interfaz gráfica.

Imagen destacada para Clean Code en UI: Nodos Únicos en Godot 4 para interfaces mantenibles

Cualquiera que haya trabajado en el front-end de una aplicación web sabe que la interfaz gráfica (UI) es una de las partes que más iteraciones sufre durante el desarrollo. El diseño se ajusta, los elementos se agrupan, se mueven de sitio… y si el código está fuertemente acoplado a esa estructura visual, todo falla al mínimo cambio.

En Godot ocurre exactamente lo mismo. Al empezar a trastear con el sistema de UI para mi juego, me di cuenta de que acceder a los nodos mediante rutas relativas (como $CanvasLayer/VBoxContainer/HealthBar) generaba un código muy frágil. En el momento en que decides meter esa HealthBar dentro de un MarginContainer para ajustar un poco el diseño, el script falla porque la ruta ya no coincide.

El salvavidas: Scene Unique Names (%)

Revisando el módulo de interfaces de usuario (UI), descubrí una de esas pequeñas funcionalidades que mejoran la Developer Experience (DX) de forma radical: el Access as Unique Name.

En Godot, puedes hacer clic derecho sobre cualquier nodo de tu escena y marcarlo como “Access as Unique Name”. Esto le añade un símbolo de porcentaje (%) delante de su nombre en el árbol de nodos.

A partir de ese momento, puedes referenciarlo en tu script de forma directa, sin importar dónde esté anidado dentro de esa escena:

@onready var health_bar: ProgressBar = %HealthBar

¿Por qué esto me parece fundamental para mantener el código limpio?

Le veo tres grandes ventajas que se alinean con las buenas prácticas de desarrollo:

  1. Resistencia a refactorizaciones: Si muevo el nodo %HealthBar a otra rama dentro de la misma escena, la referencia no se rompe. Godot se encarga de encontrarlo en tiempo de ejecución. Esto te da libertad para iterar y mejorar el diseño visual sin miedo a tener que reescribir las rutas en el código.
  2. Acceso directo y limpio: Nos olvidamos de rutas larguísimas y difíciles de leer. El código queda mucho más declarativo.
  3. Convención clara: Cuando veo un % en un script, sé instantáneamente que ese nodo es una pieza clave de la UI o un elemento interactivo importante, no un simple contenedor estructural. En mi caso, cualquier nodo con el que vaya a interactuar en un script lo declaro como unique.

Separando el estilo de la estructura

Aprovechando que hablamos de mantenibilidad en UI, otro concepto clave que me llevé de estas prácticas es la separación de responsabilidades. Al igual que en desarrollo web separamos el HTML (estructura) del CSS (estilos), en Godot es vital no dejar hardcodeados los estilos visuales directamente en las propiedades de cada nodo.

La mejor forma que he encontrado de evitar esto es creando recursos de tipo Theme (archivos .res o .tres). Configuras tus estilos (StyleBoxFlat, StyleBoxTexture, etc.) en el Theme y se lo aplicas al nodo raíz de tu interfaz.

De esta forma, si más adelante decido cambiar el color primario de los botones o el grosor de los bordes, lo hago centralizado en un único archivo, en lugar de ir modificando las propiedades nodo por nodo.

Poco a poco, voy comprobando que aplicar prácticas de desarrollo de software estándar al motor de Godot ayuda muchísimo a mantener el proyecto saneado a medio y largo plazo.