Defold Review from a Long-time Engine user

[Pawel]

Thank you for taking the time to write this! And I mean it, such reviews are helping shape the Defold for the future! There is a lot in your post that is worth taking seriously. First, I want to acknowledge the positive part of what you wrote

@Stale

I have become very proficient using the engine, and from my beginning I can see all the little changes and improvements made, and combined with my growing skill, I feel like I can finally begin creating on par with other engines.

Reaching the point where Defold feels fast, stable, and expressive once you understand its architecture is a real experience many long-term users share.

Where I would push back is on a few factual points.

@Stale

There’s no way to close multiple tabs except one-by-one, this is especially gruelling now that they reopen when you leave the program

The editor does support closing multiple tabs. The current editor manual documents both Close Others and Close All for tabs, and yes, Defold 1.12.0 also added restoration of previously open tabs and split panes on reopen.
Additionally, all the files can be edited in external text editors and IDEs without issues and for most there are also useful plugins for Defold available.

The statement that Defold “cannot handle any action which requires multiple simultaneous inputs” is also too broad. Defold’s input system supports keyboard, mouse, touch, multi-touch, gamepads, multiple listeners, and stacked/consumable input dispatch. There are certainly cases where input architecture needs to be designed explicitly, but that is different from the engine being unable to handle simultaneous inputs. Multi-touch and concurrent gamepad inputs are explicitly supported.

Device input in Defold

Likewise, “sprite swapping (…) is basically straight machine code” overstates the situation imho. I don’t know your particular use-case, maybe it was something specific, but Defold’s sprite component exposes an image property that can be changed at runtime with go.set(), using either an atlas or a tile source. That does not mean the workflow is always ergonomic enough, especially for tile-source-heavy projects, but the capability itself is built in and documented:

Runtime manipulation - Showing 2D images

The shader related points also need a bit of correction. Defold is not stuck on an old model. The current shader manual describes two pipelines, including a modern pipeline where shaders are written in SPIR-V-compatible GLSL, and Defold 1.9.2 explicitly notes the toolchain now takes GLSL 140+ as input, generates SPIR-V via glslang, optimizes it, and cross-compiles as needed. That does not magically solve the usability or the “monotonicity” problem you describe, but the technical picture is a bit different than your post suggests, it’s not on hold, and still evolves. And Defold does support Vulkan.

Some of your gripes are completely fair. For example, built-in blend modes are limited, and subtract blend mode is not part of the standard documented options for sprites, although it’s possible to be done with shaders (e.g. subtract blend mode is supported in DefBlend). I didn’t find any issue on Github from users asking to add such a blend mode.

A fair criticism would be that the most mature skeletal workflows depend on external tools rather than being native to the editor. There’s powerful Panthera animation toolset that is free, Rive offers a free tier. You mentioned you’re a student, so there’s also an option for you to use Spine for free, which I think you’re reffering to.

Defold is indeed focused on being lightweight, so a lot of functionalities are cut out into extensions or assets, this that not directly conclude they’re not available, which is a common harsh criticism. We’re working on discoverability and ease of use of the assets. It’s now very easy to control what parts of engine you want in through app manifest and we’re working on a better solution for dependency management too (something like the Asset Store).

On the other hand Defold is stable, capable, and architecturally clean. In my opinion more stable than some of the other way more popular engines. It allows to create really any kind of game, but demands user knowledge and expertise for the most complex task. For buddying teams, students, jam developers, and people comparing iteration speed, it can become an issue, I understand, but for experienced users this can be empowering.

@Stale

I plan on releasing my LuaAPI functions at the end of my project cycles, once my exams are handed in, as a cornerstone of my work for this engine. And maybe a compilation of my new-projects for educational reasons.

That would be a very nice and powerful addition to all the other community contributions, we would really appreciate it! The amount of projects you created in Defold already is astonishing, it looks like you tame a lot of useful features nicely, so I believe those would be nice assets!

@Stale

I hope this engine continues to grow and develop, I see so much potential in it

I like one of the latest comparison I saw that Defold is like a turtle against a hare Slowly, but steadily it is improving and I hope it will become a much more widely considered candidate for games in the future! And this will actually speed up the development, if more people will be interested!

To make this happen, I propose to make issues on Github for some of the valid issues you posted - do you want to do so? E.g. I do agree with the raycasts not being draw in debug, all of use just draw debug lines for raycasts from code, so there could be an issue for this.

I may also solve your issues with tilemap hitboxes, don’t know precisely what you’ve stumbled upon, but I have built a fully working terraforming for my game based on tilemaps!