Anyone here who has worked with Godot?

#1

I was just curious how those who have worked with godot feel about their productivity with defold in contrast to their productivity with godot. Also, what are your preferences between the two and things you might of liked/disliked over one or the other if you’ve used both engines.

I only have limited experience myself on both engines but off the top of my head I love the packaging/deployment in defold. I had issues trying to compile to windows on godot my first time around where as defold did everything in a click without a hitch. I’m just wondering now which engine I’ll be more productive with making different types of 2D RPGs once I’ve gotten the hang of both.

0 Likes

How camera works?
#2

I guess I am the one here who has used way too many game engines (and has time to blab about it). :smiley:

I used Godot for a year or so before switching to Defold. I made 1 finished game, 2 half-finished games, and several prototypes with it. This was a while ago, around the time they started working on 3.0, so some of my experience may well be out of date, but I doubt the general things have changed.

I already wrote some posts related to it:

Regarding productivity, I think Godot and Defold are pretty equal, but they require slightly different methods/mindsets. Godot has a lot more features out-of-the-box than Defold, so you may find it faster in the beginning. Defold, instead of trying to handle everything anyone will ever need, is more set up to use external libraries for game-specific features. Grab a few libraries from the community asset portal and you will be off to a pretty quick start. You can also grab any Lua code that other people have written for general purpose or other Lua game engines and use it with Defold with little or no adaptation. Some people don’t like using other people’s code that they don’t understand, but let’s face it, you’re doing that either way.

So it’s a trade-off. With Godot you have lots of features ready-to-use, but if they have bugs or don’t work quite the way you want, you can’t fix or change them without editing the source code and compiling the engine for your platforms. With Defold, you have to find libraries or write things yourself, but if they’re not perfect you can change them just as easily as you can change your game code, and they will work on all platforms.


I’m a bit heated on this topic :smiley: and I haven’t used Godot in the last year and a half or so that I’ve been using Defold, so take my word with a grain of salt, but here is…

A long rant about Godot...

Godot has some nice core ideas (the scene/node system), plenty of features, and is fairly easy to learn, but it’s also bug-ridden, slow, has very incomplete documentation, and a cultish community.

Bugs:
Hopefully it’s gotten better as the community has grown, but when I was using it 90% of the engine development was done by Juan (reduz). He pumps out code amazingly fast, but he also doesn’t pause to test it or document it, and he rarely goes back to fix old code. There’s a strong focus on adding new features, very little on fixing things. His most common response to serious bug reports was “oh yeah, there’s no point fixing this, I’ll be rewriting it for 3.1”. So there are lots of broken or unfinished features lying around. There’s really no such thing as a stable release of Godot.

People think the open source thing is awesome, but to be honest I’m not sure if it is more positive than negative. They routinely use it as an excuse for terrible documentation and sometimes bugs. Several times I (or other people) asked for help on how a feature worked and the answer was: “I don’t know, go read the source code and let us know what you figure out”, or “if it’s broken, feel free to fix it!”. Also, there is no great review process or testing for code to get added to the engine. Random people write stuff, add a pull request, and chances are, it is added to the engine a day or two later. I was in a discussion once about how modifier keys were handled. Some guy decided he knew the solution, wrote some code, and the next day or so it got pulled into the engine. But all it did was move the problem from one place to another! As far as I know there’s nothing in place to stop this from happening constantly. It looks like they don’t use unit tests or any other kind of code testing (at least not with any consistency).

Slowness: (scripts)
GDScript is slow. I haven’t done any tests in ages, but I am confident if you test the same code between GDScript with Godot and Lua with Defold, Godot will be 10x slower or more. This won’t be noticeable when you start working on a new project, but as things get more complicated and you add more and more scripts, you will see the framerate slowly get lower and lower. I think someone did a test when they started adding support for other languages and the others were significantly faster, but I don’t know the specifics. This has been tested and reported multiple times over the years, but the Godot devs have simply denied that the tests were valid and haven’t shown any interest in trying to find bottlenecks and optimize.

Slowness: (rendering)
Godot also seems very slow about rendering. As far as I can tell, it still doesn’t do draw-call batching at all… You can kind of get away with this on desktop, but mobile devices can’t handle it. See here, here, and here. Some quotes from Juan regarding 1000 draw calls: “This number of draw calls is not much of a problem in OpenGL. Batching is not really necesary.” and “…might be better to eventually wait for phones to get better than fixing this.” For comparison, with Defold it’s pretty easy to stay below 50 draw calls for everything in your game. Also it has overdraw issues. I was working on a platformer and wanted some parallax backgrounds, but I simply couldn’t draw more than two layers over large parts of the screen before the framerate dropped below 60 (with everything else going on of course). I recently tried something similar with Defold and it had no problem drawing a dozen or so overlapping screen-sized images. It’s quite possible that Godot doesn’t do any depth sorting either, which could be the problem.

