Why do you personally prefer Defold over Unity for 2D games?

Questions
1

Hello everyone,

I’m primarily an Android developer, not a full-time game developer. For most of my career (around 8 years), I’ve worked with statically typed languages. Over the past year, I’ve been exploring game development more seriously.

During this time:

  • I made several mini games in Unity

  • I also made a polished, high-quality casual 2D game using Defold

While working with Defold, I really appreciated things like the 2D-focused editor workflow, simplicity, fast iteration, and clean project structure. At the same time, I struggled with other aspects. I often felt that Unity has more built-in features and tools, and that building certain systems can be faster there.

One major challenge for me is that I strongly prefer statically typed languages and enjoy working with C#. I find Lua and dynamic typing difficult, and I’m not sure whether this is just a matter of habit and experience, or a genuine mismatch with how I think and work.

Despite these struggles, I can’t completely get Defold out of my mind. Even though my experience wasn’t perfect, something about Defold’s philosophy and workflow keeps pulling me back, especially for 2D games.

So I’d love to hear from people with more experience:

  • Why do you personally prefer Defold over Unity?

  • What advantages of Defold did you only start to appreciate after longer use?

  • If you came from Unity, Android, or a statically typed language background, how did you adapt to Lua and Defold’s way of working?

  • Do you think Defold works best for a certain project size, genre, or mindset?

I’m trying to figure out whether my doubts come from lack of experience with Defold and dynamic languages, or whether Unity is simply a better fit for my background.

Thanks for sharing your experiences and insights.

6 Likes
2

I have experience working with multiple game engines, including Defold and Unity.

With Defold, I really like the API architecture, which is designed very well around ECS, and I also feel more comfortable using ECS in Defold compared to more module/oop approaches.

The editor is lightweight and doesn’t require long waiting times like Unity’s editor. However, that is also a drawback: in order to keep the editor lightweight, the Defold team usually doesn’t integrate too many tools directly into it.

That said, I’m already very accustomed to using third-party tools such as Tiled or Panthera.

It can be said that Defold is one of the few free engines whose mobile platform extensions are officially supported by the core development team (just take a look at Godot—it performs very poorly in this area). Additionally, building extensions for Defold is relatively easy and fast.

And yes, I’m currently very interested in web-based games. In that regard, Defold is arguably one of the best engines available for this platform.

You can also use C/C++ or C# to build modules as replacements for Lua. I personally use a lot of C++ for most of the heavy computations in my Defold projects.

Additionally, you may want to take a look at Defold Teal Support:

7 Likes
3

Hi! I wouldn’t consider myself very experienced with Defold yet, but I’d like to share my thoughts because I’ve gone through almost exactly what you described, especially the strong preference for statically typed languages.

After encouraging myself to seriously develop games using Defold, I can honestly say that Defold is the only game engine based on a dynamically typed language where I don’t run into constant friction or headaches. I’ve tried many engines in this category and really wanted to love all of them, but once a project grows in scope or needs refactoring, I often start to struggle. Surprisingly, I’ve never felt that way with Defold.

The way Defold nudges you to structure your code, separating modules, utilities, game logic, and events, makes scaling and refactoring much easier for me. What surprised me even more is that I actually write more reusable and cleaner code in Defold (Lua) than I ever did in statically typed languages like C#. That didn’t make sense to me at first, given my strong preference for static typing.

But once I stopped fighting it and started working “the Defold way,” things clicked. I found myself naturally writing better abstractions: helper utilities, pure functions, class like modules when needed, clear message and event passing with meaningful data, and reasonable global state modules, all clean and tidy. It just works, even though it goes against my original statically typed mindset.

That said, I still consider myself relatively new to Defold and I’m constantly learning better ways to do things. My main takeaway is that pushing Defold away purely because of my preference for statically typed languages no longer makes sense after actually embracing its workflow and philosophy.

These days, Defold is my go to engine for 2D games, especially for web games.

I also wrote a bit more about this on my blog, if you’re interested:

Cheers!

6 Likes
4

i prefer defold;

defold has effectively the same quality as unity, if not better, but with no mandatory payment

defold has lots of documentation and project examples

defold’s render system is straightforward, but lacks a flow-based shader programmer

defold is on steam! wow!

the biggest problem i had with unity is that the asset files wouldn’t update when i changed them

i love that defold’s file system reflects exactly what’s on my pc, so i can edit the files both in my file explorer and in the editor

defold and roblox studio have many similarities, and being an ex roblox dev, the learning curve was easy for me

i do wish, though, that defold had a live hierarchy window during runtime, so i could see exactly what all the game objects are doing, instead of printing out everything

3 Likes
5

Regarding the language. As someone who believes that statically/strictly typed language are objectively better, I struggled a bit at first with Lua. It felt like going back in time to when I was writing plain JavaScript, and it made me stop using Defold for quite a while. The only reason why I gave it another try was because they started implementing support for Teal, which is typed. However that support is currently pretty lackluster imo. Hopefully they give it some more love next year. I’ll sing praises about Defold if they do.

Anyway, some people suggested that I could use type annotations in VS Code, and it actually works decently well. It’s far from perfect, and it adds a lot of extra lines in the code, but it gets me most of the way to having everything typed. So give that a try if you haven’t.

I think Defold shines when it comes to the platforms it supports, and the small file sizes it produces. I just haven’t found anything similar in other engines. Not to mention the official libraries for integration with steam, poki, rive, ads, etc. Chef’s kiss.

I tried creating small web builds with Unity, but I really struggled with getting it under 10MB, and the compile times were really long.

