19 julio 2025

Los Resources en Godot y el riesgo de compartirlos

En Godot, los Resources (recursos) son un tipo de objeto que se utiliza para almacenar y gestionar datos reutilizables en un proyecto. Son componentes modulares que pueden ser creados, guardados, cargados y compartidos entre diferentes nodos o escenas dentro del motor. Los recursos son esenciales para organizar y estructurar proyectos de manera eficiente.

Están pensados para almacenar información específica, como configuraciones, propiedades o datos personalizados, que pueden ser accedidos o modificados por nodos u otros sistemas. Los recursos pueden guardarse como archivos (generalmente con extensión .tres para recursos textuales o .res para binarios) y cargarse en el proyecto usando ResourceLoader. Esto permite compartir recursos entre escenas o incluso entre proyectos, al no estar ligados una escena específica, sino que pueden ser referenciados por cualquier nodo o script.

Las ventajas de usar recursos son varias:

  • Modularidad: Facilita la reutilización de datos sin duplicarlos.
  • Organización: Ayuda a mantener los datos separados del código o las escenas.
  • Flexibilidad: Puedes modificar un recurso y los cambios se reflejarán en todos los nodos que lo usen.

Godot ya trae muchos predefinidos, pero nosotros podemos crear los nuestros extendiendo la clase Resource. Por ejemplo, para un proyecto que estoy desarrollando en Godot C# he creado el siguiente recurso:

Ejemplo de recurso personalizado en Godot C#
Ejemplo de recurso personalizado en Godot C#

Como verás, no tiene mucho misterio. Basta con heredar de Resource y definir los campos/propiedades que queramos que tenga el recurso. Lo que sí merece mención aparte son los atributos. 

Como en cualquier otro script de Godot, el atributo [Export] sirve para que el campo al que decora sea editable en el inspector cuando se use el recurso. 

En cuanto al atributo [GlobalClass] de la línea 7, se necesita para que tu recurso personalizado esté disponible en el buscador del editor, cuando quieras usar el recurso. 

El cuanto al atributo [Tool], sólo es necesario si vas a necesitar acceder al contenido de tus recursos desde código que se ejecute en el editor (y no sólo en el juego).

Este recurso en concreto lo uso para poder crear un array de ellos en otro nodo y almacenar en cada uno de ellos enlaces a otros nodos presentes en la escena (ese enlace es precisamente el campo NodePath). Podría haber añadido métodos al recurso, nada te lo impide, por ejemplo, para validar los datos que se guarden en el recurso, pero en mi caso no me ha hecho falta.

Ejemplo de uso de mi recurso personalizado

Cuando pinches en cada recurso, lo desplegarás y podrás ver su contenido, así como editarlo.

Edición del contenido de los recursos
Edición del contenido de los recursos

Si vienes del mundo de Unity, los recursos son el equivalente a los Scriptable Object dado que también permiten guardar sus instancias como un asset más del proyecto. 

También cubren el hueco de las clases serializables de Unity. Aunque Godot C# tiene acceso al atributo [Serializable] de C#, a diferencia de Unity, Godot no es capaz de mostrarlas en el inspector. Por eso, la alternativa es crear una clase heredera de Resource con los campos que en Unity le habríamos puesto a la clase serializada. Tengo una versión en Unity de todo el ejemplo anterior y allí lo he resuelto haciendo de WeightedBehavior una clase serializable.

Los recursos son ubicuos en Godot, te los encuentras en todas partes. Por ejemplo, cada vez quieras usar un nodo Area2D, para crear un área de detección, dicho nodo te exigirá colgarle otro de tipo CollisionShape2D, con el que definir los límites del área de detección.

Un nodo Area2D utiliza a otro nodo CollisionShape2D para definir su área
Un nodo Area2D utiliza a otro nodo CollisionShape2D para definir su área

Lo interesante es que no podremos definir la forma del CollisionShape2D hasta que creemos un nuevo recurso en su campo Shape.

Un nodo CollisionShape2D con un recurso RectangleShape2D asociado
Un nodo CollisionShape2D con un recurso RectangleShape2D asociado

Esto responde a la obsesión de Godot por separar responsabilidades. En este caso, el nodo CollisionShape2D se limita a implementar una funcionalidad en un área, pero la forma de ese área se guarda en un recurso (en este caso, RectangleShape2D). 

