"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.

"Artificial Intelligence in Games" by Paul Roberts

The best book I've read so far on how to develop game AI is AI for Games by Ian Millington. The problem is that there aren't many books on the market that cover the game AI branch in a practical way. The ones that exist are either too theoretical or they only cover a couple of topics, such as pathfinding and state machines. That's why I read Game AI Programming with Unity by Paul Roberts with eagerness.

Fortunately, it has a practical and introductory approach. I would recommend that anyone who wants to get started in the world of game AI read this book before Millington's, since Roberts's book doesn't go as deep, but it's written in a more plain language. It's ideal for a first contact with the different branches of AI used in games, to then go deeper with Millington.

The topics it covers are varied and interesting: steering behaviors, terrain analysis with influence maps, pathfinding, decision structures, fuzzy logic, minimax, genetic algorithms, and neural networks. Unlike Millington's, you won't end up with enough knowledge to implement your own version with Roberts's book, but you will have a good understanding of the main concepts, which will make things much easier when you start reading more detailed texts.

The Kindle digital version has some defects that have made it difficult to progress at times, mainly that the formulas are not well formatted and have lost most of the operators in the digital conversion. So it's very difficult to get an idea of the formula just from what's in it. Fortunately, the formulas are not abundant or complex, so in the end you end up figuring out what they mean, even though you have to think about it for a while. I really don't understand why he didn't do the same with the diagrams, which are hand-drawn and digitized, but at least they are understandable. If he had done the same with the formulas, there would have been no problem.

But more than the theory, whose depth I have already said is quite scarce, where the book really shines is with the practical part. The author has developed a series of mini-games in Unity to test the concepts of the book. So, after the theoretical part of each chapter, there is another part in which he guides you, step by step, in a tutorial format, to implement those concepts to create an AI that will face you in the mini-game. It must be recognized that the author has made an effort to create complex, well-presented mini-games that are very well suited as a platform for testing theoretical concepts. I think this is the main value of the book. There are others that explain the different concepts better and more in depth, but they stay in theory. Having the opportunity to tinker with and test these concepts directly in a game is something that only this book has offered me so far.

So, it's a book that I recommend. Recognizing its limitations and defects, I think it's a book that adds value to the limited ecosystem of books on game AI.