"Godot 4 C# Action Adventure: Build your own 2.5D RPG" course review

Throughout the past year, I became interested in Godot as an option for game development. I was content with Unity, but what I was reading about Godot was fascinating to me. I was particularly drawn to its focus on streamlining and speeding up development. Unity is great, but working with it is slow. The constant reloading of the domain with even the slightest script modification and the slow compilation times make the workflow in Unity slower than I would like. The scandal last September, with Unity's unilateral change in terms, made me decide to start learning Godot. I'm not sure if I'll end up developing anything in Godot, but it's always good to have other options if staying with Unity becomes unsustainable, and it's also not bad to broaden the spectrum of engines if you're learning game development, as the concepts you learn in one engine will likely be useful in another.

So, I got down to it, starting with books on Godot, which I've been discussing here. Once I understood the basics, I started looking for courses on Godot to start practicing in a guided way. I had taken GameDevTV courses on Unity before and liked them, so I ended up buying a couple of their courses on Udemy. I know I could buy them on their own platform, but since they also sell them on Udemy, I prefer to buy them there and centralize all my courses. Otherwise, I end up scattering them across different platforms and forgetting what I have on each one.

One of the courses I chose is the one that gives its name to this article, "Godot 4 C# Action Adventure: Build your own 2.5D RPG" and it differs from others on Godot in that it focuses on development with C# instead of GDScript. GDScript has multiple advantages: it's very easy to learn and read, flexible, fast, and tightly integrated into the Godot editor. However, when coming from Unity, what you want is to smooth the learning curve as much as possible, and Godot's decision to support C# is a very smart way to ease the transition for Unity developers. Apart from saving you from having to learn another language, using C# has multiple additional advantages:

1. Increases game performance. It's true that Godot games developed in C++ are faster, but games developed in Godot's C# are much faster than those using GDScript.
2. Much better supported by IDEs. Godot's editor offers a lightweight version of an IDE for GDScript, but when coming from a fully-featured IDE like Visual Studio or Rider, Godot's built-in IDE falls very short. You end up missing the conveniences that a proper IDE offers by default. While you can also program GDScript in those IDEs, their support for it is very limited, and you still miss things. Ultimately, when you decide to program in C# in Godot, you can do it from your preferred IDE and feel right at home. Plus, Rider has an official plugin for Godot C# that makes the experience of using it with Godot very similar to using it with Unity.
3. Opens the door to using third-party libraries. Unlike Unity, Godot allows you to integrate NuGet libraries into your project, minimizing the chances of having to reinvent the wheel.
4. Greater code sophistication. GDScript is gradually maturing, but it still lacks many of the sophistications and abstractions that C# already offers. When coming from Unity, it's very difficult to give up many programming patterns that you've internalized in C#.

This course is one of the few that approaches Godot using C#, even though the C# developer community is one of the most vibrant in the engine's ecosystem.

Therefore, my main goal was not so much to learn new concepts as to put into practice what I already knew in a new engine, using C#. I wanted to see what the workflow could be like with C# and Godot. The result has been fully satisfactory. Not only did I find it very comfortable to work with Godot and C#, but I also learned a few tricks and concepts along the way.

The course focuses on programming a small 2.5D action game. The environments are in 3D, but the characters are 2D sprites, hence the 2.5D aspect. As for the RPG part in the title... well, it doesn't show up anywhere. Don't expect inventory management or skill tree management, as you would see in an RPG. The game ends up being purely action-based, focusing on attacking enemies with stabs and fleeing from them when they start to surround you. To add excitement to the battles, the game implements a couple of special attacks with bombs and lightning.

Things I've learned in this course:

• To shape the environments, it teaches you how to generate MeshLibraries, which are like palettes of scenery objects. It seems that Godot doesn't yet support palettes spanning scenes (the equivalent of Unity's prefabs), but only meshes with an associated collider. However, that, combined with a grid system, allows you to shape the environments comfortably and fairly accurately. I found it a bit awkward to move around while the grid was active because the right mouse button, which is used in the rest of the editor for free movement through the environment, is used to delete objects when you're in grid mode.
• Coming from Unity, I thought Godot's Node system was too granular. I didn't take long to get used to it. In the end, it turns out to be as comfortable, or even more so, than Unity's component system. The course explains it very well.
• Godot's Input system is like a simplified version of Unity's New Input System. I appreciated that it's much easier to set up than Unity's, although it's also true that the game only requires simple key presses. It remains to be seen how it performs in games that require more complex controls.
• In Godot, you won't miss Scriptable Objects. Here they're called Resources, and I've seen quite a few possibilities in them. The possibility, which the course teaches you, of dumping a resource to a file to use it as a shared repository for data among various scripts (decoupled from each other) seemed very powerful to me.
• Godot has a node called AnimationTree, which is essentially a combination of Unity's Animator and Animator Controller (all in one). On the one hand, it's more limited in transitions between animations (I missed being able to choose at what point in the animation to exit the previous state and at what point in the next animation to land in the next state), but on the other hand, it's used through a method called travel(), which allows you to transition from one state to another from disparate points in the state graph using A* to choose the route. It also has parameters, like Unity's Animator Controller, but lacks triggers. The course doesn't talk about AnimationTrees, but instead chooses to create state machines through code and call animations directly. Despite that, I insisted on using AnimationTrees with the guards, to learn to use that node. My conclusion so far is that the similarities between Godot's AnimationTrees and Unity's AnimatorControllers are quite superficial. Although they're used for the same purpose, their handling is very different. If you insist on using an AnimationTree through parameters, as you would in Unity, you'll probably run into problems. You'll also miss triggers a lot. My feeling is that in the end, you have to replace the use of triggers with calls to travel(), and that AnimationTrees are much more confined to animations than AnimatorControllers, which seem more general-purpose.
• Godot's navigation system is very easy to use. It's very similar to Unity's. If anything, I missed being able to define a step height for the agent in Godot's navigation system, which gave me problems with small steps that I had to replace with invisible ramps.
• I missed Unity's Gizmos and Handles. The course doesn't cover this, but I looked into it on my own. In a first sweep, I didn't find anything obvious. There's some mention in the documentation, but I admit I still don't have a clear idea. I have to delve into it more.
• The course taught me a combat system based on colliders (hit boxes and hurt boxes) that I hadn't thought of and that greatly simplifies other approaches I've used to implement sword combat.
• Godot's user interface system is a piece of cake. Very easy to use. If you're coming from Unity, it's more similar to uGUI than the new UI Toolkit, although it's true that unlike uGUI, things are edited in its own editor rather than overlapping with the 3D view of the scene (which I've always found horrible in Unity).
• Godot's signal and event system is very effective. It's true that in C#, it's not as straightforward as in GDScript, but once you get used to ending the definition of your events/signals with the suffix ...EventHandler(), everything goes well.
• The course touches on shaders, but only provides an example of a simple shader implemented through code (Godot's version of GLSL). I would have liked it better if it had explained it using Godot's Visual Shaders (which it has), but I was left wanting. I'll have to find another course that covers it.
• As for particle systems, they're very similar to Unity's.

Overall, not bad. The risk with these courses is that they're too basic. Fortunately, this one strikes a good balance between explaining the engine from scratch and reaching concepts that are interesting for people who already know other engines.

So, I recommend this course. I haven't regretted buying it and dedicating time to it. As for those of you who might be put off by the English, I'll mention that the Udemy course has English subtitles, so if you already read game development books in English, you won't have a hard time following the course. Plus, the instructor speaks very slowly, his pronunciation is very clear, and he uses very simple vocabulary. I, at least, haven't had any trouble following him.