Si extendemos el combo veremos que RectangleShape2D no es el único recurso que podremos asociar a ese campo.

Los distintos recursos que se pueden asociar al campo Shape
Los distintos recursos que se pueden asociar al campo Shape

Si conoces los ScriptableObjects de Unity, intuirás la utilidad de los recursos de Unity y si no, ya te irás dando cuenta conforme vayas usando el engine. Al final, lo más probable es que modeles los recursos en tu cabeza como "cajitas con datos".

Una de las utilidades de estas "cajitas" es que múltiples nodos pueda leer datos de la misma cajita, en vez de repetir dichos datos en cada nodo. Se trata de una medida de eficiencia que Godot sigue por defecto de manera transparente al usuario. 

Generalmente no pasa nada, pero a veces nos puede dar sorpresas si no somos conscientes de este comportamientos. Te pongo un ejemplo que acabo de sufrir "en mis propias carnes". 

En mi proyecto he desarrollado un sensor de cono. A todos los efectos es un cono de visión. La escena que compone el sensor cuenta con los siguientes nodos:

Nodos que componen mi sensor
Nodos que componen mi sensor

Las capturas de antes del CollisionShape2D están sacadas precisamente de esta escena.

El funcionamiento general es que la definición del parámetro de alcance y apertura del cono (definidos desde otro nodo) hacen que el nodo BoxRangeManager redimensione el CollisionShape2D para que sólo se detecten los objetos que estén dentro de su área. Luego, se hace un filtrado adicional más fino por ángulo y por distancia, pero el primer filtrado "grueso" es por si el objeto detectado entra en la caja.

Un agente de mi proyecto al que le he agregado mi sensor
Un agente de mi proyecto al que le he agregado mi sensor 

En la captura anterior, la caja azul es precisamente el área del RectangleShape2D.

Con un sólo agente todo funcionaba estupendamente. El problema empezó cuando añadí un segundo agente con otro sensor de cono.

Un ejemplo de problema al instanciar escenas con recursos
Un ejemplo de problema al instanciar escenas con recursos

Para mi sorpresa, los respectivos RectangleShape2D (ojo a la cursiva) se empeñaban en tener el mismo tamaño. Cuando cambiaba las dimensiones en uno de los agentes, ambas áreas tenían las dimensiones fijadas en ese agente, y cuando pasaba a cambiarlas en el otro agente entonces ambas áreas pasaban a configurarse con esas últimas dimensiones.

Tardé un buen rato en darme cuenta del problema. La cuestión era que no había dos RectangleShape2D independientes. Como los RectangleShape2D son recursos, todas las instancias del sensor usaban, y modificaban, el mismo recurso. De ahí la cursiva de antes, no había "respectivos" RectangleShape2D sino uno sólo compartido por los sensores de ambos agentes.

¿Cómo se soluciona esto? ¿Estamos condenados a usar una única instancia de nuestro sensor? Obviamente no, pero la solución no es tan evidente.

La clave estar en volver a la configuración del nodo CollisionShape2D y pinchar en el recurso RectangleShape2D para configurarlo por dentro.

Configuración interna del recurso RectangleShape2D
Configuración interna del recurso RectangleShape2D

Dentro de esa configuración, el campo Size es evidente y responde a las dimensiones del recurso.

El campo clave esté dentro del apartado Resource y se llama Local To Scene. Por defecto viene desmarcado, lo que significa que todas las instancias de la escena actual compartirán este recurso. En otros caso, esta configuración puede ser beneficiosa, pero en el mío provocaba el problema que te acabo de describir.

Por tanto, la solución era marcar este campo Local To Scene. Al hacerlo, cada instancia de la escena creará su propia copia del recurso y trabajará con ella. Al marcarlo y salvar la escena, ambos agentes mostraron la configuración correcta de sus respectivos (ahora sí) RectangleShape2D.

Problema corregido

Así que ten cuidado cuando utilices recursos en tus escenas de Godot. Ten presente que el comportamiento por defecto de Godot será compartir los recursos entre las distintas instancias de la escena. Por eso, si detectas algún caso en el que pueda haber instancias que necesiten personalizar los valores de ese recurso, deberás anticiparte a los problemas y marcar el valor Local To Scene, para que cada instancia tenga su propia copia del recurso.

