Defold

Defold Summer Newsletter 2026

Tue, 25 Aug 2026 00:00:00 +0000

News

Hello Defolder!

Welcome to our summer newsletter edition, covering both July and August!

Defold 1.13.1 is out with new Light components and many more improvements, the Defold Game Jam was announced and will be there soon, and we have a great collection of games, extensions, tools, articles, and videos from the community to show to you. If you have something you wish to share, please send us an email at info@defold.se.

Read the formatted newsletter here or read its content below:

Defold Game Jam 2026

It is time for another Defold Game Jam! Join us in September, make a game, meet fellow developers, enjoy online talks, and compete for prizes. Among announced sponsors we have us, the Defold Foundation, Wavedash and CraftPix - check the rewards and stay tuned, as there’s still more to come!

Meet Defold at gamescom 2026

We are at gamescom and would love to meet developers, publishers, partners, and everyone interested in games and Defold.

Schedule a meeting with us

Photon Fusion multiplayer and 3D platformer sample

We are happy to publish a Photon Fusion multiplayer extension for Defold together with a networked 3D platformer example, which is also available as a standalone sample project.

Explore the extension and sample

New games made with Defold:

Assets, extensions and tools:

Worth reading:

From tabletop mystery to mobile city — MicroMacro Creator Spotlight

Felix Weiler explains how Soft Boiled Games adapted the tabletop hit into a huge zoomable mobile city and why Defold was the right engine for the job.

by Defold Foundation

Making The Mutiny of Willy Killem in 96 hours

A candid GMTK Game Jam postmortem covering the team’s pirate-game idea, 3D production tricks, Defold tools, and hard-won lessons from a 96-hour sprint.

by gameoffate2018

New Defold manuals on automation workflows

Five new manuals explain editor and engine automation, external tooling, testing, validation, and AI-assisted development workflows.

by Defold Foundation

Worth watching:

Defold 1.13.1 has been released

Highlights:

💡 New Light components
💪 Instanced models with morph targets
🎮 SDL gamepad database
⚡ Up to 19% faster warm builds
🖥️ Borderless desktop fullscreen
🛠️ Expanded Editor Scripts and HTTP API
📦 Resource archives larger than 4 GiB
🔊 HTML5 audio fixes and more!

CHECK THE RELEASE ANNOUNCEMENT

Help Defold grow!

Support the Defold Foundation and help us cover operational costs. Received donations will be used to pay for the native extension build servers. The Defold native extension build servers are provided completely free of charge to all.

SUPPORT DEFOLD 🧡

Defold release 1.13.1

Mon, 17 Aug 2026 00:00:00 +0000

Defold 1.13.1 is now available. This release introduces a new lighting workflow for both 2D and 3D projects, significantly expands what can be built with editor scripts and the editor HTTP API, improves gamepad compatibility, shortens iteration times in large projects, improves editor tools, with infrastructure changes that make Defold easier to automate, integrate Defold with external development tools, or scale to larger projects. New engine and platform APIs make it easier to build native extensions, or stream collections. The release also continues the work started in Defold 1.13.0. Models using morph targets can now be instanced.

Before updating an existing project, we recommend reviewing the full release notes, particularly the Xcode and custom Info.plist migration note.

Key changes in Defold 1.13.1

In short, Defold 1.13.1 introduces, among other things:

new Light components for ambient, directional, point, and spot lights;
editor support for creating, editing, positioning, and previewing lights;
automatic binding of active light data to compatible shaders through LightBuffer;
instancing support for models using morph targets;
broader controller compatibility through the SDL game controller database;
borderless fullscreen by default on desktop platforms;
asynchronous collection loading through collectionproxy.load();
a new C API for making HTTP requests from native extensions;
richer editor-script dialogs, tabs, image processing, commands, and UI states;
new /ref and /preview endpoints in the editor HTTP API;
a well-known installations.json file for locating installed Defold editors;
warm builds that are up to 19% faster in large projects;
configurable mouse bindings for Scene View navigation and editing;
fuzzy symbol search in the code editor;
support for resource archives larger than 4 GiB;
improved HTML5 audio playback and Ogg/Vorbis decoding;
an experimental Metal graphics backend for local engine builds;
numerous engine, editor, build-system, and platform fixes.

Light components for 2D and 3D projects

One major new feature in Defold 1.13.1 is the introduction of first-class Light components. Defold now supports four light resource types:

ambient lights;
directional lights;
point lights;
spot lights.

Ambient lights provide a constant contribution across the scene. Directional lights represent light arriving from a direction, such as sunlight or moonlight. Point lights emit outward from a position, while spot lights produce a directional cone with configurable inner and outer angles.

Light resources can be added to game objects like other Defold components. They can be created and configured directly in the editor, where their position, direction, range, color, intensity, or cone angles can be adjusted and previewed in Scene View.

Defold does not force a specific rendering or lighting model on a project. Instead, the engine collects active light data and makes it available to compatible shaders through a built-in LightBuffer. A shader that declares the expected buffer layout receives the populated light data automatically.

This keeps Defold’s rendering pipeline flexible. Projects can use the built-in lit model materials, adapt the provided lighting helper, or implement a completely custom lighting model while still using Light components as the authoring and runtime data source.

Check out also our Defold PBR Assets project with shaders utilising the new Lights components.

Lights affecting models using Defold PBR assets

Lights are not limited to 3D games. The same data can be consumed by custom sprite (or tilemaps or particlefx) materials, making it possible to build dynamic 2D lighting.

The Light component manual explains the component properties, project limits, shader buffer layout, and built-in lighting helper. You can also explore the Basic Lights 2D and Basic Lights 3D examples.

The release also improves the built-in lit materials used with skinned models and increases world-matrix precision for lit materials on ES2-based graphics backends. These changes improve normal handling and reduce lighting artifacts around model edges.

Instancing for models with morph targets

Defold 1.13.0 introduced support for morph targets, also known as blend shapes. Defold 1.13.1 extends this support by allowing models with morph targets to participate in GPU instancing.

A new SEMANTIC_TYPE_MORPH_TARGET_WEIGHTS vertex attribute semantic can be used to supply morph target weights as per-instance data. A shader attribute named morph_targets_weights tells the engine to include the weights in the instance buffer alongside attributes such as mtx_world and mtx_normal.

This is useful when rendering many copies of the same model while giving each instance a different expression, deformation, or visual state. Instanced crowds or e.g. vegetation can use the same mesh and material while varying their morph target weights individually.

Broader gamepad compatibility

Defold 1.13.1 adds support for the widely used SDL game controller database. This database provides standardized mappings for a broad range of controllers and platforms.

SDL mappings are enabled by default. At runtime, Defold first attempts to match a connected controller by its GUID and then falls back to the legacy device-name matching system. A new input.gamepad_deadzone project setting controls the dead zone used with SDL mappings.

The existing .gamepads format remains supported, which allows current projects to migrate gradually. The gdc tool has also been updated to output the new SDL mapping format.

This should reduce the amount of controller-specific configuration needed and improve the likelihood that a connected gamepad works with the expected layout. See the Gamepad input manual and the Gamepad Tester example for more information.

More powerful editor scripts

The Editor Scripts API has received a great set of expansions. Editor extensions can now create more capable tools that remain useful while developers continue working in the main editor, as dialogs created with editor.ui.dialog() can be non-modal, resizable, and given a predefined width and height. A non-modal tool can stay open while the user selects resources, changes properties, edits a scene, or navigates between files.

Editor-script interfaces can also use tabs through editor.ui.tabs() and editor.ui.tab(), as well as checkboxes with an indeterminate state. We hope to see even more tools with interfaces inside Defold.

The new image module allows editor scripts to load image files, read their dimensions, inspect individual pixels, and iterate over all pixels. This creates new possibilities for e.g. asset validation, palette analysis, source-image processing, texture tooling, etc.

Commands can now target a Code location and query the active editor view. An editor script can determine whether the active view is a code editor, scene, HTML view, or form, inspect the resource being displayed, and check whether it has unsaved changes.

Editor scripts can also call editor.fetch_libraries() programmatically. The editor provides clearer feedback when scripts are reloaded and notifies the user when dependency changes require reloading scripts or fetching libraries.

These additions should hopefully make editor extensions feel more like integrated development tools.

New editor HTTP API endpoints

Defold 1.13.0 introduced a local authenticated /eval endpoint. Next version - Defold 1.13.1 continues expanding the editor’s HTTP API with two endpoints aimed at external tools, automated workflows, or coding agents.

The new /ref endpoint exposes Defold API reference information from the running editor. External tools can query functions, messages, properties, and other API entries without maintaining a separate copy of the documentation.

curl -s "http://localhost:$(cat .internal/editor.port)/ref?q=go.animate" \
  | jq '.[0] | {name, type, brief}'

The new /preview endpoint renders project scenes and returns them as PNG images. This is particularly useful for visual automation workflows. An external tool can modify a scene through the editor API, request a preview, inspect the result, and continue iterating automatically.

The editor’s OpenAPI description remains the entry point for discovering the available endpoints:

http://localhost:$(cat .internal/editor.port)/openapi.json

Defold also writes the location of installed editors to a well-known installations.json file. Third-party IDEs, launchers, command-line tools, or automation systems can use this information to locate the editor executable and installation directory automatically.

The file is written to:

~/Library/Application Support/Defold/installations.json on macOS;
${XDG_STATE_HOME:-~/.local/state}/Defold/installations.json on Linux;
%LOCALAPPDATA%\Defold\installations.json on Windows.

Together, /eval, /ref, /preview, the OpenAPI specification, and installation discovery provide a stronger foundation for integrating Defold with external IDEs, automated tests, custom pipelines, and AI-assisted development tools.

We’ve added 5 more manuals touching topics of automation workflows, automated testing, validation, AI agents coding, and the expanding Engine and Editor HTTP services.

Faster warm builds and smoother iteration

Large projects benefit from a substantial improvement to warm build performance. In the test project used during development, a warm build with an existing build cache improved from 3 minutes 16 seconds to 2 minutes 37 seconds—up to 19% faster. The exact improvement depends on the project, hardware, and resources.

Other workflow improvements:

recent projects remain on the welcome screen until explicitly removed;
idle editor CPU usage has been reduced;
dependency fetch timeout handling has been improved;
Bob cleans up temporary build files more reliably;
the custom debug resolution setting is now project-specific;
invalid resources created or edited by editor scripts produce clearer errors.

These changes are less visible, but they improve the development loop every day.

Platform improvements

Desktop fullscreen now uses borderless windowed fullscreen by default. When display.fullscreen is enabled, Defold creates a borderless window that covers the display instead of using the previous exclusive fullscreen mode.

For most games, borderless fullscreen provides smoother switching between the game and other applications and avoids some display-mode transitions. Projects that depend on the old behavior should test their window and resolution handling after updating.

Defold 1.13.1 also includes initial support for a Metal graphics adapter on macOS and iOS. The backend is currently intended for developers building the engine locally and must be enabled with the --with-metal build option. It is an important foundation for future development, but it is not yet the default backend distributed with normal Defold builds.

Audio improvements

HTML5 audio playback has been improved to avoid glitches and underruns in Samsung Internet and other affected browser environments. The audio queue now responds to browser-reported latency and detected underruns instead of relying on a fixed buffering strategy.

Ogg/Vorbis decoding has also been fixed for files with unusually large startup headers or metadata comments.

Native extension improvements

Native extensions can now use a new C API for HTTP requests. Extensions can obtain the engine HTTP service from the extension context registry and submit requests using the API exposed through dmsdk/dlib/http.h.

This allows native extensions to reuse an engine-managed HTTP service instead of implementing or embedding a separate networking stack for common request workflows.

Collection proxies improvements

Collection proxies also gain a new Lua API:

collectionproxy.load("#proxy", nil, function(self, message_id, message, sender)
    if message_id == hash("proxy_ready") then
        print("Proxy is ready")
    elseif message_id == hash("proxy_loading") then
        print("Loading progress", message.progress)
    elseif message_id == hash("proxy_error") then
        print("Loading failed", message.code)
    end
end)

