2024-10-25
I started working as a full-time game developer since the start of this year. My job has branched out to Artificial Intelligence and Networking since then, but I still spend a significant amount of time developing games as part of my profession. I have been making games on my own for around 8 years now. I started with pure JS, then Construct, and then finally settled with Unity. It was the go to for anyone pursuing a hobby in game development, and also somewhat of a standard in the industry back then. So, a fair share of my game development experience has been with Unity, and naturally, I was most comfortable there.
I heard of Godot in early 2023, from one of my friends. The concept of "everything is a node" didn't click for me then, and I wasn't fully sold on the philosophy as well. However, this year, when I joined Softograph, I was told that all game development here was mostly with Godot. The reasons for that were mostly the scope of our work, the economic part also played a role too. By then, the only thing I knew of Godot, was that it was built on the idea of Finite State Machines, and GDScript was almost like Python.
Now, I have had the opportunity of using Godot as my primary game development tool for 10 months. I developed and shipped multiple projects, both personal and professional. I am fairly confident in my Godot skills that I feel that I can be insightful talking about the software's user experience, capability, and trade-offs. I would like to list a portion of my experience and observations of Godot.
This is probably the primary selling point of the tool for the majority of game developers. The latest Godot 4.3.x stable binary sits at ~130mb. There is nothing to install. You just open that file and you're good to go. For any game jam, or prototyping, Godot will be my first choice for whipping out a working playable version before anything else. It also helps that Godot uses a lot less computational resources than other popular game engines.
Prior to this year, I was very much used to C#'s compilation times whenever I did some major changes in my code. Godot's scene saving takes way less time than Unity's compilation. I understand that this is also due to the nature of the language I am writing in and a lot of that cannot be helped. But when I am in a rapid development phase, this boosts my productivity and the ability for me to experiment stuff by trial and error a lot.
A lot of my professional projects are games powered by WebGL. Godot's HTML5 ecosystem and the ability to have runnable exports shaves off a lot of headaches. Plus, it has a nice way of communicating with the browser's Javascript interface. I have to work a lot with our game portal's backend, and the frontend where the game's iframe is hosted. Doing the same with Unity requires me to set up plugins for WebGL and re-import some DLLs during build time. I'd rather opt-in for the former.
This should have been higher on this list. Coming from Unity, I was very much used to component-based development. An object in the scene could hold multiple scripts and it felt natural. The way Godot restricts one single script per node, was a bit foreign to grasp at first. That way of thinking has certainly given my a new perspective to think from. Also, in this way, a lot of times, it is easier to isolate parts of the game/system and re-use them wherever necessary.
Signals are a core part of Godot's development process. This is similar to how publisher/subscriber methods work in other systems. GDScript also supports await-ing for a signal to emit, or a method to finish. Personally, writing networked systems and working with asynchronous code feels really trivial in GDScript. And compared to other engines, it is very easy to set up the system so that even if you take out one or multiple sub-scenes out of a scene, nothing really breaks or stops working.
I don't have the beefiest machine at work. And for only web games, it isn't really justified for me to scoop up another device. Unity takes up around 7 minutes to perform a clean build of a moderately sized WebGL project. That is a lot of downtime for me and a big bottleneck for when I have to test and exported version of the game. Godot's export templates, while sometimes being a bit bigger in size, take outlandishly small amount of time. This streamlines a lot of the actual development time.
It's not all green this side either. Godot has also some pain points which can even be a complete deal breaker for some.
I know, I know, you can enable the typing requirements in the editor settings. But you still miss out on a lot if you use GDScript. Godot does give you the ability to write in C#, but then you are going to have buggy exports on HTML5. I have been doing another project in Unity for the last week, and it has re-occurred it to me how much I like the C#/.NET stack. My code looks way more structured, and I am less likely to run into Runtime Errors. Now, it is unfair to compare a rather new language like GDScript with C# simply because of how much time the latter has had to mature into the current state. But I have always been a fan of languages with strict typing and I am constantly reminded of it whenever I move to a language that doesn't quite contain that in spirit.
Godot has marketplace, with addons and plugins. It is the closest thing to Unity's Asset Store or Unreal's Marketplace. But the maturity is nowhere near them. I attribute one of the reason's to be the FOSS nature of Godot. I am a big advocate of FOSS and contribute quite a bit on my own. But for a marketplace to be successful, quality-ensuring, and competitive, you need incentive. In Godot's marketplace, you don't get that like you get from Unity or Unreal. So people are less likely to publish life-changing assets. It's still mostly passionate people and volunteers that are pushing the community forward. The code editing experience is also lightyears apart. I use VSCode for any sort of text editing. The extensions and tooling available for Godot in VSCode comes nowhere near the C#/Unity support that is available. A big shout out to the godot-tools extension that is holding up a big portion of the community. But I still find it quite painful to debug with that from VSC. VSCode's extensions for Unity, or even a completely different IDE like Rider has way better support for the game engine, and from multiple angles like Code Refactoring, Engine Integration, Scene Exploration and Analysis, Seamless Debugging to name a few.
I believe a big part of Godot's disadvantage comes from how new it is to most game developers and a not fully developed community behind it. I'm sure as it starts to have more eyes on us, the QoL improvements will come with that. Until then, I am going to make it work because I feel like I can't go back from the ease of rapid development that Godot has shown me.