Espero que este artículo te sirva para ahorrarte problemas como el mío.

16 julio 2025

Los live-games y el riesgo del power creep

Internet ha cambiado radicalmente el mundo del desarrollo de los videojuegos, desde aquellos tiempos en que la promoción de estos se basaba en artículos en revistas especializadas que ofrecían discos con demos. Gracias a la hiperconectividad que tenemos en casa, el acceso a los juegos se ha vuelto inmediato y estamos sometidos a un bombardeo constante de anuncios de otros nuevos. Para el jugador, el reto ya no es enterarse de qué juegos salen, sino elegir los que más le puedan gustar entre un universo casi infinito de posibilidades. Para los desarrolladores, el reto sigue siendo llegar al jugador, pero no por falta de medios para hacerlo sino por lo complicado que es despuntar en un mercado saturado.

En un ecosistema así, muchas casas desarrolladoras prefieren no estar sacando nuevos juegos continuamente, sino centrarse en uno sólo y hacerlo evolucionar con el tiempo, ganando nuevos jugadores poco a poco y fidelizándolos durante años. La idea es que, al centrar los esfuerzos en un único juego a lo largo de un tiempo prolongado, hay más posibilidades de despuntar entre la competencia e ir ganando notoriedad. Dicha evolución se suele hacer a partir del análisis de una telemetría exhaustiva de los jugadores, con la que los desarrolladores puedan entender cómo interactúan con el juego, que partes disfrutan más, cuáles menos y qué echan de menos. Con esos datos, los desarrolladores pueden hacer pivotar al juego hacia los gustos cambiantes de su público, ir ganando nuevos jugadores y reteniendo a los anteriores. Con frecuencia, este proceso de evolución hace que, con el paso de los años, el juego no se parezca en nada a lo que era inicialmente.

Este tipo de juegos es lo que se conoce como live-game (o juego en vivo), término que se usa principalmente en el contexto de los videojuegos para referirse a un título que recibe actualizaciones continuas, contenido nuevo y soporte activo por parte de los desarrolladores después de su lanzamiento. También conocido como juego como servicio (Game as a Service, GaaS), se caracteriza por mantener una experiencia dinámica y evolutiva para los jugadores, fomentando una comunidad activa a lo largo del tiempo. 

Fortnite
Fortnite es uno de los ejemplos más claros de live-game actuales

El modelo de negocio

Esta continuidad en el servicio supone mantener servidores desde los que funcione el juego y se haga telemetría de los usuarios, contar con un equipo de desarrolladores que sigan actualizando el juego con nuevos contenidos y mecánicas, así como realizar campañas de marketing constantes que atraigan nuevos jugadores. Por tanto, estos juegos necesitan una inversión continua que no es sostenible con el modelo clásico de monetizar el juego con su venta inicial al jugador. Con estos juegos los desarrolladores tienen que acudir a modelos de monetización continua. 

El más clásico de ellos es el de la subscripción, en el que el World of Warcraft de Blizzard fue un pionero que aún pervive. El problema de las subscripciones es que el gasto recurrente que conllevan puede suponer una barrera económica o psicológica a la entrada de nuevos jugadores, bien porque no puedan asumir ese gasto o bien porque no tengan claro que vayan a jugar tanto al juego como para amortizarlo.

World of Warcraft
World of Warcraft fue el pionero

Otras casas desarrolladoras prefieren eliminar esa barrera de entrada haciendo completamente gratuito el juego, sin costes de adquisición ni subscripciones. En estos casos la monetización puede venir de la venta de grandes paquetes de contenidos opcionales, en forma de DLC, o de contenidos con un volumen mucho menor, con un coste también reducido... y aquí llegamos a las microtransacciones.