Anyway, I think that other parts of Defold are less nice. The engine feels a bit clunky and old fashioned to work with. The built-in code editor is imo a decade behind any other popular editor/IDE. And Lua is stuck on an old version that lacks many features that are standard in modern languages. A lot of features have to be added through community libraries, which is always risky. Speaking or community, it’s pretty small. It’s very easy to see all of the hype around other engines and get pulled into those ecosystems instead. I’ve had to make an actual effort to not get swayed to move to other engines. But hey, it is what it is.

All in all I think Defold has a good foundation, and hopefully it’ll keep getting better, attracting more developers. I think that if it gets some big hit games like Löve2D had with Balatro, it could quickly pick up some steam.

3 Likes
6

I also strongly prefer statically typed languages, and I also keep being drawn back to Defold for its other attributes despite how much I dislike working without compile-time type safety. I’m a full-time software engineer, and in the US at least, the vast majority of us use statically typed languages daily. Like others have said:

  • Lua in Defold feels like going back to untyped JavaScript
  • I tried Teal, but Teal just isn’t there today in any realistic sense (I spent many hours converting thousands of lines across two projects before deciding Teal is untenable)
  • I eventually hit a middle-ground via thoroughly annotating plain Lua with LuaCATS comments.

For others in the same boat, some things that have helped:

First, I found Teal to be even more verbose than LuaCATS annotations. It’s slightly more expressive, but not worth the cost.

Second, a more aggressive .luarc.json can help highlight type errors before runtime. This is the one I use:

{
    "workspace.library": [
        "types/defold"
    ],
    "workspace.ignoreDir": [
        ".git",
        ".vscode",
        "build",
        ".internal"
    ],
    "workspace.checkThirdParty": false,
    "runtime.version": "LuaJIT",
    "diagnostics.globals": [
        "hash",
        "vmath",
        "pprint"
    ],
    "$schema": "https://raw.githubusercontent.com/LuaLS/vscode-lua/master/setting/schema.json",
    "diagnostics.severity": {
        "assign-type-mismatch": "Error",
        "param-type-mismatch": "Error",
        "return-type-mismatch": "Error",
        "cast-type-mismatch": "Error",
        "undefined-field": "Error",
        "undefined-global": "Error",
        "missing-return": "Error"
    },
    "type.weakUnionCheck": true,
    "type.castNumberToInteger": false,
    "type.castIntegerToNumber": true,
    "diagnostics.disable": [
        "lowercase-global"
    ]
}

The types/defold reference is populated via GitHub - astrochili/defold-annotations: Defold annotations generator for Lua Language Server . Third-party extensions (for example, fastnoise) can be used unsafely via adding them to "diagnostics.globals" or safely by getting an LLM to write some type annotations for them that you stick in types/whatever.lua.

Finally, I have found LLMs to be useful in annotating my own code with LuaCATS - to me, one of the main drawbacks of both LuaCATS and Teal is having to define types separately from where you’re using them, essentially writing everything twice. It gets in the way of quick development. So writing scripts, then having an LLM annotate the comments without changing any of the code, has been helpful. Gemini 3 Pro seems to understand Lua the best as of today.

This is a positive for me re: Defold. I prefer a small, tight, fast, well-tested, stable core that can be extended as necessary. Godot and Unity are both littered with buggy out-of-the-box systems. Defold has excellent support for native extensions already, and I think the work the team is doing to increase the power of editor scripts is strategic & smart. That said, it’s objectively true that Defold has fewer solid 3rd party anythings so for many classes of games that need them, Defold is a non-option.

As to the specific reasons I love Defold despite all the above with Lua:

  • It sits somewhere between “game engine” and “game library” in a nice spot that gives you some minimal visual tools, while still promoting a code-and-data-first workflow.
  • Reliable and fast, both at runtime and build time. I can edit things in vscode and know that the filesystem changes are reflected in Defold, without having to shut it down and restart it each time and without expecting it to crash when something else touches a file.
  • The patterns that it encourages are simple and elegant, without forcing you into any one particular paradigm. It’s easy to build static (global) modules or bags of state, easy to pass messages, easy to create instances, easy to pool objects, etc. You can define behaviors Unity-style via several scripts on a game object, or via code composition with Lua modules.
  • While not statically-typed, Lua is undeniably elegant.
  • Its reliable monthly release cadence is amazing; releases consistently fix bugs that are impacting me or ship major features that unlock things for me.
  • The core team is friendly, welcoming, communicative, receptive, smart.
  • Though small, the community is all the above as well.

The IDE has regressed this year with lots of small bugs from new features (selection state becomes de-synced between the outline view and the properties form, keyboard navigation is broken for certain types of inputs, focus is handled inconsistently, the overloading of what double clicks and hotkeys do in the outline view has made common editing workflows harder). And the broader architecture comes with historical baggage (GOs vs Collections, GO vs GUI, lack of GO string properties). But these are rough edges I’m willing to deal with.

11 Likes
7

Does each of these have reported issues on GitHub? Regressions in the editor is definitely not the direction we want to go in.

1 Like
8

Many of these are small, context-sensitive papercuts (like unusual behavior with double clicks, keyboard shortcuts, etc). I’ll keep an eye out for the next time one happens to see if I can reproduce it well enough to report an issue.

I just submitted issues for the ones I know how to repro:

5 Likes
9

Thanks! We usually review reported issues every Monday, and I think we’ll do one more review before Christmas, otherwise it might be delayed a bit.

3 Likes