Curso "Godot 4 Multiplayer: Make Your Own Online Game" de GameDev.TV

Hace unos días que finalicé el curso que da título a este artículo y ya estoy listo para contaros lo que me pareció. 

Hice el curso en Udemy. También se encuentra en la plataforma propia de GameDevTV, aunque como ya tengo otros cursos de otras temáticas en Udemy prefiero seguir comprándomelos allí para tenerlos todo en un mismo sitio. Otra ventaja de Udemy es que suele contar con subtítulos en inglés, lo cual puede ser un auténtico salvavidas si el profesor tiene un acento muy cerrado. En teoría, la plataforma de GameDevTV debería permitir activar subtítulos, pero no he visto cómo en los pocos cursos que tengo allí.

En Udemy, el curso se anuncia prometiendo cubrir los siguientes temas:

• Construcción de un juego online multijugador usando las librerías de Godot 4.
• Crear mecánicas habituales en los juegos multijugador como baldosas interruptoras, objetos movibles, puertas a desbloquear, etc.
• Sincronización de estas mecánicas a través de internet para permitir que los jugadores puedan interactuar entre sí y colaborar para superar los retos.
• Usar la infraestructura de W4 Games para permitir que los jugadores puedan conectarse entre sí aunque no estén en la misma red local.

El juego que desarrolla para explicar estos principios es un sencillo plataformas 2D, en el que 2 jugadores podrán colaborar para alcanzar baldosas interruptoras que abran puertas y hagan aparecer puentes que permitirán acceder a zonas previamente inalcanzables. También se incluye la mecánica de abrir un cofre, para recoger una llave con la que abrir la llave de finalización de nivel. Como verás, el juego en si mismo es muy sencillo, pero permite cubrir una serie de mecánicas muy habituales en este tipo de juegos. 

Todo el primer bloque del curso, se dedica a darle forma al juego base. Si hace tiempo que no tocas Godot, te puede servir como repaso. Si nunca has tocado Godot, también te puede valer como tutorial introductorio.

En el segundo bloque es donde se empieza a implementar que los jugadores puedan conectarse entre sí, dentro de una misma red local. Al final resulta que, a Godot, le bastan 2 nodos especializados para ofrecer una experiencia multijugador completa. Todo un alarde de sencillez y elegancia que dice mucho de este engine. Entre esos 2 nodos especializados y las llamadas RPC desde el código, ya tienes todo lo que necesitas para montar tu juego online.

En el tercer bloque, el más largo, es donde se va explicando cómo aplicar los conceptos del bloque anterior para que las distintas mecánicas del juego se puedan sincronizar a todos los jugadores al mismo tiempo y que estos vean siempre el mismo estado del juego.

El curso implementa su código en GDScript, pero yo lo he seguido implementando mi código en C# y no he tenido problema alguno.

El profesor se explica muy bien, su pronunciación es buena y no divaga. El proyecto que ha elegido para sustentar sus explicaciones es lo suficientemente sencillo como para no estorbar por complejo, pero más que suficiente para cubrir las mecánicas más habituales que se suelen implementar en un plataformas. Al final del curso acabas teniendo una idea bastante buena de cómo articular un juego multijugador básico. 

Aun así, hay cosas mejorables. Para empezar, las herramientas multijugador de Godot (los 2 nodos y las llamadas RPC) se cubren de una manera bastante práctica, lo cual no está mal, pero me he quedado con las ganas de que profundizase en la parte teórica. Al final acabas intuyendo lo que hace cada cosa, pero no con la seguridad de saber lo que hace por dentro. Por ejemplo, se tratan las llamadas RPC y se usan ampliamente en el curso, pero me habría gustado que se detuviera más en ellas para explicar su funcionamiento general y cómo se utilizarían en otros contextos.

Otra cosa mejorable, es que a pesar de mencionar los servicios de W4 Games, en el curso no se les menciona para nada. Es cierto que en la letra pequeña advierten que esos contenidos no están disponibles aún y que llegarán más adelante, pero hace tiempo que W4 Games abrió su beta para que la gente probase sus servicios y esperaba que a estas alturas hubieran incluido esa parte en el curso, o que al menos hubiesen dicho cuándo lo harían. Nada de eso ha ocurrido y esa es la razón por la que no le he dado 5 estrellas en Udemy. Si finalmente, acaban incluyendo el bloque explicando cómo usar los servicios de W4 Games, revisaré al alza la puntuación.