collectionproxy.load() asynchronously loads and initializes the collection referenced by a collection proxy and reports progress and completion through a callback. This provides a direct function-based alternative for projects that want to coordinate loading screens, levels, or dynamically activated game areas (e.g. open world chunks, or areas in metroidvania games).

Editor usability improvements

Scene View mouse controls can now be configured in the Keymap preferences (File->Preferences->Keymap). Developers can customize mouse and modifier combinations for zooming, orbiting, panning, free-camera navigation, tile editing, and curve operations.

The code editor now includes a fuzzy jump-to-symbol dialog. Press Ctrl + Shift + O on Windows and Linux or Cmd + Shift + O on macOS to search symbols in the current script and jump directly to the selected result.

The grid settings popup also includes a color dropper, and several smaller editor fixes improve property controls, context menus, toolbars, dependency handling, and script error reporting.

Larger archives

The resource archive implementation now supports archive data and offsets beyond 4 GiB. This is particularly important for large Windows bundles that previously could fail to load resources when archive sizes crossed earlier limits.

Engine CMake build system

Defold’s internal engine build system has also been ported to CMake. This improves engine build workflows and makes it possible to generate development solutions for supported IDEs, including Visual Studio and Xcode configurations used when working on the engine itself.

These changes primarily affect engine contributors and developers with unusually large projects, but it removes important limitations and modernize the underlying build infrastructure.

Other improvements

GUI scripts can now remove named runtime texture mappings. This makes it possible to release dynamically created atlas resources when they are no longer required by a GUI scene.

Projects can optionally include dependency metadata in bundles by setting project.dependencies_metadata = 1. The metadata can help reproduce and debug builds by recording anonymized dependency URLs and available checksums or commit identifiers.

Important update and migration notes

Defold 1.13.1 updates the Apple SDK and Xcode toolchain used by the build servers to version 26.5. Projects that provide a custom Info.plist for iOS or macOS should compare it with the current built-in version and update their custom file before releasing a new build.

Projects should also test:

fullscreen and resolution behavior on desktop, due to the switch to borderless fullscreen;
controller mappings and dead zones if they use custom .gamepads files;
custom lighting shaders, ensuring their LightBuffer layout matches the built-in definition;
lights on older graphics contexts, as Light components are not supported on WebGL 1 or OpenGL ES 2;
large or timer-heavy projects affected by the included runtime fixes.

As always, update using version control and test all target platforms before shipping.

Summary

Defold 1.13.1 is available now. It introduces a flexible lighting foundation for 2D and 3D games, expands the editor into a more capable platform for custom tools and automation, improves controller support, and makes large projects faster to build and easier to integrate with external development workflows.

If you like the changes, consider helping us develop Defold further and bring even more exciting features and improvements - you can do so by spreading the word, helping test and catch issues, contributing, helping the community or donating.

We are excited to see what the community creates with Light components, richer editor extensions, and the growing editor HTTP API. Download Defold 1.13.1, explore the new examples and manuals, and let us know what you build!

From tabletop mystery to mobile city - how Soft Boiled Games brought MicroMacro to Defold

Thu, 30 Jul 2026 00:00:00 +0000

In the Creator Spotlight posts we invite Defold users to present themselves and share a bit of their background, their work and things that inspire them. It is an excellent opportunity for the community to come together, to recognise achievements and to share some of the great work done by Defold users.

This time we invited Felix Weiler from Soft Boiled Games to talk about MicroMacro: Downtown Detective - a very successful mobile title made with Defold, adapted from the hit board game series, and an upcoming Steam release.

MicroMacro: Downtown Detective made with Defold and released on Google Play and App Store

Hello Felix, introduce yourself to our community!

Hi, my name is Felix Weiler and I’m co-founder and developer at Soft Boiled Games. We’re based in Düsseldorf, Germany. In August 2025 we released MicroMacro: Downtown Detective, our first commercial game, a continuation of the successful board game series, made for the most part by the same team.

What are your favorite games? Do you have some nice hobbies?

I’m drawn to clever puzzle games and deep narratives, ideally both at once. Outer Wilds is probably my all-time favorite for exactly that reason: knowledge-gated puzzles, a miniature solar system to explore, and a real sense of discovery driving the whole thing.

Return of the Obra Dinn and The Witness are favorites that scratch a similar itch, and I’ll also always make room for Factorio, which is just so remarkably polished.

Right now I’m playing through Lorelei and the Laser Eyes, which I’m enjoying a lot for its striking visual style and how tightly the puzzles are woven into the narrative.

Outside of game development, I make music, and sometimes get away from screens with running, climbing, and hiking.

How did you get into game development? What did your journey look like?

Even as a kid I was more interested in taking games apart and figuring out how they worked than just playing them, so I got into programming early, before the internet made tutorials and resources as accessible as they are today. I was always tinkering on small game projects as a teenager, without any real plan to make a career of it.

I ended up studying and working as an electronics engineer in R&D, and later ran my own small consulting and development firm for electronic products. Game projects stayed a constant in the background the whole time.

The MicroMacro board game team and Soft Boiled Games are, at their core, friends who know each other from school and university, and had already worked together on other projects and businesses over the years. The board game’s success gave us the opening to found Soft Boiled Games and finally bring MicroMacro to mobile, something we’d considered from very early on.

MicroMacro board game series

You described MicroMacro: Downtown Detective as “probably a bit of an unusual case.” That immediately sounds intriguing. What makes this project unusual?

MicroMacro breaks with a lot of mobile market conventions on purpose: no pay-to-win, no in-game currencies, no timers. Where a lot of mobile design is built around quick action and manufactured waiting, MicroMacro asks for the opposite, a kind of analog slowing-down, real attention and thinking-through rather than just tapping whatever’s in front of you.

That same principle carries into the world itself: it’s one huge, continuous city, drawn in a minimalist comic style, filled with handcrafted stories and carefully placed clues. At a glance it might look like a typical hidden-object game, but it really isn’t about clicking around until something highlights: it’s about looking closely, thinking, and connecting stories.

The starting point was a beloved physical board game! What was the first moment when you felt that MicroMacro could work as a digital game? What parts of that experience did you most want to preserve?

We actually had a very early iPad prototype before the board game even existed, and our biggest worry from the start was whether a map that size would translate to a small screen. But we were confident early on that the core mechanic and feel would carry over. The board game itself was already known for its broad appeal, approachable even for people who don’t normally play board games, and going mobile only extended that further: a phone is in almost everyone’s hands these days. The board game also works best with a small group, while on mobile you can dive into a case entirely on your own.

Above all, what we wanted to preserve was the main mechanic that everything else grows out of: the same characters turn up in multiple locations across the map, each showing a different point in time. Following those threads is what turns a big illustrated city into surprisingly deep crime stories, closer to reading a comic panel by panel. We also wanted to keep the distinct style and feel of the original: that the city stays the same and you get to know it over time, that there’s always something interesting happening around you as you explore, and the humor and pop-culture references that run through it.

Designing detective cases for a zoomable screen must be very different from designing them for a printed map. How did that shape the way you approached development? What did you discover could not simply be translated one-to-one from the tabletop version to mobile?

We had to rethink how we design cases, mostly around readability on a small screen. What doesn’t translate at all is the immediate full overview you get on a printed map, the way one player can keep a finger on one corner while someone else is finding something in another place across the table. On mobile you’re always looking through a much smaller window into the world, so we introduced interactive elements and markers to help players navigate cases without losing that sense of the whole city.

During development we had time to really settle into designing cases for mobile. The new cases for the upcoming expansion, our second, are in our opinion the biggest and most complex we’ve built yet, and make full use of the whole nine-district city.

Mobile version has been released on Google Play and App Store

Compared to our earliest drafts, before we’d really learned what worked on a small screen, we ended up adapting the storytelling quite a bit: shorter texts, fewer guided camera movements, more situations that leave room for freer investigation.

Getting the balance right between free investigation and gentle guidance took a lot of fine-tuning, and a lot of playtesting with real players. The feedback shows it lands well for a lot of player types, though some would want it freer and harder, and for others it’s already fairly challenging. We’re currently exploring new ways to allow more open investigation without players getting lost, something like the “hard mode” the board game offers, which isn’t really possible in quite the same form on mobile.

The app uses its own city map and new cases. What made original content the right choice for the digital version? How do you approach the design of these?

Cases for the digital version are designed a bit differently, and we wanted to make good use of what the format allows. Search Warrants, letting players look inside houses, uncover crime scenes, find hideouts, and what we call “Superzoom”, where the player can zoom in very far in certain spots to find tiny details, are both good examples of things that simply aren’t possible in the physical version.

More importantly, we wanted to offer genuinely new content for fans of the series rather than a re-skin of something they’d already solved. Planning a new city and bringing it to life is something we really enjoy, and a lot of fans end up playing every version, board game and app alike.

Digital version is designed a bit differently than board games

What are the plans for the Steam version? How do you think it will be different from mobile and board games? Are you preparing it with Defold too?

There’s been demand from players for a Steam version since early on, and the format suits the game well, sitting down at a PC to work through a few cases is a mode we enjoy ourselves, even though MicroMacro started as a mobile game. There are also players who just aren’t interested in mobile and want it on PC in a more familiar form.

On the technical side, the main adaptation is the interface: the mobile version is built around portrait orientation with a necessarily minimal UI, while the larger screen just gives us more room to work with, and removes some of the constraints we’re designing around on mobile.

We’re building the Steam version in Defold as well, we know the engine well by now, and it’s been a good, productive environment to work in. It also means the mobile version can benefit from any improvements made along the way, which should be especially useful for tablet play.

Upcoming Steam release is also being made with Defold

When you started thinking about the technical side, what were the biggest requirements for the engine? Why did Defold become the right engine for this project?

Performance mattered a lot to us. It’s not a technically demanding game in the traditional sense, but we didn’t want to limit support to only the newest devices, and we realized fairly early on that quick, low-latency feedback on touch input is essential to how the game feels and how well players can concentrate while working through a case. It directly affects players’ ability to focus on finding clues and solving cases.

It also felt like a natural match: Defold started out as a mobile-focused engine, and that focus is still very much built into it.

What did Defold make easier than expected?

Defold’s regular updates are rarely breaking, you can usually take new features and improvements without worry, and when something does break compatibility, it’s clearly documented.

Cross-platform build workflows have been solid, and native extensions give us flexibility to go beyond the built-in functionality when needed. Overall it doesn’t feel bloated: the detailed control is there when you actually need it, and you don’t have to think about it when you don’t.

The game is built around a very detailed, zoomable city map. How did you approach rendering, memory, and performance for something like that?

The city map is genuinely large, and the total data footprint for the whole city ends up being bigger than you’d intuitively expect, even accounting for our fairly minimalist black-and-white style. Since we also wanted to support somewhat older, less powerful devices well, this became a core technical challenge.

Defold usually expects most of a game’s objects and their counts to be defined ahead of time, with memory preallocated accordingly. We do things a bit differently: we create and manage the relevant game objects and image data dynamically at runtime instead. I think it’s not the most common pattern in Defold projects, but it’s supported, and it’s what made our approach possible.

Loading and preparing data works against a per-frame budget, so we spread the cost out over time while still using that time efficiently, without stalling any other part of the game. Because the visible area can change very quickly during scrolling and zooming, we also try to predict which not-yet-visible parts of the city are likely to become visible next, and preload those where possible, including using idle time to load a bit further ahead. For unavoidable delays, we fall back to lower-resolution image tiles so there’s never a visible gap in the map, even briefly. The overall goal is to keep the experience free of stutters or distractions.

Looking back, what is the biggest design or technical lesson from the development?

Playtesting, above everything else: starting early, doing it often, and using it to actually check whether the core mechanic holds up and is fun, and whether every element in a case is really serving that, not just to find and remove friction. A lot of the case design decisions that mattered most only became clear once we watched real players get stuck, or breeze past something we expected to be a challenge, or once we realized something we liked just wasn’t pulling its weight.

