I recently entered the GBJam 11 game jam, and decided to give Godot a try for making my game, Space Walker. Here, I provide a summary of my thoughts on the experience of using Godot in comparison to using Urho3D/U3D.

Firstly, some caveats: given the game jam involves making games with GameBoy restrictions in resolution and such, the game is of course 2D. In contrast, basically all of my experience with Urho involves working on 3D games. Additionally, it was just a game jam, so I only spent a few days on it, so I am not even close to an expert on Godot. Given I barely read any of the tutorials, and instead just learned about a few of the parts that worked to make my game, I can probably barely be called a beginner. I make no claims to have done things the best or standard way when trying Godot. That out of the way, let's get into my experience.

Installation

Godot was very easy to install. A little confusing in terms of finding out what to install, as there are a few options, like a Flatpak and such (which led me down a red herring chase trying to find an AppImage version), but in the end it was very easy. Simply go to their website, and download the correct version, which is a single executable file that runs the editor, which in turn installs everything else it needs (samples, export templates, etc.). Because I was targeting a web build, I went with Godot 3, as Godot 4 has had some issues with the web build on Apple products. Those may or may not be fixed now, as I've seen some people say it works with the right setting on itch.io, but I didn't want to risk it.

In contrast, Urho is a game engine library, and not at its core an editor application. As such, you the user have to install your own IDE and CMake and compiler, and then set it up to use Urho for your projects. Definitely a bit more friction in getting started, but (aside from better documentation), there isn't really much that could be done to help with this given Urho's code-centered rather than editor-centered nature. I prefer the code-centered approach, by the way, and I think it is probably good for any aspiring game programmer to have the experience of setting up a development environment in any case.

Getting Started

Godot's editor pretty much right away allows you to download some samples to run. There collection of samples does seem pretty good. I used a few myself to get an idea of how to do things for my game:

• fixing render resolution while allowing the window to scale, based on a sample about resolutions and aspect ratios
• a basic 2D kinematic character controller
• a Main Menu example I didn't actually end up using, but might have if I had more time to polish my game.

These were very helpful in getting started with Godot. It was nice to be able to, with a few clicks, download a project and run it. And since it ends up setting it up in a new folder like your own projects, it feels like you are very involved in getting it to work, like you have ownership in it (even though you don't really do anything besides download and run).

That said, the samples seem like they might be a little too high level. Many of them seem like they are a large portion of a game: a complete menu, a complete level, etc. There didn't seem to be, for example, a sample that just explains how to use Godot's TileMaps. On the other hand, the documentation does do a good job of walking the user through these things, so perhaps it is not really that big of an issue.

In contrast, Urho's samples seem a bit lower level. Most of the samples explain only a small feature, often focusing on a single class (Sprites, Billboards, Decals, Lights, etc.) or technique (Water, Vegetation, Scene Replication) or Sub–System (Physics, Console, Scripting, Databases). There are really only a couple demos that feel like a significant portion of a game (50_Urho2DPlatformer, maybe 18_CharacterDemo, possibly a couple others). Since the samples are distributed and built with the rest of the engine, I think this arrangement is very suitable – they are very similar to a tutorial for the different parts of the engine that exists in parallel with the documentation.

On the other hand, I think Urho could do a bit better at getting new users set up with a new project. Godot's samples give basically the same experience as setting up a new project, except you start with existing resources in the project. In contrast, Urho's samples are like a small feature-demo for a part of the engine, and they are built automagically by CMake with the engine. This is likely not the experience you want for building your game, where the game is essentially a child of the Urho3D project. Instead, you likely want Urho to be a sister project, or a child project of your game. That said, Urho does have the rakefile to support making a new project, sort of like Godot, but that means you have to install ruby and rake to use that, while none of the rest of the engine requires it. Having an official high-quality U3D-Project-Template repository somewhere that could be cloned to start a new project would likely be very helpful in getting this to work, perhaps with a few additional branches for different game examples (e.g. 3D-third-person, 3D-top-down, 3D-first-person, 2D-platformer, 2D-grid-based, 2D-hex-based, etc.)

Use

Things I liked

Godot's editor-centered approach makes a number of things work very well. For example, getting textures to use the nearest pixel rather than linear filtering is just couple mouse clicks away. Simply select the resource in the (Godot) FileSystem browser, then in the Import tab toggle Filter off, and hit Reimport. Further, aligning collision shapes, at least in 2D, seemed to be a fairly pleasant experience, as the zoom is very nice, and then things snap to the pixel-perfect sizes that I needed for the GBJam. Additionally, moving nodes around in the scene was generally a pretty good experience, even when moving them to a different depth in the hierarchy. I did have trouble getting a node at the right depth at the end of the hierarchy, but I worked it out eventually. Overall, I would say that Godot has a pretty nice editor. Maybe a B+ or A-. And if I had more experience with it, I might rate it a bit higher (Blender is the only editor I have used that I would give a higher rating to, but I also have a lot more familiarity with it and its keybindings and such).

Another thing I like about Godot is how it handles scenes. As best I can tell, they are just a particular node hierarchy. They seem fairly lightweight, and are able to be instanced in other scenes, allowing for easy instancing of things more complicated than a single sprite or such (well, extremely easy instancing from the editory, and fairly easy instancing from code). For example, I use a scene with just a couple nodes (Area2D, CollisionShape2D, Sprite) and an attached script as the base for all of the thousands of point markers in my game*. To change all of the markers, I just change the single scene file and they will all be corrected. This setup stands in contrast to Urho, where there is no built-in solution to load a Scene/Node that itself instances other saved Node instances (i.e. ones in other files). Instead, you just have to load the whole hierarchy into the file, resulting in a lot of duplicated entities that can no longer be collectively edited. Of course, there are some simple workarounds to add that functionality as the user, but it would be an improvement if it were built into the engine.

* Technically, I am instancing all of them in code in Godot, so I could actually have achieved the same effect in Urho in the same way, but only because I was procedurally generating the level. For a manually created one, Godot's workflow would actually experience the benefit that Urho would not.

Another nice feature of Godot is how you can attach a script to a node, and then access the variables in the script as if they were variables on the node object. Not that important from within one script, but when you need multiple scripts to interact it can become very useful. Urho has something a little similar, as Nodes do have the UserVariables (and also Tags), but since there is no UrhoScript abstracting away the internal details, it is a bit more tedious to use (you have to put quotes everywhere to make strings rather than the compiler/interpreter handling it).

A small but helpful feature is the ability to reference nodes essentially as a directory path, including relative paths. Urho has nothing like this, you have to manually do all the GetParent() and such calls. And many of the paths can be used with Godot's $node/path notation, which saves a number of key-strokes (though again, this is just an abstraction allowed by having a GDScript that can't be done since there is no UrhoScript).

