As implied by my post last month, I’ve been testing out Godot as another development option. I’ve been finding pros that were both unexpected (at least to me) while the cons are being addressed. On the other hand, after they partially walked back their unwelcome new fees, I think I’m going to keep using Unity for my next hobby game.
First I want to address both Heaps and MonoGame, the two options I had been most interested in at first. With Heaps, I discovered that the deployment capabilities were somewhat overstated, which was very disappointing considering that was one of the main reasons I was so interested in Heaps. They weren’t lying exactly, but more like the mobile support was only theoretical. There’s nothing in how it works that would preclude mobile, and it’s open-source after all, but nobody is actually developing on mobile.
As for MonoGame, it just plain has fewer features than I would like. I mostly knew this ahead of time (I already knew it was just a framework, not an engine) but it was still dispiriting as the reality set in. Like, I wasn’t concerned about the lack of a visual editor, since I had already written a script for using Blender as a custom level editor. However I quickly found that I would also have to implement stuff like shadows myself. While I found several examples of shadow mapping in MonoGame I could leverage, my heart just wasn’t into it.
Meanwhile, as I was gradually being let down by those options, the opposite was happening to me with Godot. In retrospect it feels kinda dumb that I went through all that just to settle on the most obvious switching-from-Unity option everyone talks about, but I guess I had to go through this process to settle it for myself.
First off, I realized that Godot supports publishing web games. I’m not sure how I missed that, but initially I thought Godot only supported desktop and mobile platforms. One thing I love about making personal projects in Unity (and thus would be looking for in a new tool) is the ability to deploy prototypes to the web, even if the final release plan is for some other platform. Now, a con was that web game capability was unfinished when Godot 4 first came out, but 4.2 is released by now and web builds are fully working.
Secondly, Godot is just plain teeny tiny. I mean really small; Unity weighs in somewhere around ~10GB, while Godot is more like ~300MB (both sizes can vary depending on what optional components you include, but still within those ballparks). I’ve been getting tired of giant development tools like Unity or Unreal, and that was part of why I had been more interested in frameworks rather than engines. Somehow I assumed Godot would be heavyweight too because it also has a full-featured visual editor, but apparently that’s not the case at all.
A third (and more nuanced) pro comes from the GDExtension mechanism. As somewhat of a sideline to my other projects, I have been intending to do some learning projects with C++. I’m going to start with some prototypes built with raylib (as described in this tutorial video). However I’ve come to discover that you can also use C++ to build games in Godot, using a feature called GDExtension. While I am having no problem learning Godot’s native GDScript language, apparently the performance of that language is poor. Well, one can get around this for performance critical code by writing that stuff in C++ and then the languages seamlessly interoperate!
This all brings me back to Unity. For a while there, I was fully convinced I would be using a different tool to develop future personal projects/hobby games. However, two factors in particular have got me planning to keep using Unity for my next game. First off, their new licensing terms have settled into a less terrible place. I (along with everyone else) am still annoyed with what Unity did, but it seems like less of a deal breaker now.
Second, I’ve been realizing just how much of a head-start I get from Unity-specific assets (especially VFX). My games rely a lot on purchased assets, because man I don’t have time to be building everything from scratch. Some of those assets, while purchased in Unity’s asset store, could in fact be carried over to use in a different tool. 3d models in particular (stuff like character models or environment props) can work wherever. However just about all visual effect packs are Unity specific, relying on Unity’s shaders and particle system. Explosions, water, lightning, etc etc the list goes on. I really don’t want to toss out all the visual effects I have purchased and build my game’s effects from scratch.