And the tools you build your game with matter almost as much as the engine itself. Since our levels are really cases laid out across the city map, we ended up building a kind of level editor outside of Defold, for map and case configuration, and how good that tool was directly shaped how well, and how fast, we could design and iterate on cases.

What did you learn from testing and launching the game on mobile? How do you see the mobile games market nowadays?

We went in knowingly pushing back against some norms of the market, we wanted to make a mobile game we’d actually want to play ourselves. Honestly, there aren’t that many of those, and most of them are ports of PC games rather than mobile-first designs.

What we found is that a lot of our players really respond to a game that’s monetized fairly and transparently, no ads, no currencies, no subscriptions, you buy the game and own the content. Players also often highlight the relaxed pace paired with genuinely engaging content and puzzles, as a contrast to the louder, more aggressive side of the mobile games market.

I do hope, and I think I see some signs of it, that there’s growing room for games that don’t lean on the more aggressive end of monetization, where the experience matters more than squeezing every session for revenue. The indie space seems especially well-suited to that, particularly for more story-driven, mid-core games, it’s still a place where care and passion can carry a game.

The game’s huge, continuous city map

What advice would you give to developers considering Defold for making a game? What kinds of games do you think Defold is especially well suited for after making MicroMacro: Downtown Detective?

I’d really encourage looking closely at which engine fits the specific game you’re planning, including alternatives that might not be the obvious first choice, and making that decision independent of what’s currently fashionable in the market. For us, it was clear early on that dynamically loading and rendering a huge, multi-scale city map would be the core technical challenge, so we built proof-of-concept versions in a few different engines and compared performance directly, which also gave us a first feel for what day-to-day development would be like in each.

In conversations with other developers, I keep noticing that Defold still isn’t very well known. It’s probably not the first choice for huge 3D AAA projects any time soon, but for more modestly scoped games, it’s certainly worth putting on the list, and for mobile games specifically, the performance really stood out, especially on older devices.

You mentioned that you built proof-of-concept versions in several engines before choosing Defold. What exactly did you test, or what results made Defold stand out? Were there any measurable differences between the prototypes?

We tested a handful of core metrics across all the prototypes: initial loading time (from opening the map to the first view being fully loaded), tile processing time (how long it takes for a tile to fully load once it enters the visible area), time to a full view after zooming or panning, frame rate and how consistent it stayed, and memory footprint. We ran all of this on high-end, mid-range, and older, low-end devices too, I generally like testing a bit below our actual target spec, and we also paid attention to perceived speed and smoothness, plus how the development experience itself felt in each engine.

With Defold, the implementation turned out to be surprisingly straightforward, including the dynamic tile loading. Initial load time was great, and the per-tile timings and full-view-after-interaction times were solid too. But what mattered most was that it just felt noticeably snappier to users, especially on older, less powerful hardware. Looking ahead to building the whole game on top of that, the decision was an easy one.

“What mattered most was that it just felt noticeably snappier to users, especially on older, less powerful hardware.”

Next up is the second expansion pack for Downtown Detective, which will finally complete the nine city districts we’ve been hinting at, we’re hoping to release that by the end of the year.

After that comes the Steam version, which we think will open the game up to a good chunk of players who’d otherwise never have touched it on mobile.

Beyond that, we’ve just started early work on a next title in the series, built around a new, or heavily reworked, core mechanic. It’s still some way off, but it’s something we’re really excited about.

To stay up to date with any news and upcoming games:

Thank you very much for the interview, and we wish you tremendous success with MicroMacro: Downtown Detective and your future games!

Defold Newsletter June 2026

Wed, 01 Jul 2026 00:00:00 +0000

News

It’s been a long time!

The beta of the currently released Defold 1.13.0 was longer than usual because it was a bigger one with spring cleanup. And it also comes with great features! Check out our progress in the first half of 2026! If you have something you wish to share, please send us an email at info@defold.se.

Read the formatted newsletter here or read its content below:

Wavedash now supports Defold

We’re very happy to announce that Wavedash joins us as a Bronze partner! Wavedash is a website with free and paid premium web games, and we now have a Defold native extension for Wavedash SDK, check out the details here:

Read the announcement post

Summary of the first half of 2026

We invite you to read the summary of the recent 1.12.x and 1.13.0 releases that marked half of the year of work on Defold to make it a better engine:

Read our mid-year summary

GamedevJS Jam 2026 results

A total of 495 games were submitted, of which 17 were made with Defold! We have awarded 10 best games made with Defold, check the results here:

Check all games made with Defold on GamedevJS Jam 2026

New games made with Defold:

Assets, extensions and tools:

Defold Xoshiro 256

A fast, high-quality procedural random number generator

by Glorius Silver

Defold VSCode Kit

Using Defold Kit you can now e.g. build or hot reload from VSCode

by astrochili

Worth reading:

Power Fantasies - interview with Alex from 8BitSkull on Skull Horde and more

How is it to release 4 games and still run a sustainable game studio?

by Defold Foundation

Building Mad Skills Motocross 2 for Poki with Defold

In this Creator Spotlight interview we discuss about porting MSM2 to web.

by Defold Foundation

Best Practices for Web Games Development

Practical, useful article for anyone targeting web and HTML5 distribution.

by Defold Foundation

Post-mortem inforgraphic for Perfect+1 - a jam winner game

A nice article in a form of an infographic for a well designed puzzle game

by Hell Hog Games

Playgama Web Games Industry Market Map 2026

A great read for anyone following the web games market.

by Playgama

Deep Dive into Green Game Jam with Bounce Ball

Learn how it helped improving monetization, increasing revenue by 32%

by George Zarkua

Worth watching:

Defold 1.13.0 has been released

Highlights:

💪 Morph target support for model components
🧲 Expanded Box2D scripting, including joints
📹 Camera preview overlay in the Scene View
💨 Frustum culling for Particle FX
📱 Vulkan as the default graphics API on Android
🎨 New material and compute script modules
⚙️ Runtime graphics adapter and feature inspection
🤖 New authenticated editor /eval endpoint for automation workflows
🧹 Cleanup of legacy APIs and formats, fixes and more!

CHECK THE RELEASE ANNOUNCEMENT

Help Defold grow!

SUPPORT DEFOLD 🧡

Defold in the middle of 2026 - a summary

Tue, 30 Jun 2026 00:00:00 +0000

Defold - summary of the first half of 2026

The first half of 2026 has been an important period for Defold. Across five releases in the 1.12 series - 1.12.0, 1.12.1, 1.12.2, 1.12.3, and 1.12.4 - we continued improving the engine, editor, web runtime, rendering pipeline, 3D workflows, extensions, examples, and documentation. The period ends with Defold 1.13.0, one of the larger modernization releases. It brings, among other things, new Box2D scripting APIs, Morph Targets support for 3D models, rendering improvements, and a broad removal of deprecated APIs.

Earlier this year, in A look ahead for 2026, we outlined several priorities: better editor workflows, improved editor performance, more 3D work, richer animation support, rendering improvements, extension updates, and more tutorials and examples. Looking back at the first half of the year, many of those plans have already turned into concrete releases, and we are very glad to see that progress.

Defold Editor is now optimized for big 3D scenes, has a camera preview, a new breakpoints tab, and more!

A better foundation for game logic control

Defold 1.12.0 started the year with a change that affects how developers structure gameplay code: the update lifecycle was clarified and extended with the new late_update() function.

The new order is like this:

fixed_update() runs first as many times as needed to ensure a fixed timestep;
update() runs once per frame;
late_update() runs after regular update logic and before rendering.

Messages are also flushed between each update phase, which gives developers more predictable control.

This is especially useful in projects where gameplay and presentation should not always happen in the same step. A common pattern is to update game logic first, then update visuals, camera, UI indicators, or other dependent systems. late_update() gives Defold projects a cleaner place for that kind of work. Check out more details in the updated Application Lifecycle manual.

Pause when idle - engine throttling

Defold 1.12.0 also introduced a new engine throttling API. It allows a game to temporarily skip full engine updates and rendering while still listening for input. As soon as input is detected, the engine wakes up again for a configurable cooldown period, after which it can return to the throttled state automatically. So instead of rendering and updating continuously when nothing is happening, Defold can now reduce work until the player interacts again.

This is especially useful for games and applications that spend time in mostly static states: menus, idle screens, turn-based games, puzzle games waiting for player input, and battery-sensitive mobile or other portable devices.

A major step for Box2D physics scripting

One of the most exciting parts of Defold 1.13.0 is the expanded Box2D scripting API.

Defold had always included strong physics support, but the new Box2D scripting functions give developers much more direct control from Lua. The release adds joint creation, inspection, destruction, body/shape access, fixture and shape manipulation, mass data access, sensor changes, filter updates, AABB queries, joint limits, motors, spring settings, damping, reaction forces, torque, and more. This is powerful because it opens up a wider class of physics-driven gameplay without requiring native code.

Box2D scripting unlocks many possibilities - check, for example, the tuning example.

With the new APIs, developers can more easily build things like:

ropes, chains, bridges, cranes, vehicles, and mechanical contraptions;
grappling hooks and swinging mechanics;
destructible or reconfigurable physics structures;
physics puzzles with dynamic joints and constraints;
runtime-generated bodies and fixtures;
vehicles with wheels, suspension, motors, and limits;
tools and debug views that inspect physics state directly from Lua.

The added support covers both Box2D v2 and Box2D v3 APIs. The Physics joints manual and examples such as Box2D Mouse Joint, Box2D Motor Joint, Box2D Revolute Bridge, and Box2D Chain Terrain are good starting points.

Morph Targets, aka Blend Shapes, for 3D animation

Another major 1.13.0 feature is support for Morph Targets, also known as Blend Shapes, in 3D model components.

Animation and manual control of weights in Defold with the Aria Blake model.

This makes it possible to animate model shapes directly, which might be used for facial expressions, mouth movement, muscle deformation, soft-body-like effects, shape transitions, damage states, character customization, and many other effects that are awkward or impossible to express with skeletal animation alone. With morph target support, Defold’s glTF pipeline becomes more useful for expressive 3D characters and animation-heavy 3D projects.

It is part of a broader 3D cleanup. Defold 1.13.0 also removed Collada support and committed to glTF as the modern 3D asset format. This lets us focus our effort on the pipeline that matters most today instead of maintaining older and unsupported solutions. The release also fixed model transform inconsistencies between editor and runtime for imported glTF assets, making 3D behavior more predictable.

There is still more work ahead, but morph targets are a meaningful milestone for Defold’s 3D future. You can try this today in the Morph Target Animation and Morph Target Weights examples and read the Morph Targets manual.

Better Camera component

Camera has come a long way toward becoming a more useful component, and the camera API has grown. In the editor, the camera shows the active projection frustum and its representation is scaled properly.

Defold 1.12.0 added camera conversion helpers such as camera.world_to_screen() and camera.screen_to_world(), making it easier to connect world-space gameplay with screen-space UI or mouse/touch input. See also the World to Screen and Screen to World examples.

We also have adaptive zoom - the orthographic camera can now be adjusted even when using Fit or Cover mode, and the new camera.get_orthographic_auto_zoom() function and read-only orthographic_auto_zoom property were added. Because the camera is now selected with render.set_camera() in the render script, there is no need to acquire and release camera focus, and those functions, which had already been deprecated, have now been removed.

Since 1.13.0, you can also preview what a selected camera sees directly in the Editor. This makes it easier to set up the scene or set the correct camera position and orientation.

Camera preview directly in the Defold editor will help you create scenes and adjust camera position and orientation.

Going international - font shaping and collections

Besides the Editor and the documentation being translated to other languages like Chinese, Portuguese, and Russian, the engine has also supported runtime text shaping and font collections since 1.12.0. This improves how Defold handles more advanced text layout cases, including proper kerning pairs, ligatures, and right-to-left text. It is an important step for localization, especially for games targeting languages and scripts where basic left-to-right character placement is not enough.

The new workflow allows developers to associate multiple .ttf files with a single font resource and load only the fonts needed for a given language. It also supports prewarming text so required glyphs can be generated before they are shown on screen, which makes runtime-generated fonts more practical for multilingual games.