A pesar de eso, el curso es muy recomendable, si bien no al precio completo con el que lo anuncian en Udemy y en GameDevTV. Mi consejo es que espera a que esté de oferta en alguna de esas dos plataformas para comprártelo. En GameDevTV no lo sé, pero en Udemy las ofertas son muy frecuentes, así que mi consejo es que no cometas la novatada de comprarlo por 50 o 90 € cuando es muy frecuente verlo ofertado por 10 o 15.

"Programming Game AI by Example" por Mat Buckland

No es fácil encontrar buenos libros sobre inteligencia artificial (IA) aplicada a juegos. La mayoría no pasan del nivel introductorio y cuando llegan a explicar el algoritmo A*, lo consideran ya material avanzado y lo dejan ahí.

En mi opinión, la gran joya en esta materia es el "AI for Games" de Ian Millington, que combina unos contenidos vastísimos con unas explicaciones claras, detalladas y realmente pertinentes para el desarrollo de juegos. Desde que lo leí no me había encontrado con otra obra que se le pudiera comparar hasta que me topé con este al que le dedicamos el artículo. No en vano, el libro de Buckland fue una de las referencias de Millington.

Es cierto que "Programming AI by Example" no alcanza en amplitud de contenidos a "AI for Games", pero sí es cierto que los que trata lo hace con gran profundidad y claridad. También hay que reconocerle que trata varios temas ausentes de la obra de Millington, como la integración de sistemas de scripting en nuestros juegos (para simplificar el diseño de los algoritmos de IA) y el capítulo sobre agentes guiados por objetivos.

El libro está lleno de buenas figuras ilustrativas que permiten seguir las explicaciones. 

A diferencia de Millington, las implementaciones no las ilustra en pseudocódigo, sino en C++; lo que para mi gusto es un punto negativo porque no se trata precisamente del lenguaje más intuitivo del mundo. También es cierto que el libro acumula ya algunos años y, cuando se publicó por primera vez, la única alternativa para crear juegos era C++. En todo caso, las explicaciones son lo suficientemente extensas y claras como para que el entendimiento pleno del código no sea imprescindible.

Me ha llamado también la atención la insistencia en mostrar diagramas de UML de las jerarquías de clases de las diferentes implementaciones. Entiendo por qué lo hace y tampoco es que sobren, pero es algo que me ha hecho sonreír por lo pasado de moda que está. Ya no se suelen ver diagramas de UML en los libros.

A pesar de todas esas señales del tiempo transcurrido desde la publicación del libro, el campo de la IA para juegos no ha avanzado tanto como para dejar desfasado su contenido. Estos siguen estando vigentes. Si acaso, se echan en falta algunas herramientas que han surgido posteriormente como los árboles de comportamiento o el aprendizaje neuronal.

Conclusión: el libro me ha parecido excelente. Recomiendo que lo leas lectura  antes del de Millington. De esa manera, se puede potenciar su utilidad como pieza introductoria para facilitar la comprensión posterior del Millington y ampliar con este lo que deja pendiente el de Buckland. Con esta aproximación creo que cubrirás lo mejor que se ha escrito hasta el momento en el campo de la IA para juegos.

Cómo implementar un MiniMap en Godot

Hace unos días publiqué un artículo sobre un curso de Godot que acababa de terminar en Udemy. Se trataba de un juego de acción en 2.5D, así que aunque el curso en sí no hablaba de ello, me pareció la base perfecta para aprender a hacer MiniMaps en Godot.

Como ya sabrás, un MiniMap es una pequeña ventana que incluyen muchos juegos para mostrar dónde se encuentra el personaje dentro del nivel. Tienes un ejemplo en la imagen que abre este artículo y que se corresponde con el MiniMap de War of Warcraft.

Resulta que implementar un MiniMap básico en Godot es muy fácil y, en su versión más básica, ni siquiera requiere código. Vamos empezar explicando cómo se puede implementar un MiniMap estacionario y a partir de ahí lo vamos a sofisticar iterativamente añadiéndole sucesivamente la siguientes características:

