HubbleCommand.github.io

Personal blog, project documentation, and ramblings

Moving on from Defold

Posted 27 Mar 2025

About a quarter ago, I started playing around with Defold.

In that time, I’ve come to really like the engine. It’s small, nible, and gets the job done. It doesn’t present itself as having any fancy features, but what it does have is incredibly stable. It’s honestly the best game engine out there.

What I don’t like

UI system *

This seems to be a running theme with game engines. Most just don’t come with a good UI system. Although at least the team documents it well *.

Defold does have a key feature than many engines don’t support well, which is display profiles that allow for adaptive UI layouts. There is a whole manual on the topic.

However, it doesn’t change the general clunkiness. The biggest offender is the differentiation between a normal script / scene, and a gui script / scene.

No support for vector graphics

You can get hacky vector graphic support with meshes, but I don’t recommend it. This is the biggest drawback to the dynamic UI system, as supporting different resolutions becomes tedious with loading different resources yourself.

What’s even more surprising is that one of the biggest supporters of Defold, Rive, is a business centered solely on vector graphics!

Editor clunkiness

Defold’s editor isn’t made with defold but with JavaFX, and that’s Defold’s biggest fault. I believe that this is the source of the UI system issues: they aren’t dog-food’d.

There are many minor issues and the entire thing is unergonomic, such as the keybind system, and material system, and shaders, and scripting…

Lua

Dynamic / weak / no typing, need I say more?

My personal preferences aside, it’s not the worst choice. I mean, Godot did go and make their own scripting language… I feel like if the editor wasn’t so bad, I wouldn’t mind it as much. But autocomplete rarely works, and for a language / engine that depends so much on magic strings it becomes a massive pain. While fine for basic scripting, it’s not really adapted to making game systems.

Clunkiness of the render system

If you know, you know.

It is very powerful. There are many effects and visual systems that you can make easily in defold that would take much longer in other engines. However, just basic 2d scene rendering can get obtuse, and just doesn’t work well out of the box. The material / shader system as well, while powerful, is just so damned clunky. There’s too much you have to set up in the editor, to very little end, before you can use a material.

It’s also all of the little things that are missing, like converting screen space to world space coordinates *.

Your own physics

You need to resolve collisions yourself. I’ll be honest, every game engine requires you to do a massive amount of your own physics.

Defold, like for many of it’s systems, recognizes that if you need to heavily customize it anyways, why not just give the bare minimum? It makes it easier to develop for the Defold team, and easier to use for game devs.

Is that all? Then why am I moving away? Where am I going to?

If I was going to stick with a game engine, I’d stick with Defold.

However, over the last umpteen years, I’ve moved from engine to engine, not once ever finishing a game. I have spent more time working around limitations or working on the engine itself. I kept moving from engine to engine because I always though that making one from scratch, especially cross-platform, would take too much time.

In the next post, I will go over a small framework I made to make advanced Android Live Wallpapers, notably for idle games. Few options existed besides just making it from scratch, so that’s what I did. After making this framework, I realized that any game that I wanted to make, I could make with effectively no engine. As long as rendering was mostly taken care of, I could easily work out my own mini-engine. I have much more experience now than when I started game dev, so why not try to continue my framework?