Defold: the game engine that ships Lua and a headless build tool

What Defold solves, and who the repository is actually for

Defold is a game engine for desktop, console, mobile and web targets, written primarily in C++ and scripted in Lua. The problem it addresses is the one that appears once a game has to run in more than one place: instead of maintaining separate rendering, input and asset pipelines per platform, the project keeps one engine core and per-platform build paths. The README lists dedicated platform notes for iOS, Android and HTML5/Emscripten, which is the clearest signal of where the maintenance effort goes.

The repository is not a starter kit. It is the engine, the editor and the command line tools, plus the build system that produces them. That distinction matters when you are deciding whether to adopt it. If you want to make a game, you download the editor from the project's site; if you want to change how the engine behaves, or produce builds on a machine without the editor, this repository is the thing you clone. The two audiences overlap but they are not the same, and the README is written for the second one.

Defold is described as completely free to use. The repository carries a LICENSE.txt and a NOTICE file at the top level, and the licence identifier reported for the repository is NOASSERTION, which means GitHub could not match the licence text to a known SPDX identifier. That is a detail worth checking yourself rather than assuming a familiar licence, because the practical question for a studio is not whether the engine costs money but what obligations attach to the third-party components compiled into it.

How the Defold engine, editor and Bob fit together

The folder structure in the README is the architecture. engine/ holds the runtime. editor/ holds the editor application, which has its own README with setup, build and run instructions. com.dynamo.cr/ is Bob, the command line build tool. external/ and share/ext/ hold external libraries, split by how they are built: external/ for libraries rebuildable through the project's build system, share/ext/ for those built with custom build steps. packages/ holds prebuilt external packages, so a normal build does not have to compile every dependency from source.

The data flow for a build is: your project's assets and Lua scripts go in, Bob resolves them against the engine's resource formats, and out comes a platform-specific bundle. That is why Bob exists as a separate tool rather than as a flag on the editor. Continuous integration, build servers and headless machines cannot run an editor, but they can run Bob. The ci/ directory and README_CI.md describe how the project runs its own pipelines, which is a reasonable template for yours.

The scripting layer is Lua, and the repository topics list Clojure alongside C++ and Lua. That reflects the editor, which is not written in the same language as the runtime. Practically, this means contributions split into two very different jobs: engine work in C++ against CMakeLists.txt and the clang-format rules, and editor work in a separate stack with its own README. A patch that spans both is not a small patch.

Building Defold from source: setup, build, and a first Bob run

The README does not inline build steps. It points at README_SETUP.md for installing the tools needed to build the engine, README_BUILD.md for building the engine and command line tools, and editor/README.md for the editor. Start there; those documents are the source of the actual commands, and the repository's top-level CMakeLists.txt is the build entry point they describe.

Because the README gives no inline command sequence, there is nothing here to copy verbatim. Read README_SETUP.md first and install what it lists for your platform, then follow README_BUILD.md. If a dependency is missing, the failure will come from the configure step, not from the compile, so read the configure output before assuming the compiler is at fault.

The command line tool is Bob, in com.dynamo.cr/. It is the piece you would call from a build server to produce a bundle without opening the editor. The README does not document Bob's flags, so treat the tool's own documentation as the source for its arguments rather than guessing. The VERSION file at the repository root records the version the source tree corresponds to, and releasenotes/ holds the release note files; the recent release tags in the repository are 1.13.2-beta, 1.14.0-alpha and 1.13.2-alpha, which tells you the project runs parallel alpha and beta channels rather than a single stable line.

If you only want to make a game, the README's homepage link is where the editor comes from. Cloning and building the engine is the path for people who need to change the engine or automate builds.

Where Defold stops being the right tool

The clearest limitation is visible in the repository layout itself. The engine is C++, but the scripting surface is Lua. If your team's plan is to write gameplay systems in C++ and treat the scripting language as glue, you are working against the design. Engine changes are possible, and the build system supports them, but every one of them puts you on a fork that has to be rebased against a project that pushes frequently. The last push was on 2026-09-22, and the alpha and beta channels move on separate schedules, so tracking the source means tracking a moving target.