Right-to-left languages are now supported out of the box - check the localization example.

Web games

Web remains one of Defold’s strongest areas. In Defold 1.12.4, an empty HTML5 project was reduced to around 1.06 MB. We track size changes carefully to keep Defold as slim as possible. For browser games, this is not just a nice technical detail. It directly affects loading time, conversion from visit to play, player retention, and the ability to reach users on a wide range of devices.

We also continued cleaning up the web runtime. Unsupported and unused web functionality was removed, and with 1.13.0, Defold fully commits to wasm-web and removes the old asm.js target. WebAssembly is the modern and widely supported target for web games, and this lets Defold focus on one stronger, cleaner web path.

We also saw more real-world examples of Defold being used for web-first development, so we encourage you to read:

Fingersoft brought Hill Climb Racing Lite to Poki with Defold,
Orenji Spark rebuilt Jane’s Fashion Studio from Unity to Defold,
Refold Games rebuilt Mad Skills Motocross 2 for Poki with Defold, using dynamic meshes and custom physics,
Best practices when building for the web

If you are making web games - Defold is a great fit!

Hill Climb Racing Lite by Fingersoft in the Defold Editor

Mobile games

We care about all supported platforms and keep the SDKs updated. For example, besides engine throttling, Safe Area support for Android and iOS phones is now available in the engine out of the box, and you can control how the GUI respects it.

We’ve also released an official Firebase Crashlytics extension for Defold that might be useful if you want better crash reporting in your Defold Android, iOS, and macOS projects. Besides that, we’ve updated many other official extensions, which we’ll mention below.

Live Update

Live Update also moved forward. In 1.12.4, legacy Live Update APIs were deprecated, and in 1.13.0, the old auto-mount feature and the old Live Update archive format were removed. The recommended path is now clearer: use liveupdate.add_mount() and mount zip archives or folders explicitly.

The new direction gives developers more control over what is mounted, when it is mounted, and how content is prioritized. Developers can keep the first download small, get players into the game quickly, and then download additional content.

Live Update archives can also be mounted from Android assets, which is useful for asset delivery strategies, and can be added to the Android bundle either through bundle resources or as an install-time Play Asset Delivery pack.

Sounds good

While sound streaming already existed in 2025, this year we’ve pushed sound forward as well and introduced a new AVAudio backend for iOS/macOS, replacing the deprecated OpenAL backend.

In 1.12.1, we added Windows sound device recovery and improved how raw sounds are handled in the editor by wrapping them as embedded sound components.

In 1.12.4, we improved the internal sound buffers so they can grow dynamically, fixing crashes with high sample rates or high playback speed, increasing the maximum speed limit from 5 to 50, and adding a new Sound System section to the profiler.

Finally, we’ve also released the official FMOD extension for Defold, which gives users with more advanced sound system requirements the capabilities they need for their sound design.

Rendering and graphics keep moving forward

In 1.12.2, model components gained custom vertex attribute data support, allowing developers to set and animate model attributes from Lua. 1.12.3 exposed time to shaders and added a Texture Transform semantic, which made examples such as texture scrolling or true billboarding easier and cleaner.

Check out the billboarding example.

Defold 1.12.4 added shader precision options and increased texture units per draw from 8 to 16. This gives developers more room for complex materials and multi-texture effects, especially in 3D or advanced 2D rendering pipelines.

With 1.13.0, Vulkan is the default graphics API on Android, with OpenGL available as fallback. This release also improved and expanded blending options and added more shader constants, including commonly used inverse matrix variants. New graphics script functions expose information about the active graphics adapter and supported features. This allows game code and render scripts to make better decisions based on the current device and backend. It is especially useful for cross-platform games where rendering features may need to adapt between desktop, mobile, and web. New material and compute script modules make it possible to inspect and update material and compute resources from Lua.

Particle FX components now support frustum culling, which might give a boost for games with a lot of particle effects.

Defold’s rendering system has always been flexible through render scripts and materials, but these changes expose more of that power to game code.

Cleaner APIs

Defold 1.13.0 also removed a large number of deprecated Lua APIs and old constants.

This kind of cleanup can require migration work in older projects, but it is important for the long-term health of the engine. A small engine should also have a clean API. Removing deprecated functions, clarifying module boundaries, and consolidating graphics constants makes Defold easier to maintain, easier to document, and easier to teach.

It also gives us a better foundation for future features.

Defold Editor updates

Editor improvements were another major theme in the roadmap. Besides performance improvements, we also introduced many quality-of-life and user experience features, some of which were already mentioned above.