Documentation:
Godot has a pretty sizeable community to ask for help, but its documentation is very bad. To start with, a lot of it doesn’t exist. When I was using it, they announced that 60% of the class documentation was missing. 60%!!! And that’s just the stuff that doesn’t exist at all. The stuff that does exist is far from being good documentation. Most of it just reiterates what the name of the function already tells you. It doesn’t necessarily tell you what units all the arguments use, what each argument does, what the corner cases are, and almost never has examples of use. This is just the API documentation, never mind actual manuals that tell you how to use things in a pleasantly readable way.
The community has made some valiant efforts, but I don’t see how the situation will change much. New features are added without proper documentation. Unless that changes (either by not adding any new features or only adding them after they are fully documented), it is a losing battle. No one should have to delve into the C++ source code to figure out how a feature works.

and:

A few more opinions about Defold.

Defold isn’t perfect either, but it is light, fast, relatively bug-free, has great documentation, and very active and helpful staff and community support. Releases generally include more bug-fixes and small improvements to old features then added new features. I’ve seen occasional serious bugs reported on this forum get fixed within a couple days or a week. You don’t have to worry about new releases breaking your game without warning or having new features that don’t work correctly. I can’t begin to say how valuable this is. I’ll take a small core engine that works reliably over a big, untested engine with all the fancy features in the world.

I basically detailed the main things I don’t like about Defold in my post about Love in your other thread. (just invert the things I like about Love.)
(To sum up: poor desktop support, limited physics, and very limited audio.)

Defold’s platform support and build process is generally better than Godot’s, except that Godot has more desktop-specific engine features. I guess Godot has working web builds now, but from what I’ve seen they’re not as small and fast as Defold’s. (Defold is heavier than a dedicated web engine though.) Defold has quicker and easier builds for desktop (as you’ve seen), and makes it very easy to build and test things on mobile.

19 Likes

#3

Fantastic response. I’m sure this will help a lot of others who might come across this post in the future. So far I’ve liked both engines, but the biggest thing that was bugging me was “what’s all the hype about Godot?” I just couldn’t see what was so amazing about Godot like everyone else made it out to be, especially when I compared it to Defold which seemed to do quite a few things better (granted not everything).

The common thing I’ve finally noticed about those who recommend Godot over alternatives is either they haven’t really used other engines or even Godot that much, or they were experienced programmers/hobbyists that found Godot “fun” to use/“discover” and they enjoyed “contributing” to the engine. With your post it makes a little more sense now. It isn’t always an easy engine to use, but there’s a lot to discover (lots of features, and lack of documentation) and if you wanted to comtribute, it was very easy to do that. So maybe if you were interested in game engine development more than game development, godot could be a good choice.

While godot looks extremely interesting and possibly fun to mess around with, I think I will be staying away from till atleast a 4.x where I will likely just be poking at it for “fun”.

The larger community godot had was also pretty attractive to me, but at the end of the day doesnt really make up for the documentation, manuals and bugs. At the very least it seems to have interest from a lot of people and developing at a fast pace so it will be interesting to see where it is in the future.

Edit: On another note, I do remember the discussion on performance. This seems to be improved by roughly 2-4 times in Godot bunnymark benchmarks with the use of GDNative (Nim, D, or C++) in Godot 3.x. So while I wonder how it matches up to Defold now, using GDNative would mean giving up using a simple language like GDScript or Lua.

4 Likes

#4

Heh, yeah, there is a lot of hype around Godot. I think it has a strong initial draw because it is totally free, open source, and its editor runs on linux. So it has a lot of appeal for that linux/open-source/free-software crowd. Defold is one of a very few similar engines that meets two out of those three, but it suffers from a lot of “King is Evil!” sentiment. That with its online features (which are mostly gone now of course), mean the people that are attracted to Godot will probably have objections to Defold.

There’s also a significant “anti-Unity” crowd, and Godot ticks all the right checkboxes for people to see it as a viable alternative. The main Godot dev has been pretty vocal about comparing Godot to Unity and Unreal too, especially regarding the new rendering features for 3.0. If you tell people that something is better and have a cool picture next to your statement, a lot of people will probably believe you. It’s not generally overt or insulting, just a lot of: “In Godot, unlike in other engines…” or:

“This is one of the strong points of Godot implementation, which uses a novel blending algorithm between probes. Other popular game engines present hard edges between one probe and the next.”

“Thanks to Godot’s Forward/Clustered design, the material system is far more advanced than in other popular game engines, requiring no hacks to allow a much larger amount of parameters ready to use for the artists, at no cost.”

This month has been mostly implementing standard modern engine features, always with a twist to improve them the Godot way.

- Source article.

8 Likes

#5

I adore Defold and have come to appreciate it more and more over the course of developing Chemaria.

At the same time, I think this is more of a question of what is best for the situation. I use Godot for another game I am working on because Godot’s built-in features simply make my life that much easier (lighting, built-in UI system as the game is heavy with menus).

There are plenty of things about each engine that make me annoyed (Trying to support multiple resolutions with Defold. Cleaning up after myself when switching scenes in Godot because I instantiated scenes inside of the one scene and for some reason the switch scene functions simply don’t work as promised.), but in the end, whatever makes you more productive should be followed.

(Also, Godot’s community sucks compared to Defold’s. Defold’s community and development team are a unique miracle.)

Rewrites are quicker than making the initial product, so just get a thing working, and once the infrastructure is getting in the way, that is the time to re-evaluate and switch. I know, I have done this both for Chemaria (Unity to Defold) and Into the Crypt (Unreal to Godot).

9 Likes