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.