One other feature that was pretty nice for my game was setting up named keybindings in Godot, where you give the controls a name, assign the relevant keybindings, and then you can react to these inputs using the name. I don't know how flexible it is for a more complicated setup, and I think Urho's approach of leaving such abstractions to the user is acceptable, but Godot's approach was pretty nice to work with.

Now for some of the things I didn't like

Doing things from code sometimes seemed harder. Saving a loading scenes seemed to involve creating these mysterious objects that handle the saving and loading, and Urho's Node::Load and such in contrast seem much more straightforward. Additionally, the owner of a node ens up very important in the saving, at least, and wasn't clearly explained, so I had some issues where I did that incorrectly at first when I was trying to save the whole scene. But eventually I did work that out.

An issue with Godot 3 that has apparently been fixed in Godot 4 is that *.txt files cannot be used as a resource, so they are invisible in Godot's FileSystem browser, though you can still open the files in scripts and such. Unfortunately, that feature did not seem to work in the browser, though I may just have been using it incorrectly. In any case, I cached the level (hence the discussion of saving and loading above) so it ended up not mattering.

Copying and pasting in the Scene hierarchy leads to unexpected behavior. If you copy a RigidBody with a child CollisionShape, you do get a new body and shape you can move around. However, the new CollisionShape seems to share the resource with the original one, so if you change the size of the rectangle, for example, it ends up changing both the copy and the original. Unlike blender, which has a nice interface to make a new copy of a resource in such a setup, I could not figure out how to do it in Godot without just recreating the shape from scratch (not that hard, since it was just a rectangle, but still tedious).

Setting parameters across multiple objects could be tedious. In the more code-focused approach of Urho, I would just set all the collision layers and masks in code, most likely, so I would not worry about having to tab through multiple similar objects (the different shield directions) and change all the layers and masks to the same values.

Exporting

Godot's exporting seemed very nice. It downloads the export templates, and then you set a few parameters (save location, icons, etc.) and it does the export for you, and then you can run the result. This was a very friendly arrangement, though granted I only tried the web-export. I suspect that this is only possible as the entire Godot game are essentially pointing the shared Godot runtime at your resources (scenes, scripts) without any compiled code (at least for the non-C# Godot), so you can just download a pre-compiled Godot runner or something like that, but I haven't looked into it in any detail.

In any case, this is much nicer than setting up cross-compiling with Urho. Granted, with the dockerized build environment and GitHub Actions, you can get rather close to this, it still involves a bit more technical know-how to set up in Urho.

Summary

My experience with Godot was nice. I don't think I will switch to it from Urho, as I do prefer the code-centered development Urho together with the familiar editing environment of Blender (with exporter addon) rather than the self-contained editor-centered approach of Godot. That said, I think Godot might be a bit more friendly to new game developers without any coding background, as it's just one program to set up and you can do basically all of your development (scene editing and scripting) within it. The Python-like GDScript is also probably a more friendly start to learning programming rather than C++/AngelScript/Lua that Urho offers. Though perhaps if I finish my Python bindings for Urho at some point, the situation there could change and U3D could be the better choice for new programmers, as you could learn real Python (a useful language to learn) rather than a language that is just similar to Python.