1. Haremos que el MiniMap se mueva siguiendo al personaje principal.
2. Representaremos al personaje y a su entorno con iconos, dentro del MiniMap.
3. Veremos cómo hacer para que el MiniMap sea redondo.
4. Adornaremos el MiniMap con un borde.

MiniMap básico estacionario

Este MiniMap no se mueve con el personaje sino que muestra una sección del escenario. Sólo tiene sentido si nuestro nivel es muy pequeño y puede mostrarse entero dentro del MiniMap. Aun así, a pesar de su limitada utilidad, es la base de la que parten todo los MiniMaps.

Para implementarlo tendremos que añadir los siguientes nodos a la jerarquía de nuestra escena:

El nodo SubViewportContainer nos permitirá anclar el MiniMap a la zona de la pantalla en la que queramos que se sitúe, simplemente eligiendo ese nodo y fijando su anclaje en la pestaña de la vista principal:

Una vez colocado el MiniMap probablemente querrás definir su tamaño. Para eso, tienes que fijar primero el tamaño del nodo Subviewport, encargado de mostrar la vista de la cámara. Para ello tienes que seleccionar ese nodo y configurar la propiedad Size:

Es posible que tras redimensionar el nodo Subviewport tengas que volver a fijar el anclaje del nodo SubViewportContainer.

Hecho eso, tendremos una ventana, superpuesta a la principal del juego, que mostrará lo que enfoque el tercer nodo: el de la cámara. Lo que tendremos que hacer es colocar dicha cámara sobre el escenario, enfocándolo en vertical. Yo suelo configurar esa cámara en proyección ortogonal porque así el MiniMap queda más claro. Con su parámetro Size podemos abarcar más o menos escenario dentro del enfoque. Por último, es importante desmarcar el parámetro Current para no usurpar la función de la cámara principal del juego. Al final, esos parámetros de la cámara pueden quedar quedar así:

En este punto ya tendremos la versión más básica del MiniMap.

Sin embargo, este MiniMap tiene muchas carencias que resolveremos en las secciones siguientes.

MiniMap móvil

El primer problema que tenemos en este punto es que al no moverse la cámara hay que ponerle un Size gigantesco para que todo el escenario quepa en la recuadro del MiniMap. Eso le resta valor porque cuanto mayor sea el escenario, más se reducirán sus detalles en el MiniMap. Lo que se hace normalmente en esos casos es reducir el Size de la cámara, haciendo que enfoque sólo una parte del escenario en torno al personaje del jugador y hacer que le siga. De esta manera, aunque la cámara no abarque todo el escenario sí que dará suficiente detalle del entorno del jugador, que es lo que realmente le interesa a este.

Para hacer que la cámara del MiniMap siga al jugador, tienes que añadirle a aquella el siguiente script:

Como verás, se limita a ubicar la cámara en la misma posición que el usuario, conservando la altura inicial a la que la hubiéramos colocado en el editor. Dado que hemos implementado el método _Process(), la posición de la cámara se actualiza en cada fotograma. El efecto será que la cámara se moverá con el jugador, enfocándole cenitalmente.

El parámetro _player es una referencia que habrá que pasar por el inspector, arrastrando el objeto del escenario del jugador sobre el campo _player del script. 

Representación con iconos de los personajes y los elementos del mapa

El siguiente problema será que, por mucho que hayamos acercado la cámara, es muy posible que muchos de los elementos importantes sean demasiado pequeños o no se vean con claridad. Para resolver eso, la mayor parte de los MiniMaps representan esos elementos con iconos, tal y como se puede ver en el MiniMap de ejemplo que inicia este artículo.

En mi caso particular, dado que mi juego era 2.5D, los personajes eran sprites por lo que al ser planos resultaban invisibles al enfocarlos cenitalmente con la cámara del MiniMap.

La solución consiste en añadir un sprite justo encima de los elementos que queramos que se muestren en el MiniMap. Esos sprites mostrarán el icono que queramos que represente a esos elementos.

Por ejemplo, en mi caso he añadido el sprite de un casco encima de mis enemigos.

Lógicamente, ese icono debe estar en un plano perpendicular al eje de enfoque de la cámara del MiniMap para que esta lo pueda captar bien. Si la cámara del MiniMap enfoca desde el eje Y, el icono tendrá que reposar en el plano XZ.