Las microtransacciones son compras pequeñas dentro de un videojuego (o aplicación) que permiten a los jugadores adquirir contenido digital adicional usando dinero real. Suelen ser opcionales y se supone que están diseñadas para mejorar la experiencia de juego. Su coste es bajo, generalmente van desde céntimos hasta unos pocos euros por transacción. Los ejemplos más habituales de contenidos ofrecidos a través de transacciones son:

  • Cambios cosméticos respecto al juego base: Skins, atuendos o personalizaciones visuales de las armas (ejemplo: skins en Fortnite).
  • Ventajas de juego: Objetos que facilitan el progreso, como potenciadores o recursos (ejemplo: gemas en Clash of Clans).
  • Contenido adicional: Niveles, personajes o historias extras.
El modelo de negocio

Para el desarrollador, las microtransacciones suponen un riesgo mucho menor que los DLC. Con un DLC hay que desarrollar mucho contenido y, si no triunfa, las pérdidas pueden ser muy importantes. Las microtransacciones son mucho más granulares, al ser tan pequeñas, su coste es reducido y el riesgo también. Combinadas con una buena telemetría que permita seguir su aceptación entre los jugadores, se pueden usar varias microtransacciones fallidas para centrar el tiro de lo que le gusta a los usuarios y, a partir de ahí generar otras muchas que den en el blanco de lo que estos quieren comprar. Es mucho más fácil entrar en un balance de caja positivo si se cuenta con un equipo de análisis competente y unos desarrolladores y artistas creativos.

Las críticas

Para el jugador, las microtransacciones tienen el atractivo del capricho a coste nimio. Son "bombones" que resultan fáciles de comprar porque a primera vista su coste parece irrelevante, si bien, con el paso del tiempo, el coste acumulado puede ser considerable. Esa facilidad en el gasto ha hecho que muchos acusasen a las microtransacciones de generar adicción. Estas acusaciones tuvieron especial virulencia con las loot-boxes (o cajas de botín), microtransacciones donde los jugadores pagan (con dinero real o moneda virtual del juego) para obtener una caja virtual que contiene recompensas aleatorias. Estas recompensas pueden incluir objetos cosméticos, personajes, armas, potenciadores u otros elementos, pero el contenido exacto es desconocido hasta abrir la caja, lo que introduce un elemento de azar similar a las apuestas. Esa similitud ha llevado a que algunos países (como Bélgica y Países Bajos) hayan restringido o prohibido las loot boxes al considerarlas apuestas. Otros exigen que se publiquen las probabilidades de obtener ciertos ítems. Al final, debido a las críticas, muchos desarrolladores han reducido el uso de loot boxes o han optado por sistemas más transparentes, como pases de batalla o tiendas directas donde los jugadores compran exactamente lo que quieren. Algunos juegos, como Rocket League, eliminaron las loot boxes tras incluirlas. No es el único caso, en Star Wars Battlefront II (2017), las loot boxes generaron una gran controversia por su impacto en la jugabilidad, lo que llevó a EA a modificarlas tras críticas masivas, a pesar de que todo el modelo de monetización giraba en torno  ellas, por lo que su retirada supuso el final del atractivo económico del juego para su productora.

Loot boxes


La adicción no es la única crítica que reciben las microtransacciones. Otra de las más recurrentes es que, al dar ventajas injustas a quienes gastan más, reduzcan el juego a un pay-to-win que frustre a los que no estén dispuestos a pagar en la misma proporción. El pay-to-win puede disuadir incluso a los que sí tuvieran poder adquisitivo para permitirse las microtransacciones al no sentirse interesados por una experiencia de juego en la que primase más la cartera que la habilidad.

El riesgo del Power Creep

Otro peligro de las microtransacciones es lo que se denomina el power creep. Cuando un juego usa las microtransacciones como modelo de monetización, tiene que sacar contenido continuamente y además hacer más atractivo que el anterior para que los jugadores vayan comprando lo nuevo y no se conformen con lo que ya tienen. Hasta aquí lo normal, pero hay una posibilidad de que esta dinámica torne en un círculo vicioso que puede acabar siendo perjudicial para el juego, tanto desde el punto de vista de los desarrolladores como de los jugadores. El power creep (o "escalada de poder") se refiere al fenómeno en el que los desarrolladores introducen nuevo contenido (personajes, armas, habilidades, etc.) que es significativamente más poderoso que el contenido anterior, haciendo que los elementos previos queden obsoletos o menos competitivos. Por tanto, es un fenómeno que afecta sobre todo a las microtransacciones enfocadas a ofrecer ventajas en el juego.