A second constraint is the editor. The editor is a required part of the workflow for most game development, and it is built and run separately from the engine, with its own README. That means a headless-only workflow is possible for building but not for authoring. If your pipeline assumes everything is a text file in a repository and nothing requires a GUI, Defold's authoring model will feel heavier than you expect.

Third, the licence situation needs your own review. The repository reports NOASSERTION, and the README directs you to COMPLYING_WITH_LICENSES.md for the full list of third party software licences and how to give attribution and include the licences in your game. TOOLS_LICENSES.md and the licenses/ directory exist for the same reason. For a commercial release, that document is the one to read before you ship, not after. Nothing here is legal advice; the point is that the attribution work is real and it is documented rather than implicit.

Defold against Godot and Love2D: different bets on scripting

The comparison people reach for is Godot, and the difference that matters is not features but where the scripting layer sits. Defold's runtime is C++ with Lua as the scripting language, and the editor is a separate application built from this repository. Godot's editor and runtime are the same binary and its primary scripting languages are GDScript and C#. If your team already writes C# or wants the editor and runtime to be one artifact, that is a structural difference, not a preference.

Against Love2D the split is sharper still. Love2D is a Lua framework: you write Lua, you get a window and a loop, and you bring your own everything else. Defold gives you a component model, an asset pipeline and per-platform build paths for iOS, Android and HTML5, documented in README_IOS.md, README_ANDROID.md and README_EMSCRIPTEN.md. The trade is that you accept Defold's structure in exchange for not writing the platform layer. Love2D is the better answer when the platform layer is not the hard part.

One thing the repository does not settle is console support. The topics list mentions multi-platform and the description names console targets, and there is a RELEASE_EGS.md and RELEASE_STEAM.md at the root, but the README's platform specific section lists only iOS, Android and HTML5/Emscripten. If console is your reason for choosing Defold, verify the current path with the project directly rather than inferring it from the repository description.

Maintenance cost and licence obligations before you fork

The project is not archived and the last push was on 2026-09-22. Release tags in the repository show 1.13.2-beta and 1.14.0-alpha dated 2026-09-10, and 1.13.2-alpha dated 2026-07-13, so there are two parallel channels and the alpha line is ahead of the beta line. If you build from source, the branch you track determines how much churn you absorb. The default branch is dev, which is the least stable place to sit.

Upgrade cost depends on how far you have moved from the tree. Consuming the editor and letting the project handle engine changes costs you nothing but the release cadence. Patching the engine means rebasing your changes on every pull, and the repository's own tooling (clang-format rules, CMake configuration, build_tools/) sets expectations about how patches are shaped, which CONTRIBUTING.md and CODE_OF_CONDUCT.md govern.

On licences: the README states that a full list of third party software licences, with information on how to give attribution and include the licences in your game, is in COMPLYING_WITH_LICENSES.md. The repository also carries NOTICE, TOOLS_LICENSES.md, licenses/ and an apply_license.py script. The reported identifier for the repository is NOASSERTION. Read those files and get your own advice; the practical takeaway is that shipping a Defold game involves an attribution step that the project documents deliberately.

Editorial conclusion

Adopt Defold if you want a Lua-scripted engine with a single editor that targets desktop, mobile, console and HTML5 from one project, and you are willing to work inside its component model. Do not adopt it if you need to write engine-level gameplay in C++ as a matter of course, or if you want a large third-party plugin ecosystem; the repository ships the engine, the editor and Bob, and the README points to separate setup and build guides rather than a package manager. Before committing, read README_SETUP.md and README_BUILD.md for your platform, confirm the third-party attribution requirements in COMPLYING_WITH_LICENSES.md, and check the VERSION file against the release notes directory to see which channel you are tracking.

Frequently asked questions

Official sources

1. defold/defold on GitHub
2. Issues
3. Project website
4. README
5. Releases