En este punto, la problemática será que esos iconos sean invisibles para la cámara principal del juego y sólo se muestren en la del MiniMap. Para resolverlo podemos usar las capas de renderizado.

En mi juego he creado las siguientes capas de renderizado, dentro de Project > Project Settings... > General > Layer Names > 3D Render:

Las piezas del escenario las he colocado en la capa 1, al personaje del jugador en la capa 1 y a los enemigos en la capa 3. Esto se configura en el apartado de VisualInstance3D del sprite principal de cada uno de los elementos. Por ejemplo, en el caso del sprite con el que represento al jugador, su configuración es:

Para los elementos 3D, la capa de renderizado se configura en el apartado del MeshInstance.

En cuanto a los iconos de los marcadores, tanto del jugador, como de los enemigos, los he dejado en la capa 4.

Para que la cámara principal del juego no muestre los iconos del MiniMap se configura su Cull Mask para que no muestre la capa donde hayamos situado dichos iconos.

En el caso de nuestro ejemplo, la cámara principal tiene el siguiente Cull Mask:

Teniendo en cuenta las capas que yo había creado, lo anterior significa que la cámara principal del juego sólo muestra el escenario (capa 1), al jugador (capa 2), a los enemigos (capa3), pero no los marcadores del MiniMap (capa 4).

Por contra, el Cull Mask de la cámara del MiniMap deberá incluir la capa donde estén los iconos.

En el caso del ejemplo, la cámara del MiniMap tiene la siguiente configuración:

Fíjate por tanto, que en el MiniMap se mostrará el escenario (capa 1) i los iconos de los marcadores (capa 4). No muestro ni al jugador ni a los enemigos porque estos ya está representados por sus respectivos marcadores.

El resultado será que el jugador y los enemigos se verán representados de la siguiente manera en el MiniMap:

MiniMap redondo

En este punto tendremos un MiniMap funcionalmente completo, aunque estéticamente modesto.

Puede ser que en nuestro juego nos encaje tener un MiniMap cuadrado, ¿pero cómo lo haríamos si quisiéramos un MiniMap redondo?

Hay varias maneras de hacerlo. Unos prefieren usar un shader, pero yo creo que es mucho más sencillo usar una máscara. Esta es un sprite que se superpone a una imagen para definir qué partes de la imagen se pueden ver y cuales no. El sprite que hace de máscara definirá las partes que se pueden ver con un alpha 1 (independientemente del color) y las que no con un alpha 0 (o sea transparente).

Un editor gráfico como Gimp te puede bastar para hace una máscara como la siguiente:

Importa la imagen de la máscara en Godot y asóciala a un nodo Sprite2D que debes situar como padre del MiniMask:

Para que el sprite haga de máscara debes fijar el parámetro Clip Children de su sección CanvasItem a Clip Only. Eso hará que enmascare a todos los nodos que tenga como hijos.

Es posible que cuando recoloques a los nodos del MiniMap debajo del sprite de máscara, te veas obligado a asegurar que los tamaños (Transform-Sizes) de los nodos SubviewPortContainer y Subviewport coincidan. De no coincidir es posible que sólo veas una porción del MiniMap. 

También asegúrate de que el el parámetro Anchor Preset del SubViewportContainer esté en FullRect para que se amolde al tamaño del sprite de máscara.

El problema de este esquema es que el MiniMap perderá el anclaje automático respecto a la pantalla, ya que el padre del MiniMap (el sprite de máscara) ya no se recolocará automáticamente cuando se redimensione la ventana del juego. En estos casos, suele ser buena idea colocar al sprite de máscara (ya a todos sus hijos) por debajo de una nodo PanelContainer, de tal manera que podamos anclar este a la posición de la pantalla que queramos.

En este punto, MiniMap será redondo, pero el problema será que por alguna razón el panel sobre el que se muestra no será transparente del todo (amplía la foto y fíjate en los bordes del MiniMap):

La causa es que el estilo por defecto de los paneles de Godot incluye que su fondo no sea transparente. Así que hay que cambiar eso. Ve a las propiedades del PanelContainer y, en la sección ThemeOverrides > Styles, crea un recurso StyleBoxEmpty. Eso reseteará los valores por defecto del estilo del Panel Container y este pasará a ser completamente transparente.