Cuando el power creep se prolonga en el tiempo, puede introducir graves inconvenientes en el juego. Los más destacados son:

  • Impacto en la imagen del juego: Aplicado a juegos multijugador competitivos, donde los jugadores que no gastan dinero se enfrentan a desventajas claras, supondrá que el juego acabe teniendo la mala prensa de ser considerado un pay-to-win.
  • Impacto en la mecánica de juego: Los nuevos personajes, armas o ítems suelen tener estadísticas, habilidades o efectos superiores a los existentes, lo que desplaza el equilibrio del juego. Con el tiempo, esa "carrera armamentística" puede hacer evolucionar la mecánica de juego hasta que no se parezca en nada a como estaba concebida inicialmente... y probablemente no para bien.
  • Impacto en el desarrollo: Es muy difícil mantener indefinidamente una dinámica de desarrollo en la que en cada iteración hay que sacarse de la chistera nuevas ventajas, más poderosas que las anteriores, pero que no den al traste con la diversión de la mecánica de juego.
  • Impacto en los jugadores: la obsolescencia del contenido antiguo hará que los jugadores que usaban objetos o personajes previos pueden sentirse en desventaja, ya que estos ya no son tan efectivos conforme pase el tiempo. Quienes invirtieron tiempo o dinero en contenido antiguo pueden sentir que su esfuerzo fue inútil. Esto puede hacer que acaben desencantándose del juego y lo abandonen.
Power creep en las cartas de Pokemon
Power creep en las cartas de Pokemon

El power creep fuera de los videojuegos

En realidad, el power creep no es exclusivo de los live-games. Si hacemos memoria podemos encontrar ejemplos similares en el mundo de las series de televisión. Si te pones a pensar en las que has visto hasta el momento, te darás cuenta de que muchas se enfocan a una estructura de "vencer-al-villano-de-la-temporada". Para mantener el interés, dichos villanos son cada vez más poderosos, lo que hace las situaciones más dramáticas y extremas. Sin embargo, ese enfoque no es sostenible. Conforme pasan las temporadas los villanos de las primeras empiezan a parecer irrelevantes, comparándolos con los de las últimas. Por otro lado, el creciente dramatismo necesario para vencer a enemigos tan poderosos puede alcanzar un punto que desborde hacia el ridículo y la incredulidad. 

Hay muchos ejemplos de series que han sufrido este fenómeno, pero quizás una de las más evidentes es Dragon Ball. Los fans de Akira Toriyama recordarán como la serie empieza siendo un relato alegre y travieso, con un niño como protagonista, y unos enfrentamientos que se limitan a golpes de artes marciales. Con el tiempo, aparece la técnica de la "onda vital" o "Kame Hame Ha" (según la traducción e la serie que hayas visto) como un rayo legendario y definitivo. 

Dragon Ball al principio

Pero como la serie no para ahí, tampoco lo hacen las técnicas de combate ni los enemigos. Conforme la serie va avanzando, los enemigos se hacen más fuertes, ya no basta con pegarles para vencerles, la "onda vital" se queda corta, así que los protagonistas se hacen adultos, aprenden a volar y a lanzar nuevos tipos de rayos (la wikipedia identifica hasta 18 versiones distintas de la "onda vital", cada una de ellas de creciente poder). Con tanto despliegue de poder, los combates de la serie se vuelven tan aparatosos que un golpe mal dado puede acabar partiendo un planeta en dos. Al llegar, a este punto la serie ya había perdido su alegría y vitalismo y se había reducido a combatir a una larga sucesión de villanos más poderosos que los anteriores. Fue cuando perdí el interés y me desconecté de la serie, aunque me consta que siguió durante mucho tiempo y con abundantes spin-offs. 

Dragon Ball, ya víctima del power creep

Posibles soluciones al Power Creep

