Defold Review from a Long-time Engine user

1

Hello I am StaleDev, I have been using Defold as my main engine of choice for around 5 years. I was originally recommended it by my school and seeing how I was already familiar with python, I thought it would be easier to learn than my contemporaries.

Since then I have created several unreleased projects, mainly for school projects as I am studying for a game-dev related degree.

Here is some of my portfolio using the engine for reference:

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.

The object-oriented system is really in depth, and I’ve been able to make things at immaculate speeds using require passings through Lua scripts. And I’ve never experienced any significant engine lag or bugs over the course of my time using the engine. I genuinely enjoy using this engine (most of the time).

If I could I would fully release a bunch of these projects and be something worth putting Defold on the map for. If it wasn’t for one re-occurring issue built into the very heart of the program..

It takes so long to implement even basic features, I’ve had entire days wasted on mechanics built into other engines, only to get worse results. It took me two days to do text-scrolling, it took me a week to figure out sprite swapping. I needed to build my own level editor in-engine in order for me to create entity-snapping to tiles and for tilesets to be stored as data files. I’ve been a part of game jams and by the time I’ve set up basic movement, they have a full prototype. It genuinely feels like machine code at some points.

The only way I’ve managed is the vast library of support functions I’ve accumulated from my previous projects. Otherwise its straight back to grinding several hours to get something slightly complex like a parallax or a shader working.

Its nearly impossible to recommend this engine to people, even beginners, because what you get in initial understanding you pay in long-term monotony. Especially with the lack of documentation (although it has gotten better in the last couple of years)

I have spent a week trying to implement a basic CRT shader directly from Shadertoy, and thanks to the lack GLSL debugging tools (GLSL in 2026 over Vulkan btw) and different syntax (especially with Idimension stuff), I don’t think its worth it to use shaders due to how monotonous they are. If a part of your engine is so difficult to use that I actually refuse to engage with it even with tutorials, I don’t consider it a well designed part of the engine.

My current two Defold projects for the next set of exams are most likely going to be the last ones I will produce, because switching to learning Godot so I can work alongside the rest of my dev team. It feels wrong to use an engine for 5 years and still not be able to produce a game longer than 5 mins, but unfortunately that is how long it takes to develop something with this engine. My current project, I’ve been working on since last august and I’m still only 20% of the way there to a potential end-goal.

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.

I hope this engine continues to grow and develop, I see so much potential in it, but I just don’t see what it offers over other engines rn.

Smaller Gripes:

-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

-There is no subtract blend mode, making darkness cutouts impossible

-Rigged Animation is heavily advertised, but the filetype used is locked behind a $70 paywall of a nonstandard software

-Raycast Linedrawing should be in Debug Hitboxes

-The engine cannot handle any action which requires multiple simultaneous inputs without some esoteric work-around

-Sprite Swapping (not atlas swapping, there’s reasons to not do that, mainly for Tilesourse) is basically straight machine code

-Spawned tiles lack hitboxes, this nearly killed my level editor

4 Likes
2

In my view, the biggest edge Defold has is its tiny bundle size. But it comes at a cost: it sacrifices many features to maintain that lightness, which makes development significantly slower. Unless you absolutely need a tiny bundle size, you’re better off using a different game engine.

The reason I chose Defold is for Poki game development. Since Poki demands an incredibly small bundle size, Defold is the perfect fit.

Every game engine has its own strengths, and you should always choose the right one for your specific project. For example, I would absolutely never use Defold to develop a AAA game.

3

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 :wink:

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.

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.

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:

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.

That would be a very nice and powerful addition to all the other community contributions, we would really appreciate it! :heart: 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! :wink:

I like one of the latest comparison I saw that Defold is like a turtle against a hare :sweat_smile: 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! :grinning_face:

8 Likes