Borde del MiniMap

Lo normal es dotar al MiniMap de un borde que lo resalte respecto al fondo y que lo ponga a tono con la estética general del juego. Veamos cómo hacerlo.

Si no somos artistas podemos buscar en Internet bordes para nuestros MiniMaps. Eso sí, te aconsejo que revises los derechos de lo que encuentres, para asegurarte de que lo puedas usar en tu juego. Una búsqueda por los términos "Minimap circular texture download" puede ofrecerte muchos ejemplos. Uno de ellos es el que he usado en este tutorial:

Fíjate en que la imagen debe contener un canal Alpha, dejando con valor 0, todas aquellas zonas, como el interior del anillo, a través de las cuales queramos que se vea nuestro MiniMap.

La idea es colocar esa imagen sobre el MiniMap, tapando los bordes. Para hacerlo, tenemos que añadir un nodo TextureRect como hijo del PanelContainer del MiniMap. Sobre ese nuevo nodo deberemos arrastrar la imagen del borde, lo que la mostrará en el editor.

Es probable que la imagen tenga un tamaño que no nos encaje en el MiniMap, así que deberemos redimensionarla. Para eso, deberemos fijar el parámetro Expand Mode, del TextureRect, a Ignore Size. A partir de ahí, podremos cambiar el tamaño de la imagen del borde modificando su parámetro Custom Minimum Size. Probablemente también tengamos que cambiar los parámetros Position y Scale del nodo MiniMapMask para redimensionar y centrar la imagen del MiniMap dentro de la del borde.

El esquema de nodos resultante será el siguiente:

Y el resultado:

Fíjate que, en Godot, el orden de pintado de los nodos es de arriba a abajo de la jerarquía de la escena. Eso quiere decir que primero se pintan los nodos que están en la parte más cercana a la raíz y luego sus hijos. Por eso es importante que el TextureRect esté por debajo del MiniMapMask, de manera que primero se pinte el MiniMapMask y luego el TextureRect. La consecuencia de lo anterior será que el TextureRect se pintará encima del nodo MiniMapMask, tapando sus bordes. 

Prueba a invertir el orden y verás el efecto.

Opinión sobre el curso "Godot 4 C# Action Adventure: Build your own 2.5D RPG"

A lo largo del año pasado me empezó a interesar Godot como opción para desarrollar juegos. Estaba contento con Unity, pero lo que iba leyendo sobre Godot me resultaba superinteresante. Me atraía sobre todo su enfoque en agilizar y acelerar el desarrollo. Unity está muy bien, pero trabajar con él es lento. Tanta recarga del dominio a la mínima modificación de un script y la lentitud de las compilaciones hacen del flujo de trabajo en Unity más lento de lo que me gustaría. El escándalo del pasado septiembre, con el cambio unilateral de condiciones de Unity, me hizo tomar la decisión de empezar a aprender Godot. No sé si llegaré a desarrollar algo en Godot, pero siempre viene bien tener otras opciones si la permanencia en Unity se vuelve insostenible y tampoco está mal abrir el abanico de engines si estás aprendiendo a desarrollar videojuegos ya que todo los conceptos que aprendas en un engine probablemente te sean de utilidad en otro.

Así que me puse manos a la obra, empezando con libros sobre Godot de los cuales ya he ido hablando por aquí. Una vez comprendidos los conceptos básicos me puse a buscar cursos sobre Godot, para empezar a practicar de una manera guiada. Ya había hecho antes cursos de GameDevTV sobre Unity y me habían gustado, así que acabé comprándome un par de cursos suyos en Udemy. Sé que podría comprarlos en su propia plataforma, pero dado que también los venden en Udemy prefiero comprarlos allí y así centralizo todos mis cursos. De otra manera, al final empiezo a dispersarlos por las distintas plataformas y me acabo olvidando de lo que tengo en cada una. 