Esto, que ya pasaba con las series, puede pasarle también a un live-game, minándolo hasta su fin. Evitar o mitigar el power creep exige que los desarrolladores diseñen estrategias que equilibre la mecánica de juego y mantengan la experiencia justa, divertida y sostenible a largo plazo. Los enfoques que se suelen seguir son:

  • Enfocar las microtransacciones a la venta de contenido cosmético: Al tratarse de cambios meramente visuales (como skins o efectos visuales) no hay cambios funcionales que puedan afectar a la mecánica de juego, lo que mantiene su equilibrio. Un ejemplo de este enfoque es Fortnite, que centra la mayoría de sus microtransacciones en skins y bailes, evitando que el poder del jugador dependa de compras, por lo que estos no sienten presión por gastar para mantenerse competitivos, y el power creep funcional es mínimo.
  • Diseño de contenido lateral (sidegrading) en lugar de mejoras directas: En lugar de introducir nuevos elementos (personajes, armas, habilidades) que sean estrictamente más poderosos, los desarrolladores crean contenido con características diferentes pero equilibradas, que ofrecen nuevas formas de jugar sin superar al contenido existente. Por ejemplo, en Overwatch, los nuevos héroes se diseñan con habilidades únicas que no necesariamente son más fuertes, sino que aportan estilos de juego distintos. Esto minimiza la obsolescencia del contenido anterior, ya que la elección entre uno u otro se basa en preferencias o estrategias, no en poder bruto.
  • Ajustes de equilibrio regulares (buffs y nerfs): Los desarrolladores monitorean el meta del juego y ajustan las estadísticas o habilidades de elementos nuevos y antiguos para mantener un equilibrio competitivo. Por ejemplo, en League of Legends, los parches regulares ajustan a los campeones para evitar que los nuevos dominen el juego, fortaleciendo a los menos usados (buffs) o debilitando a los dominantes (nerfs). Con esta técnica se mantiene la relevancia de contenido antiguo y evita que el nuevo sea abrumadoramente superior.
  • Limitar el impacto de la progresión: Se trata de diseñar el juego para que las mejoras de poder tengan un impacto limitado o estén restringidas a ciertos modos (como PvE en lugar de PvP). Por ejemplo, en Destiny 2, el equipo nuevo puede ser más fuerte, pero los modos competitivos a menudo tienen límites de poder para igualar a los jugadores. Esto reduce la percepción de pay-to-win y mantiene la equidad en entornos competitivos.
  • Implementar sistemas de rotación o meta cambiante: Se basa en introducir cambios en las reglas del juego, modos o eventos que alteren qué elementos son más efectivos, sin necesidad de hacerlos más poderosos. Por ejemplo, en Hearthstone, la rotación de cartas entre formatos estándar y salvaje asegura que las cartas antiguas no compitan directamente con las nuevas, controlando el power creep.
  • Reutilización y mejora de contenido antiguo: Se trata de actualizar personajes, armas o ítems antiguos para que sigan siendo relevantes, en lugar de reemplazarlos con contenido nuevo más fuerte. Es el enfoque que sigue World of Warcraft, modificando las clases antiguas para asegurar que sigan siendo viables en nuevas expansiones. De esta manera, los jugadores perciben que la inversión realizada en contenido antigua mantiene su valor.
Soluciones al problema

Conclusión

Para mi gusto, el enfoque más sencillo es el seguido por Fortnite, de limitarse a vender contenidos cosméticos. Al no afectar a la jugabilidad, no requiere un esfuerzo de análisis y de revisión del contenido con el paso del tiempo. Aunque también es verdad que la mecánica de juego de Fortnite es tan sencilla, y su marco escenográfico tan plano, que puede permitirse la heterogeneidad loca de personajes que se dan en sus batallas (que más bien parecen un extracto de Ready Player One). 

Sin embargo, otros juegos basados en mundos con una ambientación mucho más marcada, como pueden ser los de World of Warcraft o Star Wars, probablemente no tengan tanto margen para ofrecer heterogeneidad visual sin que la cosa degenere en un delirio estético en el que no se reconozca el mundo en el que quieren sumergirnos.

Se trata por tanto de estudiar nuestro juego y ver hasta donde podemos llegar con cada una de las estrategias anteriores. La solución no tiene por qué ser apostar por una sola de las estrategias, sino que podemos optar por enfoques mixtos. El peso que le demos a cada una de las estrategias en nuestra mezcla final dependerá del marco argumental de nuestro juego, de nuestra disponibilidad de creativos para crear contenidos visuales, y de analistas y programadores para revisar y ajustar aquellos contenidos que pudieran afectar a la mecanica de juego.