Para aclarar, se dice que el 90% de los datos en Godot son guardados en Resources. El otro 10% serían los Dictionary.
Pero expliquemos un poco qué carajo son:
Los Resources te permiten crear una estructura de datos estable, que sirva de plantilla para almacenar datos de forma permanente. Por ejemplo, podrías tener distintos stats para enemigos y así crear variaciones de un enemigo (incluyendo la textura o sprite). De ese modo, tienes un lobo azul (con 50 HP y 20 de Daño) y un lobo rojo (con 400 HP y 100 de Daño). La base es la misma pero lo que te permite es crear un nuevo enemigo sin tocar el código, solamente completando los datos y guardando el recurso (en este caso, red_wolf.tres y blue_wolf.tres).
Para crear el Resource sólo creamos un script, extendemos desde la clase Resource, se recomienda darle un class_name y, bien, llenar los datos que quieras. Además, se permite usar setget para alterar el setter y getter con funciones (por ejemplo, para usar clamp y limitar los valores mínimo y máximo), y podrías añadir más funciones para trabajar con tus datos. Luego, irías al file explorer de Godot, hacés click derecho sobre tu Resource, New, Resource (en el menú a la derecha, aparece la plantilla del Resource, en este caso Stats, para llenarla).
Se supone que ~~esta mierda~~ estos Resources son la base y el porqué ellos no se apoyan tanto en clases tradicionales. Como dije antes, los Dictionary se usan en los otros casos, cuando no tienes clara la estructura o quieres flexibilidad.
¿Si recomiendo Godot?
El software cumple la función de ser una especie de Unity libre. Intenta cooperar para que lo hagas más rápido. Sin embargo, como todo, la complejidad es inherente al Desarrollo de Software (y esto empeora exponencialmente con los juegos). Entonces, no importa qué herramienta elijas, te aseguro que vas a sufrir como un perro. Y no importa si antes alardeabas con las animaciones CSS o si te sentías el jefe del data center, te garantizo que es desafiante. Esto es porque insume mucho esfuerzo y tiempo tener algo valioso. Por ejemplo, los desarrolladores de suites de oficina no tienen que preocuparse de que sus aplicaciones sean divertidas o siempre vistosas (pueden decir que es funcional), pero al desarrollar un juego es central que los usuarios se diviertan y les guste el arte del juego.
Entonces, para desarrollar juegos, hay que estar realmente comprometidos con la causa. No existe el camino fácil por ninguna parte. Sólo maduras como desarrollador de juegos cuando aceptaste que "no queda otra que partirse el lomo" para tener el juego hecho. Una verdadera mierda pero ésa es la verdad.