Uno de los que elegí es el que la da nombre a este artículo, "Godot 4 C# Action Adventure: Build your own 2.5D RPG",  y se diferencia de otros sobre Godot en que lo enfoca al desarrollo con C# en vez de con GDScript. GDScript tiene múltiples ventajas: es muy sencillo de aprender y leer, flexible, rápido y tremendamente integrado en el editor de Godot. Sin embargo, cuando vienes de Unity lo que quieres es que te allanen la curva de aprendizaje lo más posible y la decisión de Godot de soportar C# es una manera muy inteligente de facilitarle al salto a los desarrolladores de Unity. Aparte de evitarte tener que aprender otro lenguaje más, el uso de C# tiene múltiples ventajas adicionales:

• Incrementa el rendimiento de los juegos. Es cierto que los juegos de Godot desarrollados en C++ son más rápidos, pero desde luego los desarrollados en el C# de Godot son mucho más rápidos que los que usan GDScript.
• Mucho más soportado por los IDE. El editor de Godot ofrece una versión ligera de un IDE para GDScript, pero cuando vienes de un IDE hipervitaminado como Visual Studio o Rider el integrado en Godot se te queda muy, pero que muy, corto. Acabas echando en falta las comodidades que te ofrece de serie un IDE hecho y derecho. Es cierto que también puedes programar GDScript en esos IDE, pero su soporte en ellos está limitadísimo y sigues echando en falta cosas. Al final, cuando tomas la decisión de programar con C# en Godot, puedes hacerlo desde tu IDE de referencia y te sientes como en casa. Encima, Rider cuenta con un plugin oficial para Godot C# que hace que la experiencia de usarlo con Godot sea muy similar a la de usarlo con Unity.
• Te abre la puerta a usar librerías de terceros. A diferencia de Unity, Godot te deja que integres librerías de NuGet en tu proyecto, lo que reduce al mínimo las posibilidades de que te veas obligado a reinventar la rueda.
• Mayor sofisticación del código. GDScript va madurando poco a poco, pero aún dista de contar con todas las sofisticaciones y abstracciones que ya ofrece C#. Cuando vienes de Unity es muy difícil renunciar a muchos patrones de programación que ya has interiorizado en C#.

Este curso es uno de los pocos que se aproxima a Godot usando C#, a pesar de que la comunidad de desarrolladores de C# es una de las más vibrantes del ecosistema del engine.

Por tanto, mi objetivo principal no era tanto aprender nuevos conceptos como poner en práctica lo que ya sabía en un nuevo engine, usando C#. Quería comprobar cómo podría ser el flujo de trabajo con C# y Godot. El resultado ha sido plenamente satisfactorio. No sólo me ha resultado muy cómodo trabajar con Godot y C#, sino que además he aprendido unos cuantos trucos y conceptos por el camino.

El curso se enfoca a programar un pequeño juego de acción en 2.5D. Los escenarios son en 3D, pero los personajes con sprites 2D, de ahí lo de 2.5D. Lo de RPG del título... pues no aparece por ningún lado. No esperes una gestión de inventarios de objetos, ni una gestión de un árbol de habilidades, como se vería en un RPG. El juego acaba siendo puramente de acción, basado en atacar a los enemigos a estocadas y huir de ellos cuando empiezan a rodearte. Para darle a alegría a los combates, el juego implementa un par de ataques especiales con bombas y rayos.

Cosas que he aprendido en este curso:

• Para darle forma a los escenarios, te enseña a generar MeshLibraries, que son como paletas de objetos del escenario. Parece que Godot no admite aún que las paletas abarquen escenas (el equivalente a los prefab de Unity) sino sólo meshes con un collider asociado a ellos, pero al menos eso, unido al un sistema de rejillas permite darle forma a los escenarios de una manera cómoda y bastante precisa. Si acaso me ha resultado un poco incómodo moverme mientras la rejilla estaba activada porque el botón derecho del ratón, que se utiliza en el resto del editor, para el movimiento libre por el escenario, se usar para borrar objetos cuando estás en el modo rejilla.
• Viniendo de Unity, me parecía que el sistema de Nodos de Godot era demasiado granular. No he tardado en acostumbrarme y cogerle el aire. Al final resulta tan cómodo, o incluso más, que el sistema de componentes de Unity. El curso en todo caso lo explica muy bien.
• El sistema de Inputs de Godot es como una versión simplificada del New Input System de Unity. He agradecido que es muchísimo más fácil de configurar que el de Unity, aunque también es cierto que el juego sólo requiere de pulsaciones sencillas de teclas. Habrá que ver cómo se desenvuelve en juegos que requieras controles más complejos.
• En Godot no vas a echar de menos los Scriptable Object. Aquí se llaman Resources y les he visto bastantes posibilidades. La posibilidad, que te enseña el curso, de volcar un resource a un fichero para que lo usen como repositorio compartido de datos varios scripts (desacoplados entre sí) me ha parecido muy potente.
• Godot tiene un nodo, denominado AnimationTree, que viene a ser un Animator y un Animator Controller (todo junto) de Unity. Por un lado está más limitado en las transiciones entre animaciones (he echado en falta poder elegir en qué punto de la animación abandonar el estado anterior y en qué punto de la siguiente animación aterrizar en el siguiente estado) pero por otro lado se usa a través de un método travel() que permite transitar de un estado a otro de puntos dispares del grafo de estados usando A* para elegir la ruta. También cuenta con parámetros, como los de los Animator Controller de Unity, pero carece de triggers. El curso no habla de los AnimationTree, sino que opta por hacerse las máquinas de estado por código y llamar a pelo a las animaciones. A pesar de eso, yo me he empeñado en usar los AnimationTree con los guardias, para aprender a usar ese nodo. Mi conclusión por ahora es que las apariencias entre los AnimationTree de Godot y los AnimatorController son bastante superficiales. Aunque se usen para lo mismo su manejo es muy diferente. Si te empeñas en usar un AnimationTree mediante parámetros, como se haría en Unity, probablemente te veas en problemas. Echará también mucho de menos los trigger. Mi sensación es que al final tienes que sustituir el uso de triggers con llamadas a travel() y que los AnimationTree están mucho más encasillados en las animaciones que los Animator Controller, que me parecen más generalistas.
• El sistema de navegación de Godot es muy fácil de usar. Se parece mucho al de Unity. Si acaso he echado en falta que en el de Godot no parece que se pueda definir una altura de escalón para el agente, lo que me ha generado problemas con escalones pequeñitos que he tenido que sustituir con rampas invisibles.
• He echado en falta los Gizmos y los Handles de Unity. Esto no lo cubre el curso pero yo lo he indagado por mi cuenta. En un primer barrido no he encontrado nada evidente. Hay alguna mención en la documentación, pero reconozco que aún no me hago una idea. Tengo que indagarlo más.
• El curso me ha enseñado un sistema de combates basado en colliders (hit boxes y hurt boxes) que no se me había ocurrido y que simplifica enormemente otros enfoques que he usado para implementar combates a espada.
• El sistema de interfaces de usuario de Godot esté tirado. Muy fácil de usar. Si vienes de Unity se parece más a uGUI que al nuevo UI Toolkit, si bien es cierto que a diferencia de uGUI las cosas se editan en su propio editor en vez de solaparse con la vista 3D del escenario (algo que siempre me ha parecido horroroso de Unity).
• El sistema de señales y eventos de Godot es muy efectivo. Es cierto que en C# no es tan directo como en GDScript, pero una vez que te acostumbras a acabar la definición del nombre de tus eventos/señales con la coletilla ...EventHandler() todo va bien.
• El curso roza los shaders, pero sólo pone un ejemplo de un shader sencillito implementado por código (la versión Godot de GLSL). Me hubiera gustado que lo hubiera explicado usando los Visual Shaders de Godot (que los tiene) pero me he quedado con las ganas. Tendré que buscar otro curso que lo cubra.
• En cuanto a los sistemas de partículas, se parecen mucho a los de Unity.

En fin, no está mal. El riesgo de estos cursos es que sean demasiado básicos. Afortunadamente, este resuelve bastante bien el equilibrio entre empezar a explicar el engine desde cero y llegar hasta conceptos que resulten interesantes para gente que ya conozca otros engines.

Así que recomiendo este curso. No me he arrepentido de haberlo comprado y haberle dedicado tiempo. En cuanto a aquellos a los que les eche para atrás el inglés, os comento que el curso de Udemy tiene subtítulos en inglés, así que si ya lees libros de desarrollo de juegos en inglés no te será difícil seguir el hilo del curso. Además, el profesor habla de una manera muy pausada, su pronunciación es muy clara y usa un vocabulario muy sencillo, Yo al menos no he tenido problema para seguirle de oído.