AI-assisted tools, automation, and agent-driven workflows are becoming more and more relevant and we want Defold to stay open and ready for the ways developers are starting to build.
That’s why we’re happy to share Automation Bridge - a new debug-only native extension for inspecting and controlling a running Defold game from local automation clients.
Defold exposes many new possibilities for external tools to interact with both editor via editor HTTP server and a running instance of a game via engine HTTP service. Additionally, a lot can be done with editor scripts and external tooling. Automation Bridge is build up on these posibilities.
Automation Bridge lets local automation clients inspect and control a running Defold game:
query scenes and nodes,
send input,
take screenshots,
record desktop video,
add timeline markers,
and optionally communicate with your game through a Lua channel for events, state, commands, annotations, and acknowledgements.
It opens up interesting possibilities for automated testing, debugging, visual inspection, and AI-assisted Defold workflows, automated visual inspection, or other repeatable interactions with a running Defold game.
It is designed for debug builds, so it does not expose the bridge in release builds.
We created this extension/Python library because it provides high-level access to low-level engine and editor functionality. It helps agents interact with the editor and the engine much more efficiently. This library is unlikely to become obsolete because it simply provides a convenient interface for fundamental operations.
Skills are a bit different. I’ve seen this many times myself, and I know many people (for example, @Oleg_Chumakov and even people working in AI labs) who recommend periodically removing all the custom skills and infrastructure you’ve built and seeing how the latest model performs without them. It’s surprisingly common that a new model no longer needs things that were previously essential, and in some cases those old skills even reduce performance.
Because of that, I try to avoid building complicated technical skills that require long-term maintenance. Instead, I focus on building tooling that remains valuable regardless of how much the models improve.
Apart from that, I mostly pay attention to prompting. At the moment, the prompt structure that works best for me is:
What do you want the engine to do? (e.g. create me a particle when bullet hit a wall)
How should the result be validated? (This is where automation-bridge becomes useful. You can specify exactly how validation should happen. For example: “Use automation-bridge to create a callback that immediately spawns the particle you can use. Generate a four-frame screenshot collage covering 1/5 intervals of the particle lifetime, verify that the scale is correct and matches the game’s style, and finally record a short video of the finished effect when you are done as the report for me.”)
As you can see, steps 2 and 3 are generic for almost every particle-related task, so they are good candidates for a reusable skill. However, I think it’s better to create that skill after you’ve successfully completed the task. At that point you can ask a skill creator (this is a skill for skills creation) something like:
“Create a reusable particle creation skill that captures everything you’ve learned about particle creation, includes all relevant references, and describes the validation process, so I can reuse it across projects by only specifying what particle I need and where it should be used.”
Skills created this way tend to be much more reusable and stay relevant for much longer.
As someone who has been using Automation Bridge for weeks, I want to say that Alexey has created something truly impressive. It may look like another collection of skills, but it is fundamentally different.
Since around autumn 2025, we have built many tools around our project SuperWEIRD to help the agent interact with it independently: clicking through the project, running builds, monitoring their progress, restoring state, finding bugs, testing and building interfaces, and more. Automation Bridge brings all of this together in a much more universal form.
After analyzing the latest Bridge version, 2.0.2, our LLM agent concluded that we could remove most of our own recent developments and rely entirely on Bridge.
So this is not just a useful tool for everyday development with agents. It is the compiled experience of more than a year of developing SuperWEIRD. Everything we built for ourselves is here in a much more universal form, suitable for any project, without the many intermediate approaches we discarded because they worked only in simple cases, failed in complex ones, or worked on Mac but not Windows.
Alexey has done an outstanding job, what a legend!
I’ve been testing this for a few days and it’s been mind-blowing. I was recently able to give Claude a mockup of a screen made by our UI artist, a directory with the already-exported individual assets from that mockup, and - using the Automation Bridge - it was able to iterate and build an almost pixel-perfect .gui based on the source reference. Great job with this extension!
I extended the hobby project a bit and now it has runtime preview that is streamed directly from the game. It’s pretty cool what you can do with Defold and the Automation Bridge extension.
This release introduces Automation Bridge HTTP API v2 and Python wrapper 3.0, with safer element input and easier future upgrades.
What’s new
Passing an Element to click(), or two Element objects to drag(), now verifies their runtime identities. If an element ID has been reused, the wrapper raises engine.StaleElementError instead of sending input to the wrong element.
key() now accepts normalized names such as M, SPACE, KEY_ENTER, and {KEY_ESCAPE}. Unsupported names fail before input is queued.
type_text() now always treats braces and other characters as literal UTF-8 text.
project.update_automation_bridge() can update the project to the latest stable release or an explicitly pinned version. It updates game.project, fetches dependencies through Defold, replaces the complete project-root Python wrapper, and rolls back on failure.
A Python migration guide is now included with the wrapper.
Migration from 2.0.x
Extension 2.1.0 and Python wrapper 3.0 must be updated together. Wrapper 3.0 communicates only with HTTP API v2.
2.0.x
2.1.0
/automation-bridge/v1
/automation-bridge/v2
/nodes and /node
/elements and /element
Response fields nodes and node
elements and element
Capabilities nodes and node
elements and element
Element IDs beginning with n:
Element IDs beginning with e:
automation_bridge.nodes
automation_bridge.elements; preferably use engine.Element and engine.Bounds
The documented high-level Python helpers—including element(), elements(), maybe_element(), element_by_id(), click(), drag(), and type_text()—retain their names.
For the initial upgrade, replace the complete Python wrapper directory instead of merging files, restart Python, and follow automation-bridge-python/MIGRATION.md. Future upgrades can use project.update_automation_bridge().