First of all, we now have a long-awaited Free Fly camera mode in Scene View, introduced in 1.12.4 and enabled by holding the right mouse button or toggled with Shift + ` (backtick). You can now freely fly or walk across your scenes. We also improved the camera and grid settings in the toolbar. This, plus the newest camera preview option and optimized performance for 3D, improves navigation and orientation when editing collections directly in the Editor.

Free Fly Camera mode in Defold Editor.

Defold 1.12.0 added restoration of open editor tabs and improved runtime font workflows.

Then, 1.12.1 improved the Properties view and added a brand-new Breakpoints tab, allowing you to quickly investigate and manage code breakpoints (including conditional ones) for quicker debugging. In this version, we also added a new Dependencies category in the Assets panel to keep libraries separated from project files, allowed assets to be dragged into resource pickers, and improved large-project loading performance.

Next, 1.12.2 improved the Asset Browser “New…” menu, tidying up our components, scripts, and other resources that can be created in Defold.

You can now also open images directly in the editor.

A better organised New... submenu (with Light components from the upcoming 1.13.1), PNG images opened directly in the editor, and the Dependencies section separated from project files in the Assets pane

Defold 1.12.3 brought the Script Structure side panel for code editing, and a new Properties API for Editor Scripts.

We also added editor.ui.image() for editor scripts, and this was immediately picked up by the community - Insality uses it to display thumbnails of browsed assets in the Asset Store.

Asset Store by Insality uses images in custom editor UI. You can also notice a new Structure pane for script content and a new Breakpoints tab

In 1.12.4 we also improved camera controls, manipulator performance, and a glTF validator is now integrated into the asset pipeline.

Defold Editor is becoming faster, more scriptable, more useful for 3D work, and more suitable for larger production projects.

Automated and custom workflows

We also improved the /command/build endpoint, so external tools can know when a build has actually completed. In 1.12.3, we added OpenAPI support for the Editor HTTP Server, which makes the editor server easier to discover and use from external programs. In Defold 1.13.0, we introduced a new /eval endpoint for the editor server, which allows developers to design more automation systems. These features help users who want to incorporate agents into their workflow to close the loop, build more advanced toolchains, including local automation e.g. for testing, and create agentic systems that can inspect a project, run editor commands, evaluate small operations, trigger builds, and help developers with repetitive production tasks. We won’t be forcing AI-assisted workflows, but we’ll try to make development convenient and reliable for all users - those who want to use LLMs, and those who want to create custom automations.

We want the editor to stay lightweight, but also become more customizable and easier to integrate into each team’s workflow. Instead of forcing every project into the same large editor pipeline, Defold should provide reliable extension points and allow further customizations and automations for game creation, and we will keep moving in this direction.

Extensions continued to evolve

Extensions remain central to Defold’s design - we keep the engine lightweight, while powerful external integrations can be easily added to projects.

The Rive extension got major updates, including a new data binding API, a Lua binding overhaul, generated documentation, async APIs, global listeners, Linux Vulkan backend support, and later Luau scripting support.

The Spine extension received fixes and improvements for empty first frames, property options, indexed-buffer rendering, track alpha support, Linux ARM64 support, and deprecated API cleanup.

Other official extensions also moved forward, including AdMob, WebView, Firebase Remote Config, IronSource, Push, WebSocket, and the mentioned FMOD and Firebase Crashlytics extensions.

This extension work is important because many production games depend on ads, analytics, platform SDKs, animation runtimes, web views, remote configuration, push notifications, and platform-specific integrations. We believe that keeping these pieces moving alongside the engine is part of keeping Defold production-ready.

New Defold website and more examples

We refreshed the whole defold.com website, revamped many pages like Asset Portal, Showcase with new games made with Defold, and especially the Learn Hub, which is now meant to be a convenient starting point for anyone wanting to learn Defold.

And we made some progress on the learning side. We continuously update old manuals and examples and add new ones, e.g. Billboarding, Texture Scrolling, Morph Target Animation, Morph Target Weights, and many Box2D scripting examples.

We also created and released the full 3D Third Person Playground sample Defold project with shadows, keyboard, touch and gamepad controls, and many useful game mechanics. It is also available directly from the Editor Samples.

3D playground sample with shadows, multiple control options and base mechanics.

We are updating old tutorials (e.g. the old Astronaut tutorial is now a broader top-down movement tutorial) and adding new ones. For example, we created a dedicated and comprehensive Defold for Unity users guide for people coming from Unity.

We created a dedicated Defold tutorial for Unity users.

Astonishing Defold community achievements

We are also very happy that more and more games are being made with Defold and released on different platforms. Check out for example Skull Horde, Game of Fitna, Sprint City, Push Titans, Break the Forest, Knight Bolts, Clean-up Crew, Jane’s Fashion Studio, or Throst.

Sprint City by Second Stage Studio, developers of Speedrunners, released in March 2026 in EA on Steam, made with Defold.

We also published several interviews with our community members and developers using Defold:

Creator Spotlight: Kuyi Mobile
Power Fantasies - 8BitSkull on Skull Horde and sustainable indie development
and the interviews mentioned above with Refold on Mad Skills Motocross 2, Fingersoft on Hill Climb Racing Lite, or Orenji Spark on Jane’s Fashion Studio

The community continued to create useful learning material and tools as well. Asatte Games created a top-down island defense video tutorial series for Defold. Sam is creating a great 2D animation tool called SpriteLoop with great integration for Defold. We have new assets like the Biplanar Mapping Shader, WebP native extension, Defold Mic native extension, Asobi multiplayer backend, DefDragon for DragonBones, Live Unbundler, Random Number Generator, and many more. Existing assets also received updates, including Defold Event with Queues and Promises, Graph Pathfinder, Defold A* Pathfinding, DAABBCC, and DAABBCC3D.

We are very proud of our community and very happy that improvements do not only come from Defold engine releases, but also from a community that builds tools, writes examples, shares experiments, publishes postmortems, and helps other developers build and ship their games.

Two new partnerships

We are also very happy that 2026 brought two new important partnerships.

First, 8BitSkull joined the Defold Foundation as a corporate partner. 8BitSkull has used Defold for successful PC and console games such as Fates of Ort, Void Scrappers, Bore Blasters, and Skull Horde. Their support is especially meaningful because it comes from a studio that has been using Defold in real commercial production for years, and we’re very happy that Defold was part of their success!

Fates of Ort, Void Scrappers, Bore Blasters, and Skull Horde by 8BitSkull

Second, Wavedash joined the Defold Foundation as a corporate partner. Wavedash is a browser-native gaming platform where players can discover, play, and share games instantly. Alongside the announcement, we’ve created an official Wavedash SDK integration for Defold, so you can start releasing your web games on Wavedash right away! The collaboration will focus on web performance improvements and tighter integrations with the Wavedash platform.

Wavedash, a new browser-native games platform, partners with Defold to bring more games to the web

Together, these partnerships reflect two important parts of Defold’s current position: a strong base of commercial indie developers, and growing recognition of Defold as one of the best engines for fast, lightweight, high-quality web games.

We would also like to thank our existing corporate partners: MoonActive, Rive, Poki, Heroic Labs, and Denda Games for their continued support, and all our contributors and donors helping Defold grow!

A strong first half of 2026

The first half of 2026 moved Defold forward in many ways.

The engine became smaller and cleaner. The editor became faster and more capable, with advanced 3D workflows. Morph targets opened the door to more expressive 3D animation. Box2D scripting gave developers much deeper runtime control over physics. Rendering gained new low-level tools. Live Update became more explicit and predictable. Extensions continued to evolve. More examples, guides, games, and community tools appeared. And two new partnerships strengthened the ecosystem around the engine.

There is still more to do, of course. But the direction described in the 2026 roadmap is already visible in the releases.

The second half of 2026 should be just as exciting. Stay tuned!

Defold release 1.13.0

Mon, 22 Jun 2026 00:00:00 +0000

Defold 1.13.0 is a substantial release that develops several areas of the engine at once: model support, physics, rendering, editor tooling, and build workflows. This version introduces new functionality relevant to both 2D and 3D projects.

This release also includes many important cleanup changes. Older, long-deprecated APIs and formats have been removed, including Collada, asm.js, and the old Live Update format. Before updating existing projects, we recommend reviewing the full release notes and checking any parts of your project that may depend on older engine behavior.

Key changes in Defold 1.13.0

In short, Defold 1.13.0 introduces, among other things:

support for Morph Targets (also known as Blend Shapes), for model components;
an expanded Box2D scripting APIs, including support for joints;
frustum culling for Particle FX components;
Vulkan is now the default graphics API on Android, with OpenGL as a fallback;
new material and compute script modules;
new functions for inspecting the active graphics adapter, limits, extensions, and supported GPU features through the graphics API;
new blending control options in render scripts;
new shader constants, including inverse matrices;
improvements to orthographic cameras using Auto Fit and Auto Cover modes - adaptive zoom;
a selected camera preview directly in Scene View;
a local, authenticated /eval endpoint for the editor, enabling many new test automation scenarios;
direct opening of PNG and JPG images in the editor;
smaller final engine builds for macOS and Android;
faster resource syncing, dependency fetching, font generation, and improved editor responsiveness during builds;
important cleanup of older APIs, formats, and engine behavior.

This is a broad release. It includes features that are immediately visible while working on a project, as well as deeper infrastructure changes that will matter for the future development of the engine.

Morph targets for 3D models

One of the most important additions in Defold 1.13.0 is support for morph targets in model components. The engine can now use morph/blend target data stored in glTF files.

Morph targets allow a model to be smoothly deformed by blending between different shapes of the same mesh. In practice, this means that a model can keep the same structure while changing expression, proportions, or visual state without switching to a different mesh. This is especially important for facial animation, character expressions, mouth shapes in dialogue animation, transformations, damage reactions, mutation effects, stylized deformations, and any case where skeletal animation alone does not provide enough control over the surface of the model.

Control Morph Targets (Blend Shapes) of your 3D glTF models in Defold 1.13.0

For developers building 3D games in Defold, this means more expressive characters and a more flexible asset pipeline. Models prepared in 3D modeling tools can now bring not only skeletal animation data into the engine, but also mesh deformation data. Developers can then control morph target weights through materials and shaders, creating smooth transitions between different model states.

Animation and manual control of weights in Defold with the Aria Blake model

Morph targets are also useful beyond facial animation. They can be used for gameplay-driven changes in an object’s state: for example, an enemy can swell before attacking, a character can gradually transform into another form, an object can squash after impact, or an environmental element can change shape in response to interaction. These effects do not require separate models or a complex bone setup if they are better represented through simple shape blending.

Morph targets animation in Defold with Shewolf model by Polygon Artisan

Try the Morph Target Animation example to see glTF morph target animation playback, or the Morph Target Weights example to see how model.set_blend_weights() can drive blend weights from Lua.

In the same release, Defold removes support for the old, deprecated Collada format (.dae) and focuses the 3D pipeline on glTF/GLB. This clarifies the direction of model support in the engine and strengthens support for a modern format widely used in real-time graphics.

Expanded Box2D API

Defold 1.13.0 significantly expands the scripting API for the Box2D physics engine, both for V2, the legacy Defold version, and V3. The most important change is broad support for joints, but the release also includes new Box2D functionality in general.

You can now tune many parameters and properties from script - check the example

From Lua, developers can now create and control different types of physical connections. Depending on the backend used, V2 or V3, this includes distance, revolute, prismatic, weld, wheel, mouse, rope, pulley, gear, motor, and filter joints. The API also allows scripts to read connected bodies, local and world anchor points, reaction forces, torque, limits, speeds, angles, lengths, spring parameters, and motor settings.

Create bridges using revolute joints - check the example

Bridges, hinges, ropes, mechanisms, vehicles, moving platforms, cursor-based object grabbing, springs, pendulums, levers, physics puzzles, and dynamically generated structures can now be built directly in game scripts. The logic remains in Lua, without the need to create native extensions just to access core Box2D functionality.

Design complex terrain using chains - check the example

Access to fixtures and shapes has also been expanded. Scripts can read and change density, friction, restitution, sensors, filter data, and AABB. They can check shape types, test points, and manage shapes or fixtures attached to a body. In practice, this gives more control over object behavior at runtime: an object can change its physical properties after collecting a power-up, an enemy can become a sensor in a specific state, and a dynamic level element can modify its collision filter without rebuilding the entire scene.

Control damping and frequency using mouse joints - check the example

This is a major step for games that use physics as part of gameplay, not only as a simple collision system. Box2D becomes more accessible from scripts, and physics systems can be designed more directly in game logic. The Physics joints manual and Box2D API reference are the best starting points.

Rendering and the graphics environment

On Android, Defold now uses Vulkan as the default graphics API, with OpenGL as a fallback. The backend can still be controlled through the application manifest. For new mobile projects, this means moving to a more current default rendering path, without removing compatibility with devices or projects that require OpenGL.

The graphics module now includes functions for checking available graphics adapters and retrieving information about the currently used backend. Scripts can read the API family, version, hardware limits, supported features, and extensions. This is useful in cross-platform projects where a game may run on desktop, Android, web, or other environments with different GPU capabilities.

You can now check whether the runtime supports features such as compute shaders, storage buffers, texture arrays, multiple render targets, instancing, or 3D textures. This information can be shown in a debug UI, written to diagnostic logs, or used by the graphics settings system. It can also be used to choose the appropriate rendering path, making it easier to adapt settings to the current environment.

`material` and `compute` modules

New material and compute script modules have been added to the engine. They allow Lua code to read and modify selected data from material and compute resources.

For materials, scripts can work with constants, samplers, textures, and vertex attributes. For compute resources, access is available for constants, samplers, and textures. This gives developers more control over resources used by rendering and visual effects.

This change is important for projects with custom render scripts, debug tools, material editors, procedural effects, and systems that adjust shader parameters at runtime. Materials and compute resources no longer have to be treated only as static configuration prepared before the game starts. They can be inspected and updated by game code or tools.

Particle FX, blending, and shaders

Particle FX components can now use frustum culling. Emitters outside the camera view can be skipped during rendering if the project uses render.draw() or an active camera set through render.set_camera(). This is especially useful in scenes with many particle effects.

Render scripts also gain more precise control over blending. New functions allow blend factors and blend equations to be set separately for color and alpha. This is useful for 2D shadows, masks, lighting effects, specialized compositing, post-processing, and custom transparency handling.

New shader constants have also been added, including inverse versions of the most important matrices used in rendering. Shaders can now receive inverse world, view, projection, view-projection, and world-view-projection matrices without manually preparing this data in additional code. This helps with screen-space effects, position reconstruction, decals, ray direction calculations, and more complex materials.

Editor changes

Defold Editor receives several improvements to everyday workflow. Scene View can now display an overlay showing the view from the selected camera, making it easier to set up levels, framing, and scene composition without building the game just to see the camera view.

Tool popups related to the grid, camera, and scene visibility have also been improved. This includes better controls, value fields, shortcut handling, color selection, focus traversal, and localization.

The editor can also open engine-supported images, such as PNG, JPG, and JPEG files, directly inside Defold.

A local, authenticated /eval endpoint has been added to the editor server. It allows Lua code to be executed in the editor runtime. This feature is intended for local development tools, automation, editor scripts, and external integrations. It can be used to inspect resources, execute editor operations, prepare reports, and support more automated workflows.

Smaller builds and faster workflows

In Defold 1.13.0, final engine builds for Android and macOS have been reduced in size thanks to additional flags that remove unused code. The release notes report a reduction of about 354 KB on Android and about 576 KB on macOS.

Several areas of working with larger projects have also been improved. Resource syncing when opening a project now uses parallel directory traversal. Dependency fetching has been unified between the editor and Bob. Font map generation has been moved to a later build phase, and the editor UI remains more responsive during builds.

These changes are not visually spectacular, but they affect the daily development cycle: opening a project, fetching dependencies, building, and iterating.

Breaking changes

Defold 1.13.0 removes several older parts of the engine. Projects updated from earlier versions should be checked before migration.

Support for js-web / asm.js has been removed, as Defold’s web backend now focuses on wasm-web. Collada support has also been removed, so .dae models should be migrated to glTF or GLB. Old, deprecated Lua functions and constants, the old LiveUpdate format, and LiveUpdate auto mount have also been removed. We prepared a special Python script to check for deprecated APIs in your project available here.

Component winding order has been unified to counter-clockwise. Projects using custom culling should check their render scripts and materials. The import behavior for glTF/GLB models has also changed by removing automatic re-centering, so transforms are closer to what was prepared in the source tool.

These changes may require work in older projects, but they simplify the future development of the engine and reduce the number of exceptions Defold had to maintain. Please be especially careful when updating. Before updating an existing project, we recommend reading the full release notes, checking the breaking changes, and migrating on a project copy or in version control.

Summary

Defold 1.13.0 is available now. It cleans up and develops the engine in several concrete aspects. We believe these changes and the direction Defold is taking are good for the engine in the long term, and we hope you’ll make good use of the new feature to create great games!

Building Mad Skills Motocross 2 for Poki with Defold

Tue, 02 Jun 2026 00:00:00 +0000

In this Creator Spotlight interview, we invited Björn, Eugene, Sergey and Paweł from Refold Games to talk about what it actually took to bring Mad Skills Motocross 2 to Poki with Defold.

Mad Skills Motocross 2 was created for Poki with Defold

Tell us a little bit about what Mad Skills Motocross 2 is.

Paweł: Mad Skills Motocross 2 is a super fun, fast, side-scrolling motocross racing game built around short competitive sessions, tight realistic physics, and skill-based bike control. It was originally created for mobile phones in Unity by Mad Skills series creators Turborilla.

The core appeal is easy to understand but hard to master. You race across bumpy dirt tracks, manage jumps, landings, acceleration, and momentum, and try to beat rivals, friends, or leaderboard times. It is part arcade racer, part physics challenge, and it has a very loyal audience among players who like motocross games and especially the whole Mad Skills franchise.

The web version brought the series to Poki’s audience with daily competitive modes and a rebuild from scratch in the Defold engine experience by Refold Games, a game studio from the founders of the Defold Foundation.

Mad Skills Motocross 2 can be played now for free on Poki

Why did Turborilla specifically choose Defold for this port?

Björn: Turborilla and Poki had been discussing for quite some time various alternatives to bring Mad Skills Motocross and other games from Turborilla to the web. One option was to strip down a Unity version of the game and make a WebGL export, but it would be a challenge to get it down to a small enough size to make it load fast.

Performance was another concern. If you start from scratch with Unity and build the game with the web in mind you can get something that works decently well, but the size will still be an issue.

Thanks to the Defold and Poki partnership it was decided to use Defold and to make a port from scratch, rather than trying to adapt the existing Unity version.

So this was not only a simple port, but rebuilding the game from scratch in Defold suited specifically for the web games market. How did you manage to do so? What changed in the architecture? And how did you preserve the original game’s feel?

Eugene: Since we had an original mobile project as a reference, we could reuse many useful modules from there. Separate classes from Unity could be easily represented as Lua modules, which made the structure easier to understand and easier to maintain.

For the web version the main motto was: simplify. The original game has more modes and more functionality. For the web release, we wanted a concentrated experience.

On the other hand we’ve added several features aimed to satisfy the (not so hardcore) Poki audience. Namely, it’s landing and flip assistance. These systems help players to perform tricks like backflips and frontflips and have fun, while still being able to land smoothly.

Paweł: I joined the project at the very end, but I was happy to see the same architecture approach I was using previously all the time - that separates view (audiovisual representation of the game) from logic (everything related to movement, controls, AI behaviour and other code-only related things) that is simply a result of years making games and coming to the same conclusions each time. And of course we were suiting everything to how Defold operates to make it most optimal.

Also, making GUI was super easy and efficient, as we utilised the powerful Druid Framework by Insality.

Mad Skills Motocross 2 Leaderboards GUI in Defold Editor

What should developers be aware of when porting a game to web? What is the hardest part?

Sergey: When porting a game to the web, there are several important factors to consider. Players may use low-performance devices or slow internet connections, and both affect whether they will stay. That means you have to optimize gameplay systems and reduce the overall build size as much as possible.

I would not say there was one single hardest part. The real challenge was choosing the right approach for each system and knowing how to solve performance and optimization problems efficiently.

Mad Skills Motocross 2 uses Turborilla’s own great custom physics engine. How does it work and how did you port it as a native extension in Defold?

Björn: We were fortunate that the custom physics engine in MSM2 was implemented as a clean, isolated C++ library with a small API surface. That made it much easier to extract the physics engine into a standalone native extension and expose it through Lua bindings.

The physics engine defines track geometry as a list of height data. The bikes are defined as a bike frame, wheels and rider, each with their own physics control points, weights, spring coefficients and other constraints. Both track data and bike data were read from a binary format and passed to the physics engine through the Lua API before the simulation started.

The player controls the bike by pressing throttle or brake and by leaning forward or backward with the rider.

At every update, the simulation advances with a fixed delta time and receives the current throttle, brake and lean inputs. After the update, we fetch the new state through Lua and position and rotate the individual bike and rider pieces according to the physics result.

“We had an initial version of the physics engine up and running in Defold in a matter of days.”

After that, it took some additional time to match the bike and rider positions from the physics engine with the Defold game objects and to generate the meshes for the track from the track geometry, but thanks to Eugene’s efforts this was also achieved with great results!

And for the visual part, you rebuilt the biker and tracks as dynamic meshes. Why did you choose meshes over sprites or prebaked animation?

Eugene: For the track ground, we dynamically create the track surface using mesh components based on a one-dimensional array of track heights. Then we attach a repeated ground image, with different variants for different environments.

On the left, a simple line representation of the 1D track height array, on right with an aligned mesh for the track

We also add shadows below the rider with another mesh curved according to the track height. On top of that, there are several more meshes for foreground and background grass, rocks, and the black area below the track. The result looks and feels pleasant without requiring a large amount of prebaked art.

At first we tried an orthographic camera, but it did not feel right and result didn’t satisfy us. The image looked too flat and lacked depth, so we moved to a perspective camera instead.

“As the game has pretty long tracks with long meshes, we were concerned a bit that this might affect performance, and had a few possible optimizations on our mind already, BUT in practice, Defold handled it extremely well, and meshes don’t influence game performance at all.”

Meshes did not become a bottleneck, and that gave us the freedom to build the scene the way the game actually needed it.

I also want to mention RenderDoc. It helped a lot when debugging graphics and render-related issues.

Paweł: And later on Eugene was invited to the Made with Defold Jam 2025 as a speaker and presented a great lecture about Meshes in Defold that you can now watch online here, and trust me, it’s worth watching, if you would like to do anything with meshes. Check out also the open source online examples!

Sergey: For the bike and rider, we also used a mesh. Initially we used regular sprites, but with a perspective camera the wheels and other elements started to flicker as the rotation angles and positions changed. Unfortunately, adjusting the Z positions pushed sprites noticeably farther away in a way that did not feel right.

In the end, we decided to render the entire bike and rider as a single mesh while keeping the center of each element in the same place. One of the trickier parts was that the wheels still needed to rotate relative to the bike, so we had to recalculate vertex positions manually.

Foreground and background elements are meshes too

The game also introduces daily challenges and leaderboards. How did you integrate the custom server functionality?

Paweł: Turborilla had already done a very good job describing the API, and the client-side documentation was clear. We only needed to integrate it into the game. In Defold we could control the method, headers and body directly from Lua.

Sergey: For request handling, we used ludobits.m.flow based on coroutines wrapping the HTTP requests in a small backend transaction module with retries, error handling and coroutine support.

Paweł: Precisely, so the rest of the game could treat server calls like normal sequential logic. Daily Dash is a good example. The game downloads the current season data from Turborilla’s content server. Those requests are started in parallel where possible, and the results are cached in local save data. The gameplay code does not need to know much about networking - it just asks for today’s challenge or today’s opponents, and the backend layer handles the rest.

Leaderboards use the same pattern. Scores are sent to Turborilla’s server, and we only upload when the player improves their previous local best. Fetching ranks and leaderboard pages is handled by the same Lua wrapper, including pagination for the UI.

There was also one small trick around player names. The leaderboard service needed each user to have a valid, unique username matching a specific regular expression, but for the Poki web version we did not want to interrupt the player with account creation or a name-entry flow. So we generated a compact server-safe guest name automatically. If the server rejected it, we simply generated a new one and retried. In the UI, we decoded that internal name back into something more readable. From the player’s perspective it looked like a normal leaderboard name, but technically it satisfied Turborilla’s backend requirements without adding friction.

That is a good example of why Defold worked so well here: the whole solution stayed as a thin Lua layer around Defold’s built-in HTTP API. Notice also, that on the screenshots from the development we have a huge button in the bottom right corner with letter “D” - which was a “Debug” button simply used to open a popup with different settings and cheats for faster testing.

Leaderboards with randomly generated names

What did you have to do to make the game load fast enough and still preserve quality?

Sergey: To achieve faster loading times, we had to reduce the build size. For that, we used Defold’s Live Update feature - a very convenient technology that allows separate collections to be downloaded after the main build has loaded.

The game contains many different skins and backgrounds, so we split them into separate collections and loaded through Live Update mounts and proxies at runtime instead of stuffing everything into the first download. In practice, that meant we could keep the initial package small and stream in content when needed and it made a real difference.

Paweł: This is one of the clearest Defold advantages for web games.

“You can build a focused initial payload, then bring in the rest of the content when the player actually needs it, in the background. That is pretty much how the web should work.”

Sergey: We also used compression through texture profiles for images and TexturePacker extension for Defold to save space. TexturePacker was especially helpful because it accounts for transparent and empty pixels, which meant less wasted texture memory and a smaller bundle.

Mad Skills Motocross 2 Haunted Race

What do you think Defold brought to this project that would have been harder in another engine?

Paweł: The short answer is: a lot less friction. Defold gave us a small, web-friendly base, a powerful path for low-level code functionalities through native extensions, and runtime meshes that were great for the whole visual approach. That combination made it realistic to rebuild the game for the web from scratch without dragging a lot of mobile baggage along with it. And iteration speed while developing games in Defold is incredible. It also helped that the project stayed readable. We were not dealing with huge callback chains or a lot of platform-specific glue. The code stayed modular, and the important systems remained easy to reason about.

Eugene: Defold is small, fast and efficient.

“Engine functionality works great, and if something is slow - it’s a question to my own implementation.”

Looking back, what is the main lesson from this project?

Eugene: As we already ported many projects, rebuilding some from scratch, one important thing is that porting project is much easier if you have access to original code! And one more: Mesh component is a great tool, one just need to figure it out.

Paweł: It was very scary for me to add any online features like leaderboards, stuff like this, but when you face it, it’s not so difficult. Maybe because we already had a nicely working server infrastructure, because now only this part sounds scary to me, but there are a lot of solutions, also for Defold, that simplifies it a lot. Client side implementation is usually very simple and straightforward.

Thank you very much for the interview, and we wish Refold and Turborilla continued success with Mad Skills Motocross 2 on Poki!

Check the game online for free: Mad Skills Motocross 2 on Poki

Best practices when building for the web

Tue, 02 Jun 2026 00:00:00 +0000

This is a practical guide for Defold developers building for the web. Pay attention to each of the topics in this guide as they are crucial to your success on Poki and the web in general.

Quick summary

If there’s one thing to remember from this guide, it’s this: The best-performing games on Poki are designed for instant fun.

That means:

Fast loading (<20MB ideally)
Gameplay within seconds
Simple, satisfying gameplay loops
Excellent controls on both desktop and mobile
Clear visuals and readable UX
Replayability over complexity

Web players decide very quickly whether they want to stay. The strongest games remove friction, create immediate interaction, and make players think: “One more round.”

The web is a different playground

The web behaves differently from mobile, console, or PC. Players arrive fast, decide fast, and leave fast. At Poki, there is thousands of games enter testing pipelines every year. The games that ultimately succeed are rarely the ones with the largest feature lists or deepest progression systems. Instead, the strongest performers are usually the games that understand web player behavior exceptionally well.

A successful web game creates clarity immediately. It loads quickly, feels responsive within seconds, and gives players something satisfying to do almost instantly. On the web, the game starts the moment the page opens.

Session 0 is everything

One of the biggest differences between mobile and web is the importance of the first session. On mobile, developers can often rely on long-term progression systems, onboarding funnels, or retention mechanics that unfold over days or weeks. Web players behave differently. Many sessions are spontaneous and curiosity-driven. The first minute matters enormously.

Successful Poki games focus on immediate interaction, low friction, clear goals, satisfying feedback, and quick understanding. Games with long intros, dialogue-heavy tutorials, complex menus, or slow unlock systems generally struggle more on web.

Continuous gameplay performs best 🔁

Games that perform well on Poki usually keep the player actively engaged almost all the time. Whether the player is dodging enemies, matching tiles, drifting through corners, aiming shots, solving puzzles, surviving waves, or stacking combos, the important part is that the interaction feels continuous and satisfying.

Replayability matters enormously. The strongest games often create a “one more try” feeling where players naturally want to restart, improve, or continue.

File size is one of the biggest success factors

File size directly impacts whether players even start the game. On web, loading speed strongly affects Conversion to Play (C2P). If a game loads too slowly, players simply move on to another title.

As a general guideline, games should aim for under 20MB total size. Smaller is always better. Developers should aggressively optimize textures, audio, unused assets, dependencies, startup processes, and shaders. For Defold developers specifically, this is a major opportunity. Learn more about how to optimze game size in our optimization manual.

Defold’s lightweight runtime and HTML5-focused tooling align very well with browser player expectations.

Poki For Developers shows performance metrics such as gameplays, earnings, engagement time, and monetization

Controls need to feel great everywhere

Web players arrive from many different devices. The best-performing games feel smooth and intuitive everywhere. Games should respond instantly, avoid overly small UI elements, support touch naturally, and work well on both desktop and mobile.

Simplicity usually beats complexity

Web players generally respond better to clear, lightweight systems than complicated economies or progression structures. Rewarded ads typically work best when they feel like a second chance, a revive, an optional reward, or a bonus attempt. Heavy monetization layers or complex store systems often create friction instead of improving engagement.

Readability matters more than realism

Players browsing web platforms make extremely fast visual decisions. Strong-performing games usually communicate their appeal immediately through bold visuals, readable gameplay, clear interactions, recognizable gameplay moments, and clean UI. Visual clarity is often more important than visual complexity.

Support both landscape and portrait

Most games on Poki will be played both on desktop and mobile. It is important to design a game which can be played in both landscape mode on desktop and in portrait mode on mobile. Supporting portrait mode on mobile also means that banner ads can be used.

What Poki looks at during testing

Poki Inspector helps verify SDK events, initial errors, warnings, loading time, file size, and scaling behavior

The most important metrics during testing include:

Average Playtime: 5+ minutes
Very Strong Playtime: 7–10+ minutes
Conversion to Play: 65%+
File Size: Under 20MB

In general, strong playtime suggests replayability, strong conversion suggests low friction, and small file sizes improve accessibility globally.

Player Fit Test statistics help compare playtime distribution between tested versions

The biggest mistake developers make

The most common mistake is treating web as simply another export target. The strongest teams instead approach web as its own platform with different player behavior, session patterns, technical constraints, and design opportunities.

A simple question often separates successful web games from unsuccessful ones: “Can the player start having fun within ten seconds?”

Final takeaway

The games that stand out on Poki are usually not the most technically complex. They are the games that remove friction, respect the player’s time, load quickly, feel satisfying immediately, and create strong replayability. Web success comes from understanding player behavior first, and building around that reality from the very beginning.

Worth reading

For even more tips and recommendations head over to the:

Gaming platform Wavedash partners with Defold

Mon, 01 Jun 2026 00:00:00 +0000

The Defold Foundation partners with Wavedash to integrate Wavedash services and improve the web version of the Defold game engine

STOCKHOLM, SWEDEN - Jun. 1, 2026 - The Defold Foundation today announced that new gaming platform Wavedash joins the foundation as a corporate partner. Alongside the announcement, a Wavedash SDK integration for Defold is now available, making it easy for developers to integrate Wavedash features in their Defold games.

“We are excited and proud to welcome Wavedash as a Defold Foundation partner. Their decision to join the foundation as a corporate partner is a strong endorsement of Defold and further validates its position as a leading engine for web games. It also reflects the rapid growth of the web gaming ecosystem, where rising player expectations and demand for high-quality experiences are creating new opportunities for developers and studios to succeed with a web-first strategy.”, said Defold Product Owner Björn Ritzl.

The Defold Foundation will work on general performance improvements to the web version of the Defold game engine and build new integrations specifically for the Wavedash platform. The new integrations and performance improvements will be developed iteratively and primarily released in sync with the monthly stable releases of the Defold game engine

“Defold is one of the most respected engines in the web games space. It is source-available, lightweight, and engineered with craft. These are values we believe in at Wavedash. Partnering with the Defold Foundation lets us invest directly in the engine, tooling, and community of Defold developers.”, said Kyler Blue, CEO at Wavedash.

About Wavedash

Wavedash is a browser-native gaming platform where players can discover, play, and share games instantly — no downloads, no installs, no waiting. Built for developers who want to reach players with zero friction, Wavedash provides built-in social features, achievements, leaderboards, and the most competitive revenue split in the industry.

About Defold Foundation

The Defold Foundation is the owner of the free to use game engine Defold. The foundation works together with industry partners to provide free and open software and services to game developers across the globe. The foundation was created in May 2020 and is registered in Stockholm, Sweden.

About Defold

Defold is a free to use, source available, game engine with a developer-friendly license used for development of cross-platform games. Defold is used by a growing number of developers to create commercial hits as well as games for game jams and in schools to teach game development. Defold is known for its ease of use and it is praised for its technical documentation and friendly community of developers.

CONTACT

Kyler Blue Co-founder and CEO, Wavedash contact@wavedash.com

Björn Ritzl Product Owner, Defold Foundation bjorn@defold.se

Power Fantasies - 8BitSkull on Skull Horde and Sustainable Indie Development

Fri, 15 May 2026 00:00:00 +0000

We invited Alex Asvegren from 8BitSkull back to the Defold blog. Since our first interview after the release of Fates of Ort, 8BitSkull has shipped Void Scrappers, Bore Blasters, and now Skull Horde.

This time we talked about the studio strategy behind those games, the launch of Skull Horde, Steam marketing, localization, console plans, Defold performance, and what it means for a small indie studio to build a sustainable rhythm around compact power fantasies.

8BitSkull has shipped four commercial Defold games: Skull Horde, Bore Blasters, Void Scrappers, and Fates of Ort

Introduction

Alex, welcome back to our blog! We first spoke when Fates of Ort had just released and you were just starting with Defold. Later, we talked about releasing Void Scrappers on Nintendo Switch. Now you are here with four commercial Defold games shipped as 8BitSkull, an established and successful indie game studio. How would you introduce 8BitSkull today, especially to new readers?

Thanks for having me yet again! I hope I have something sufficiently interesting to say that warrants a third interview.

8BitSkull is a small indie studio based in Scotland. We focus on games that deliver compact and exciting power fantasies, often with elements of action and destruction. We primarily target the PC market via Steam, but also sometimes consoles like Nintendo Switch, thanks to Defold for making that easy!

Yes. Our first commercial project, Fates of Ort, was a naive labour of love. We did not particularly concern ourselves with market research or anything like that, and I think the reason the game did even moderately well was through the sheer amount of earnestness poured into it. It was not a sustainable approach though. With a development time in excess of 2.5 years, we would not be able to continue as a studio with games like this.

We tried to scope out a new direction, abandoning a few prototypes on the way. Finally, Void Scrappers ended up being our next released title. In many ways it was the polar opposite of Fates of Ort: tight scope, pure gameplay, and a focus on replayability. Crucially, development time was less than a year. I realised we had stumbled upon the centre of this diagram:

The studio strategy diagram behind 8BitSkull’s current direction

In order to formalise this learning and make sure it would not be forgotten, I wrote a document I refer to as our studio strategy. This details our approach as a studio, and in terms of gameplay elements it includes these four pillars:

Power - enjoyment through gaining strength in the game world
Excitement - fast pace, intensity, and thrills
Destruction - joy through causing chaos, mayhem, and destruction
Completion - upgrades, unlocks, and achievements

I think the existence of this strategy becomes readily apparent when evaluating Bore Blasters and Skull Horde.

What has changed most in how you think about game scope, production, and sustainability as an indie developer?

The aforementioned studio strategy document covers this area as well. Every game idea we come up with is assessed against this document. A game does not have to meet every criterion. For example, we would not reject a game idea just because it does not have enough “destruction”.

Beyond gameplay, we also assess factors like scope and production requirements, which directly inform sustainability. We consider how many systems we can carry over from project to project, whether a game idea leverages our experience, and so on. We design with gamepad input in mind so that our games work flawlessly on the Steam Deck and are trivial to bring to consoles like Nintendo Switch. We develop with localisation in mind from the start. We know how important demos are as a marketing tool, so we make sure to pick game ideas that demo well.

The final factor is scope. How much development time is required to launch? Every unit of development time is a cost that needs to be recovered, and thus increased scope needs to come with an increase in expected returns. Our soft target is about a year of development per game, though this often slips. We think we can strike a balance between a scope sufficiently large to make a meaningful game, but not so large that an unexpected failure would damage the studio.

Skull Horde

Skull Horde is described as an auto-battler dungeon crawler where you play as a flying skull necromancer. What was the original spark for that idea?

I have always been drawn to minion-managing roles in ARPGs. I love the feeling of summoning a horde of minions and having them do the fighting for me. At its core, we are trying to recreate the feeling of playing a Diablo 2 summoner necromancer, just modernised and with our own twist.

Skull Horde is a real-time auto-battler dungeon crawler where you play as a flying skull necromancer

How did you decide which systems should be automatic and which should stay under direct player control?

Simple and limited input is called out as something desirable in our studio strategy. We do not like tutorials, as both designers and players, so we like to aim for designs that minimise the amount of tutorialisation needed. Automated systems help achieve this goal.

In Void Scrappers, you talked about letting players become absurdly powerful rather than nerfing everything into balance. Did that same philosophy carry into Skull Horde?

To an extent! We keep it in mind, but sometimes it is not possible. I was quite concerned with players finding a favourite build and always heading straight for it, neglecting the joy of discovering other builds. Skull Horde is quite generous with rerolling and banishing, which means this is very achievable for players. As a result, we did need to nerf away some properly unbeatable builds, such as hordes of rats causing chill on hit and an infinite invulnerability engine.

However, when designing, I try not to be too heavy handed. One mechanic I am quite pleased with is the Curse system. At higher difficulties, players are forced to pick Curses that add additional challenges. Multiple Curses beyond the minimum can be selected, which gives access to Rites, powerful boons.

The game detects what builds a player uses a lot and offers up related Curses. Using Burn a lot? One of the Curses on offer will steer you away from it while buffing something else. This gives the player the opportunity to intentionally avoid a certain build trope in exchange for a reward. There are always enough options to choose from, so the player is not forced to abandon their favourite playstyle, but the design nudges them to give other builds a try.

“The player is not forced to abandon their favourite playstyle, but the design nudges them to give other builds a try.”

Various builds in Skull Horde

What was the hardest part of making summoned minions feel readable, useful, and satisfying without turning the screen into visual noise, especially because there are hordes of enemies approaching as well?

We have some experience with this, partly from Bore Blasters but particularly from Void Scrappers. It is difficult to fully solve this because the visual carnage is part of the fun, but here are a few things we implemented in Skull Horde:

Single-pixel-thickness outlines for units, so they are distinct from each other
Squad units have colour accents matched to their type, such as Rogue or Beast, that make them distinct from other classes
An option to highlight the player by rendering an animated circle around the character
An option to turn off things like health bars or stack icons

The visual carnage is part of the fun, but readability still matters

Steam

Skull Horde launched with strong reception and a very warm welcome. What did players understand immediately, and what did you have to patch, explain, or improve after launch?

The single biggest post-launch issue we experienced was an issue where some Windows users with unicode characters in their username encountered a crash when launching the game, particularly impacting East Asian users. As confused and disappointed players began leaving negative reviews, our score started dropping and threatened to go below 80% positive. At 70%, the score would turn into a “Mixed” rating, which would have been disastrous for the launch.

In a panic, I reached out to the Defold team, who kindly generated a hotfix on a Saturday morning to resolve the issue for me! I am extremely thankful for this as it had a huge impact on the success of our launch. Our score has now stabilised at 82% positive.

There were a few additional crashes happening as well. The Defold team helped me resolve the ones caused by my implementation, and fixed the ones that were a problem on the Defold side.

Beyond that, I have been hard at work over the past few weeks, doing daily updates with bug fixes, performance improvements, and quality of life features. As the pace of these has slowed down, I have started working on the first big post-launch content update.

Your games tend to sit in crowded genres, but you always manage to find a sharp appeal: space horde survival, machine-gun mining, skull necromancer auto-battling. How do you come up with those ideas? How do you test whether an idea is marketable enough before committing to production?

Actually, I am moving away from hooks a little bit! I think all the hooks for my games have been fairly weak. I am not even sure what the hook was for Void Scrappers - “Vampire Survivors in space”, maybe? Now I try to frame the appeal of a game in terms of the “fantasy” the player gets to experience.

Blasting swarms of enemies in space in an unstoppable racing ship, mining thousands of gems with a ridiculous gatling gun, amassing a huge horde of skeletal warriors… These are not really hooks, but they are super appealing fantasies.

If you are interested in this concept, I can strongly recommend this video by Jonas Tyroller: What Sells on Steam: You Don’t Need a Hook.

How much do you follow genre trends, such as survivor-likes, roguelites, and auto-battlers, and how much do you try to deliberately move close to or away from them?

I do not tend to particularly chase or avoid genre trends. I do get inspiration from contemporary games, but I do not intentionally set out to quickly chase trends. I am fairly comfortable that the audience I have identified for my games will continue having the same preferences, so I do not need to worry too much about trends.

Did the demo, wishlists, festivals, streamers, or early community feedback play a major role in shaping the final release? What would you do the same again?

Here is a chart of the wishlists gathered before release:

Skull Horde wishlists before release

Notably, we did not rely on festivals, other than Next Fest, or social media at all. The marketing strategy should be tailored to the type of game you are developing. A game trying to go viral should probably focus more on social media, but our gameplay-first approach is more suited for a demo and content creator strategy.

We had the demo out for about a year before release, which was tremendously valuable in terms of gameplay feedback, but also for bug fixing and spotting technical issues.

Skull Horde unit sales are distributed as follows:

United States - 28%
China* - 16%
Japan* - 9%
Germany* - 8%
Korea* - 5%
Canada - 3%
United Kingdom - 3%
France* - 3%
Australia - 2%
Poland* - 2%

* = localised

Due to regional pricing, the US will have contributed way more than 28% of revenue. Nevertheless, this distribution shows the importance of localising into languages beyond English.

We tend to localise into the following languages:

Simplified Chinese
Japanese
Korean
French
German
Spanish
Brazilian Portuguese
Polish

We intentionally do not bother with Traditional Chinese, Spanish (LATAM), and Portuguese. I think there is a high degree of mutual intelligibility for these languages, and if not, we have not ever received any complaints!

There are more languages we could add, such as Italian or Turkish, but you have to draw the line somewhere. We use human translators, so each language is a cost and an administrative burden.

When choosing what languages to localise into, you should consider:

How big is the market?
How well does that market speak English?

For example, it might not be worth it to translate into Dutch or Swedish, as the markets are not huge and English proficiency in the population is very high.

What do you think indie developers misunderstand most about Steam launches?

Good question! Here are a few things people should know:

Do not shadowdrop your game! Your Steam page should be up throughout your development cycle, gathering wishlists. Your launch is really important, and it is very hard to recover from a bad one.
Make sure you release a demo long before launch, and participate in a Steam Next Fest. Pick a Next Fest late in your development cycle so that your demo is in a polished state.
You can be successful without posting on social media. I mention this because I have always struggled to get traction on social media, and it has felt like a waste of time posting daily into the void. So I give you permission to ignore it, if it does not suit you or your game. Instead, treat the demo itself as a very powerful marketing tool.
Make sure to get 10 reviews from paying customers, meaning free keys do not count, quickly after launch. Same day if possible! This unlocks base visibility on Steam. Not explicitly, but it seems having a review score is required for certain visibility mechanisms. You are not allowed to reward people for leaving reviews, or ask for them in game, but you are allowed to yell at people in your community!
If it is feasible, try to aim for more than 5,000 wishlists to have a shot at appearing in the Popular Upcoming widget. You can verify whether you have enough by going to your game on steamdb.info and checking the “Store data” section under the Charts tab. If you have a “top wishlists” ranking, you will appear in Popular Upcoming. Note that there is currently a change in the Steam beta client that might remove Popular Upcoming altogether, so it is possible this information is stale when you read it!

I am not sure I have covered everything, so if anyone is interested in discussing this, the #business channel in the community Discord is a place you will find me.

8BitSkull Studio

How early do you bring artists and musicians into a project? Do you prototype alone first, or do visuals and audio shape the core loop from the beginning? Christoph Gray’s music has been part of earlier 8BitSkull titles. How important is continuity with collaborators when building a recognizable studio identity?

Collaborator continuity is super important. I have worked with the same people for years, and losing any one of them would be a big setback. They are reliable, quality people with detailed knowledge of the workflow.

I tend to take ownership of project selection myself, because I am the one running the business side and will be investing the most in terms of man-hours and money. Once a project is selected, I involve the rest of the team early. We develop things like visual identity cooperatively.

Skull Horde concept art sketches

From the outside, 8BitSkull looks like a studio that has found a repeatable rhythm. Is that accurate, or is every project still a leap into uncertainty?

Since the development of the studio strategy, we have definitely managed to hit our stride with multiple consecutive successful projects. I think in large part we owe that to the intentionality we apply to project selection, ensuring the games we develop suit our strengths and expertise. This is a creative industry though, so every project is still a risk. This is why we try to keep scope tight, so that any failures do not have an excessive impact on the survival chances of the studio as a whole.

You previously spoke candidly about cancelled or paused projects. What did those projects teach you that directly improved Void Scrappers, Bore Blasters, or Skull Horde? And what does success mean for 8BitSkull now?

I think they taught me a few things that we have already touched on. Primarily, this was about tight scope, with reasonably defined project boundaries in place before development starts. The abandoned projects were more aligned with Fates of Ort, in that we had a vibe we were going for and then just started developing without a plan in mind.

It was in the middle of development of one of the abandoned projects that I spent two weeks laying the foundation for Void Scrappers. I was frustrated with spinning my wheels on a poorly defined project with no end in sight. In contrast, the progress on Void Scrappers in two short weeks was exhilarating, and it was easy to visualise the finished project. I think the ability to imagine what the final product will be is a crucial aspect of actually delivering a completed game. Without this, you will be endlessly polishing and adding new features.

Void Scrappers gameplay

In the earlier interview, you described the Fates of Ort Switch release as fulfilling a childhood dream. I bet you still have it deeply in your heart, but how do you feel about your other games now?

There is definitely a higher degree of cynicism in the games I have released after Fates of Ort, but I think I have struck a healthy balance. Fates of Ort is more a work of art than a commercial product, but it was a naive approach to game development as a business. I get way more fulfillment and artistic expression from developing Skull Horde than I would if I had to go back to working as an accountant.

That said, I will still be making games when I retire, so I can lean more heavily into the artistic side again then!

Practices

Your games often involve many enemies, projectiles, loot objects, terrain chunks, or minions. Is Defold helpful for these kinds of games? What are your current best practices for high-object-count games in Defold?

Defold is very performant in this sense, so it benefits me tremendously. I also lean heavily on the work of more skilled developers for performance-heavy tasks, for example using Selim Anaç’s A* and AABB extensions. Things like pathfinding and collision detection are really expensive, particularly in a game like this, so my biggest recommendation is outsourcing these to extensions that perform these tasks very well.

Has your technical architecture evolved since then? What Defold patterns have survived across all your games, and what did you completely rewrite?

There are a lot of modules and components I have developed over the years that I carry with me from project to project. Things like game saving, input, menus and settings, collection proxy management, and so on. With each project, I naturally end up tweaking these to make them progressively better and more robust. I rarely throw anything out entirely, and end up making huge development time savings by reusing old code.

Bore Blasters gameplay

Defold

You have been using Defold for almost 10 years, and you have created a sustainable indie studio that is now a Corporate Partner of the Defold Foundation, which we are very proud of! What still makes Defold the right engine for 8BitSkull? Why was now the right moment to formalize that relationship?

Why fix what is not broken! Defold is really performant, I love Lua, and have tons of experience using the engine. I want to keep using it for years to come and so I am happy to finally be able to contribute more. I have been sponsoring Defold at the community level for years, and the reason we are going up to the corporate level now is simply because of the success of Skull Horde.

The announcement mentions performance improvements and desktop-specific functionality. Without revealing anything confidential, what kinds of improvements matter most to a studio like yours?

Our top priority is a big overhaul to the gamepad mapping functionality to leverage the SDL game controller database. I believe this is almost ready to ship!

We also want to see improved sound functionality in the engine so there is not a need to use sound engines like FMOD. I would also love to see some more features in the particlefx component, as we use it a lot for our juicy effects.

What does a good partnership look like from the developer side? Is it about feature requests, technical dialogue, funding specific work, roadmap influence, or simply supporting a tool you depend on? What would you like other commercial Defold developers to understand about supporting the engine financially or technically?

A big part of the benefit to me is simply contributing to the continued existence of the engine. Even without any other perks, this is a good enough reason to contribute financially. If I had to switch from the Defold engine to another one, this would represent a significant financial hit to my business, and I really want to avoid that happening.

I do not have the technical ability to support the engine, so financial support suits me better. Those that do have technical skills should get involved! The Defold team is quite small, and I have it on good authority that pull requests are very welcome and help lighten the workload.

Consoles

Fates of Ort and Void Scrappers both reached Nintendo Switch, but Bore Blasters was PC only. Do you plan to release Skull Horde on consoles? Maybe on other consoles as well? How do you decide now whether a game is worth porting to Switch or other consoles? Is it sales potential, controls, performance, genre fit, or something else?

We are not experts on the console market, and so our basic approach is to just release on the Switch and hope for the best. Our plan is to move on to porting Skull Horde to Switch after post-launch fixes and updates are more or less stable. We may also explore other consoles, but that is very uncertain at the moment.

Are there particular design choices you now make earlier because you know a game may later go to console?

Absolutely. This is a core part of the studio strategy document. When you develop a game with these things in mind from the beginning, things like porting to consoles become much easier.

Fates of Ort gameplay

What advice would you give to Defold developers who want to move from jams and prototypes to their first serious releases?

Start small. You do not have to make a tiny project, but you should be able to create a development roadmap with a sensible timeframe and clearly defined end goal. If you are targeting Steam, release this project even if you know it will not be successful. There is a tremendous amount to learn about the Steam release process, so it is worth doing a trial run first.

What is next for 8BitSkull: updates, ports, expansions, experiments, or moving on to the next game?

For the past few weeks, we have been swamped with fixes, and have now finally moved on to post-launch content updates. We will do this for a while until interest cools down, then we will port to Switch and start considering the next game project.

Thank you very much for the interview, Alex! Finally, how can the community follow you and the studio?

You are welcome! You can follow our Steam developer page and subscribe to our newsletter. You can also find me in the Defold forums and community Discord.

Defold

Defold Summer Newsletter 2026

News

Defold Game Jam 2026

Meet Defold at gamescom 2026

New games made with Defold:

Assets, extensions and tools:

Worth reading:

Worth watching:

Help Defold grow!

Defold release 1.13.1

Key changes in Defold 1.13.1

Light components for 2D and 3D projects

Instancing for models with morph targets

Broader gamepad compatibility

More powerful editor scripts

New editor HTTP API endpoints

Faster warm builds and smoother iteration

Platform improvements

Audio improvements

Native extension improvements

Collection proxies improvements

Editor usability improvements

Larger archives

Engine CMake build system

Other improvements

Important update and migration notes

Summary

From tabletop mystery to mobile city - how Soft Boiled Games brought MicroMacro to Defold

Hello Felix, introduce yourself to our community!

What are your favorite games? Do you have some nice hobbies?

How did you get into game development? What did your journey look like?

You described MicroMacro: Downtown Detective as “probably a bit of an unusual case.” That immediately sounds intriguing. What makes this project unusual?

The starting point was a beloved physical board game! What was the first moment when you felt that MicroMacro could work as a digital game? What parts of that experience did you most want to preserve?

Designing detective cases for a zoomable screen must be very different from designing them for a printed map. How did that shape the way you approached development? What did you discover could not simply be translated one-to-one from the tabletop version to mobile?

The game gives players digital affordances such as zooming, touch navigation, guidance, and interactive progression. How did you make sure these features helped the detective experience without making it feel too automated?

The app uses its own city map and new cases. What made original content the right choice for the digital version? How do you approach the design of these?

What are the plans for the Steam version? How do you think it will be different from mobile and board games? Are you preparing it with Defold too?

When you started thinking about the technical side, what were the biggest requirements for the engine? Why did Defold become the right engine for this project?

What did Defold make easier than expected?

The game is built around a very detailed, zoomable city map. How did you approach rendering, memory, and performance for something like that?

Looking back, what is the biggest design or technical lesson from the development?

What did you learn from testing and launching the game on mobile? How do you see the mobile games market nowadays?

What advice would you give to developers considering Defold for making a game? What kinds of games do you think Defold is especially well suited for after making MicroMacro: Downtown Detective?

You mentioned that you built proof-of-concept versions in several engines before choosing Defold. What exactly did you test, or what results made Defold stand out? Were there any measurable differences between the prototypes?

And finally, what are your future plans that you can share and how can we follow your progress and next games?

Thank you very much for the interview, and we wish you tremendous success with MicroMacro: Downtown Detective and your future games!

Defold Newsletter June 2026

News

New games made with Defold:

Assets, extensions and tools:

Worth reading:

Worth watching:

Help Defold grow!

Defold in the middle of 2026 - a summary

Defold - summary of the first half of 2026

A better foundation for game logic control

Pause when idle - engine throttling

A major step for Box2D physics scripting

Morph Targets, aka Blend Shapes, for 3D animation

Better Camera component

Going international - font shaping and collections

Web games

Mobile games

Live Update

Sounds good

Rendering and graphics keep moving forward

Cleaner APIs

Defold Editor updates

Automated and custom workflows

Extensions continued to evolve

New Defold website and more examples

Astonishing Defold community achievements

Two new partnerships

A strong first half of 2026

Defold release 1.13.0

Key changes in Defold 1.13.0

Morph targets for 3D models

Expanded Box2D API

Rendering and the graphics environment

`material` and `compute` modules