Defold

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.

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

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.

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.

For even more tips and recommendations head over to the Poki Developer guide.

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 Newsletter May 2026

Tue, 05 May 2026 00:00:00 +0000

News

Hello Defolder! Here’s your fresh Defold newsletter with updates and highlights from the Defold community and the Defold Foundation. If you have something you wish to share, send us an email at info@defold.se.

Read the formatted newsletter here or read its content below:

8BitSkull Now Supports Defold

8BitSkull has joined the Defold Foundation as a Bronze Partner. The studio creates successful PC and console games with Defold.

Read the Announcement Post

Meet Us in Poland and Czech Republic

The Defold team will attend Digital Dragons in Cracow, Poland on May 17-19 and Game Access in Brno, Czech Republic on May 29-30. If you are nearby, we would like to meet the local community.

Digital Dragons, Cracow, Poland, May 17-19

Game Access, Brno, Czech Republic, May 29-30

New Games Made with Defold

Clean-up Crew

by Kuyi Mobile

A relaxed cleaning and renovation simulation where players clean, fix, and rebuild messy rooms.

Play on Poki

Jane’s Fashion Studio

by Orenji Spark

A stylish dress-up game about creating looks, styling unique characters, and following their stories through fashion.

Play on Poki

Throst

by ZiG Games

A 2D retro arcade action adventure game about precision flying, gravity, and fighting through enemy defenses.

Throst on Steam

Assets, Extensions, and Tools

DefDragon - DragonBones Extension

by Ronald K Bett

A community extension for the free 2D skeleton animation software DragonBones, with support for DragonBones Pro 5.5 runtimes.

Learn More

Live Unbundler

by SalavatR

Enhances Defold Live Update by splitting large archives into smaller chunks.

Learn More

Random Number Generator

by Alchimystic

Defold-RNG is a fast, instance-based native extension for random number generation.

Learn More

Graph Pathfinder

by Selim Anaç

Graph Pathfinder now supports multiple navmeshes for pathfinding.

Learn More

Defold A* Pathfinding

by Selim Anaç

This native extension for A-star navigation has been updated.

Learn More

DAABBCC

by Selim Anaç

Version 3.0.8 is available with object validation improvements.

Learn More

DAABBCC3D

by Selim Anaç

Version 1.0.5 is available with object validation improvements.

Learn More

Worth Reading

How We Stayed on the Front Page of Itch for Over a Month

by Oleg Chumakov, Luden.io

A practical case study on how Luden.io kept SuperWEIRD visible on itch.io through tag strategy, strong banners, and page clarity.

Unity to Defold - Understanding the Shift in Component Architecture

by Orenji Spark

An article about recreating Unity-style component architecture in Defold with Lua modules, and how to adjust your mental model when moving from Unity.

Robo Dance - GamedevJS Post-mortem

by Insality

Read about making Robo Dance for GamedevJS Jam 2026, from early ideas to a rhythm-synced turn-based game.

Space Base Maintenance - GamedevJS Post-mortem

by Paweł Jarosz

How the Machines theme became a Defold-made 3D base-building game with resource loops, fragile systems, and balancing challenges.

Marshaller of Inalpla - Ludum Dare Post-mortem

by Jennifer S. Lange

A jam postmortem about making a whimsical fantasy interdimensional airport marshalling game with Defold.

What Engine I Choose in 2026 - My Personal Take

by Orenji Spark

Iwan from Orenji Spark shares why Defold is his main engine in 2026.

Defold 1.12.4 Has Been Released

Highlights:

Free Camera mode in Scene View
glTF validator integrated into the asset pipeline
New shader precision options
16 texture units per draw for better rendering capabilities
Text rendering performance boost
Smaller HTML5/WASM builds, with an empty project now 1.06 MB
Editor, rendering, and runtime performance improvements

We have also added new examples, refreshed Defold’s website, and updated the Rive extension.

Updated Rive Extension

Check Release Notes

Help Defold Grow

Support the Defold Foundation and help us cover operational costs. Donations are used to pay for the native extension build servers, which are provided free of charge to everyone.

Support Defold

Defold release 1.12.4

Mon, 04 May 2026 00:00:00 +0000

Defold 1.12.4

Featured: Fates of Ort by 8BitSkull

We continue our focus on making the engine faster, smoother and more reliable, while still maintaining the small size - and even decreasing it further - for HTML5 builds the empty project is now 1.06 MB. We also keep adding some nice features, i.a. a new Free Fly mode in the Editor for easier scene nagivation in 3D projects.

Summary

NEW: (#6519) Shader precision options (by Jhonnyg)
NEW: (#11750) Increase number of texture units per draw from 8 to 16 (by Jhonnyg)
NEW: (#12032) Deprecate the legacy LiveUpdate APIs (by AGulev)
NEW: (#10478) Add glTF validator (by Jhonnyg)
NEW: (#11697) Fix build error source links for embedded resources (by AGulev)
NEW: (#11828) Improved Scene View manipulator performance (by matgis)
NEW: (#3893,#12171) Update editor JGit dependency to version 7.6.0 (by matgis)
NEW: (#11185,#8840) Free camera mode in scene view + enhanced camera controls (by JosephFerano)
FIX: (#11845) Shut down the engine gracefully when creating a model component with model and rig are excluded (by britzl)
FIX: (#12078) Cleanup of missing argument types etc in our api documentation (by JCash)
FIX: (#9647) Fix for models with multiple meshes and mixed coordinate spaced materials (by Jhonnyg)
FIX: (#12031,#9045,#10327) Allow the sound system to grow its used memory to increase the sound speed limit and fix possible crashes (by AGulev)
FIX: (#12097) Added type safety to the graphics context handle (by JCash)
FIX: (#12107) Exclude unused code from the HTML5 build to reduce binary size (by AGulev)
FIX: (#12110) Fix for uniform buffers on WebGPU (by JCash)
FIX: (#11196) Don’t apply skinning twice (by Jhonnyg)
FIX: (#12114) Updated to Zip v0.3.8 and miniz 3.1.0 (by JCash)
FIX: (#12127) Remove unsupported luasocket functionality from HTML5 build (by AGulev)
FIX: (#12138) Optimize sprite culling (by ekharkunov)
FIX: (#8088) Store frustum has in render items to avoid already calculated culling (by Jhonnyg)
FIX: (#12136) Cache the text layout to speed up text rendering (by AGulev)
FIX: (#8899) Avoid deadlocks when the profiler stack is unbalanced (by AGulev)
FIX: (#11913) Switching the atlas in a sprite no longer throws an error if the current animation doesn’t exist in the new atlas (by AGulev)
FIX: (#12141) Fixed crash when calling model.play_anim() with an animation that is not present in the model (by AGulev)
FIX: (#12134) Show a Lua error when attempting to set the render target size <= 0 (by AGulev)
FIX: (#11572) Update GUI nodes if the texture has been replaced from a script (by AGulev)
FIX: (#12154) Fix occasional freezes on load in debug builds (by AGulev)
FIX: (#12093) Fix Box2D 3.1 trigger enter/exit when one collision object overlaps several triggers (by aglitchman)
FIX: (#12181) Display a warning when a profiler scope overflow occurs (by AGulev)
FIX: (#12189) Fixed an issue where HTTP requests could stall during app restart (by AGulev)
FIX: (#12190) Add the ability to increase the maximum sample count in the profiler (by AGulev)
FIX: (#12191) Windows fix for file operations using Unicode paths (by JCash)
FIX: (#12187) Apply filter params when uploading texture data (by Jhonnyg)
FIX: (#10552) Add check for ES2/WebGL1 shaders that highp is supported in shaders (by Jhonnyg)
FIX: (#11951) Add xdg-open fallback on Linux when attempting to open a link in the browser (by JosephFerano)
FIX: (#11054) Apply skeleton transforms for orphaned joints (by Jhonnyg)
FIX: (#11524,#11643) Fix glb rendering issue (by JosephFerano)
FIX: (#12106) Allow go.property() only in .script files (by vlaaad)
FIX: (#12025) Insert call arguments for LSP completions (by vlaaad)
FIX: (#9430) Fix build error log parse exception (by vlaaad)
FIX: (#8570,#3660) Replace SSDP/UPnP target discovery with mDNS/DNS-SD for Defold debug targets (by AGulev)

Engine

NEW: (#6519) ‘Shader precision options’ by Jhonnyg Two new game.project options have been added that controls how the default type precision for floats and ints are generated for GLSL ES shaders:

shader.glsl_es_default_precision_float = highp | mediump
shader.glsl_es_default_precision_int = highp | mediump

These will affect how the global type qualifiers are generated in the cross-compiled shaders:

#version 300 es
precision highp float;
precision mediump int;

NEW: (#11750) ‘Increase number of texture units per draw from 8 to 16’ by Jhonnyg Max texture units a draw call can reference has been increased from 8 to 16.

NEW: (#12032) ‘Deprecate the legacy LiveUpdate APIs’ by AGulev ⚠️ We are deprecating old LiveUpdate functionality in favor of mount/archive-based Live Update workflows.

The following Lua API has been deprecated:

liveupdate.get_current_manifest()
liveupdate.store_resource()
liveupdate.store_manifest()
liveupdate.store_archive()
liveupdate.is_using_liveupdate_data()
collectionproxy.missing_resources()

resource.* aliases for these APIs have been removed:

resource.get_current_manifest()
resource.is_using_liveupdate_data()
resource.store_resource()
resource.store_manifest()
resource.store_archive()

The deprecated API still works, giving users of the old Live Update time to migrate before it is removed later this year. However, it has been removed from the documentation, and some functionality has changed.

First, manifest signing keys are no longer part of the pipeline, which means:

bob.jar no longer accepts --manifest-private-key or --manifest-public-key
game.public.der is no longer generated or bundled, and the publickey and privatekey fields in liveupdate.settings are now deprecated and unused
At runtime, deprecated Live Update manifest and archive validation now check only supported engine versions instead of using bundled public/private key signatures

This change reduces the engine’s build size (for example, from 2,339,290 bytes to 2,423,041 bytes for a WASM release build, about ~3.6%).

Second, archive builds now include a new Live Update setting, Strip Live Update Entries from Main Manifest in game.project (liveupdate.exclude_entries_from_main_manifest), enabled by default.

When this option is enabled for archive builds that publish Live Update content, liveupdate-only resources are excluded from the bundled game.dmanifest, while the published liveupdate.game.dmanifest still contains the full resource list required for remote content delivery. Disable this setting only if you need the deprecated behavior where excluded entries remain in the bundled game.dmanifest. This reduces build size and runtime memory usage, especially for projects with a large number of resources in Live Update archives.

This option is enabled by default because mount/archive-based Live Update workflows are highly dynamic and users can replace archive content at any time, manifest data cannot be relied upon for resources excluded during the bundle build. For the same reason, collectionproxy.missing_resources() is now deprecated, as it depends on manifest data to detect excluded resources. It can be partially replaced by collectionproxy.get_resources(), which now returns an empty table {} when no collection exists in any mounted archive and Strip Live Update Entries from Main Manifest checked, indicating that the required archive has not been mounted yet.

FIX: (#11845) ‘Shut down the engine gracefully when creating a model component with model and rig are excluded’ by britzl This fixes a crash when trying to create a model component with model and rig excluded using an app manifest. The engine will now shut down gracefully and the log will show that the operation is not supported:

WARNING:RESOURCE: Unable to create resource: /_generated_90739376.modelc: NOT_SUPPORTED
WARNING:RESOURCE: Unable to create resource: /_generated_1f27f107.goc: NOT_SUPPORTED
ERROR:GAMEOBJECT: Could not instantiate game object from prototype /_generated_1f27f107.goc.
WARNING:RESOURCE: Unable to create resource: /main/game/game.collectionc: FORMAT_ERROR

FIX: (#12078) ‘Cleanup of missing argument types etc in our api documentation’ by JCash Some parts of the C++ api generation was missing some type information. Fixes to our internal scripts also now make it easier to spot such errors.

FIX: (#9647) ‘Fix for models with multiple meshes and mixed coordinate spaced materials’ by Jhonnyg Models that use .gltf files that use materials with different coordinate spaces can now be batched correctly.

FIX: (#12031,#9045,#10327) ‘Allow the sound system to grow its used memory to increase the sound speed limit and fix possible crashes’ by AGulev Compile-time assumptions about how large audio buffers need to be for all sounds created limitations on the playback speed that could be applied and on the sound quality that could be played safely. For example, playing a 384 kHz sound could crash on a device with a 44 kHz output rate. A similar issue existed for playback speed: increasing the speed requires more decoded data to be fed into the resampler, and the sound system could end up with a buffer that was too small, which could also cause a crash.

To fix this, the sound system can now grow its scratch buffers dynamically to ensure that enough data fits when needed. This fixes crashes in those situations and also allows the maximum speed limit to be increased from 5 to 50. It still makes sense to use reasonable sound sample rates, such as 44 kHz, since higher rates increase runtime memory usage as well as using high speed sounds. To help track that memory usage, a new Sound System section has been added to the profiler.

FIX: (#12097) ‘Added type safety to the graphics context handle’ by JCash This fixes a regression where the WebGPU backend used the wrong information to setup its context, resulting in erroneous rendering.

FIX: (#12107) ‘Exclude unused code from the HTML5 build to reduce binary size’ by AGulev Even though http_service.cpp and provider_http.cpp were unused in HTML5, they were accidentally included in the HTML5 binary.

Excluding them reduces the HTML5 release build from 2 604 862 bytes to 2 469 942 bytes, saving 134 920 bytes (~5.2%)

FIX: (#12110) ‘Fix for uniform buffers on WebGPU’ by JCash This fixes some uninitialized memory and handling of cached states that was introduced in 1.12.2.

FIX: (#11196) ‘Don’t apply skinning twice’ by Jhonnyg An issue has been fixed where world transforms are applied twice for static non-skinned meshes that are anchored to skeletal bones. Essentially, in some cases meshes would render in an incorrect position when playing an animation as opposed to the bind pose (i.e when no animation is playing).

FIX: (#12114) ‘Updated to Zip v0.3.8 and miniz 3.1.0’ by JCash This allows us to use vanilla library files which will help keeping the library up-to-date. We’ve also removed our zlib dependency, and instead rely on the miniz library, eliminating duplicate code. In doing this we can save on executable size. On macOS, the combined savings of the libraries is roughly 40kb.

FIX: (#12127) ‘Remove unsupported luasocket functionality from HTML5 build’ by AGulev TCP/UDP isn’t supported on the HTML5 platform with luasockets. Removing this functionality from the binary helps reduce the WASM binary size slightly (~1%)

FIX: (#12138) ‘Optimize sprite culling’ by ekharkunov Sprite culling spends less time calculating visibility now. But memory footprint grows by 20 bytes per every sprite component.

FIX: (#8088) ‘Store frustum has in render items to avoid already calculated culling’ by Jhonnyg The amount of time spent on frustum culling has been reduced when issuing multiple render.draw calls during a single frame.

FIX: (#12136) ‘Cache the text layout to speed up text rendering’ by AGulev Text layout calculation is pretty expensive. To reduce its cost, we cache it once and reuse it until layout-related parameters change. This significantly speeds up text rendering (1.5x-4.5x, depending on the selected font system, classic or dynamic fonts), but increases memory consumption.

FIX: (#8899) ‘Avoid deadlocks when the profiler stack is unbalanced’ by AGulev Fixes an issue where the engine may freeze if a user calls profiler.scope_begin("my_scope") without later closing it with profiler.scope_end(), or vice versa: closing without opening. In such cases, an error will be shown and scopes will be auto-closed at the moment of detection.

Also fixes occasional freezes when using profiler.dump_frame().

FIX: (#11913) ‘Switching the atlas in a sprite no longer throws an error if the current animation doesn’t exist in the new atlas’ by AGulev Switching the atlas previously showed an error when an animation didn’t exist in the new atlas:

ERROR:GAMESYS: Atlas doesn’t contain animation ‘anim’. Animation ‘new_0’ will be used

This used to happen even when the next line after changing the atlas switched the animation, which made the error unnecessary and annoying.

FIX: (#12141) ‘Fixed crash when calling model.play_anim() with an animation that is not present in the model’ by AGulev Fixed a crash when model.play_anim() is called without a callback and attempts to play an animation that doesn’t exist in the model.

FIX: (#12134) ‘Show a Lua error when attempting to set the render target size <= 0’ by AGulev An attempt to set the render target size less than or equal to zero crashes the engine. This fix prevents it by showing a Lua error instead.

FIX: (#11572) ‘Update GUI nodes if the texture has been replaced from a script’ by AGulev Fixed an issue where, when updating a texture in GUI, go.set() updates node parameters in debug builds but doesn’t update them in release builds.

FIX: (#12154) ‘Fix occasional freezes on load in debug builds’ by AGulev Fixes an issue where the profiler may get stuck in a deadlock in some cases, which is easier to reproduce on Android.

FIX: (#12093) ‘Fix Box2D 3.1 trigger enter/exit when one collision object overlaps several triggers’ by aglitchman 2D physics with Box2D 3.1 could report wrong trigger enter/exit when one object overlapped more than one trigger at the same time. Exits were applied incorrectly to all overlaps of a body instead of only the pair that ended. This change fixes that tracking and adds a regression test. Sensor overlap queries used for collision callbacks also read overlap counts from Box2D correctly.

FIX: (#12181) ‘Display a warning when a profiler scope overflow occurs’ by AGulev The app used to hang if the user made a mistake and created too many scopes. That made it hard to debug. Now the profiler warns the user about the problem.

⚠️ This introduces a breaking change to the DMSDK API:

void ProfileSetThreadName(const char* name);
void ProfileScopeBegin(const char* name, uint64_t name_hash);
void ProfileFrameEnd(HProfile profile);
void ProfileScopeEnd(const char* name, uint64_t name_hash);
void ProfileLogText(const char* text, ...);

replaced with

ProfileResult ProfileSetThreadName(const char* name);
ProfileResult ProfileScopeBegin(const char* name, uint64_t name_hash);
ProfileResult ProfileFrameEnd(HProfile profile);
ProfileResult ProfileScopeEnd(const char* name, uint64_t name_hash);
ProfileResult ProfileLogText(const char* text, ...);
// The result can be one of the following values:
// PROFILE_RESULT_OK
// PROFILE_RESULT_NOT_INITIALIZED
// PROFILE_RESULT_OUT_OF_SAMPLES

FIX: (#12189) ‘Fixed an issue where HTTP requests could stall during app restart’ by AGulev In some cases, an application restart could not complete an ongoing HTTP request, which could result in the app freezing.

FIX: (#12190) ‘Add the ability to increase the maximum sample count in the profiler’ by AGulev Added profiler.max_sample_count to game.project to allow using more than the default 4096 samples, which can be useful in rare cases.

FIX: (#12191) ‘Windows fix for file operations using Unicode paths’ by JCash This fixes issues when a folder or a filename contain Unicode characters. E.g. you could see Failed get application support path due to invalid conversions.

FIX: (#12187) ‘Apply filter params when uploading texture data’ by Jhonnyg Fixed an issue where updating font data in OpenGL changes texture filtering parameters but didn’t update the sampler dirty state. This caused a mismatch between the expected filtering state since the sampler settings were never applied.

Editor

NEW: (#10478) ‘Add glTF validator’ by Jhonnyg The glTF validation tool has been integrated into the asset pipeline. Building / loading a project with faulty glTF files will output errors now that needs to be addressed before they can be used in Defold. Usually, the quickest route to fixing the content is to re-export them via Blender (https://www.blender.org/).

Note: Validating .gltf files inside an archive (e.g project dependency) does not validate external buffers and/or textures.

NEW: (#11697) ‘Fix build error source links for embedded resources’ by AGulev Build errors coming from embedded resources now consistently open the owning file instead of ending up with an unknown or missing source.

NEW: (#11828) ‘Improved Scene View manipulator performance’ by matgis We now defer committing changes to the graph until the drag operation has completed when using Scene View manipulators. This can significantly improve responsiveness when the manipulated objects are referenced from a large number of scenes. An unfortunate downside of this new approach is that you won’t see the drag reflected across multiple open tabs in Split View until you complete the drag.

NEW: (#3893,#12171) ‘Update editor JGit dependency to version 7.6.0’ by matgis It seems the old version of JGit we were using has trouble with some repositories created by newer Git versions.

See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=581723

NEW: (#11185,#8840) ‘Free camera mode in scene view + enhanced camera controls’ by JosephFerano We have added a new 3D perspective free camera mode for navigating scenes! Click and hold the right mouse button to activate and move around with the WASD keys. There is a scene view popup on the perspective camera button with additional controls for the camera. The left mouse button controls (orbit, zoom, pan) now warp around the editor window to allow you to keep going forever. There are also several smaller improvements, like smoother zooming and localization for the grid menu.

Shoutout to @sprocketc who started the PR and @delinx who contributed his winapi know-how to the mouse_capture_windows.cpp module.

FIX: (#10552) ‘Add check for ES2/WebGL1 shaders that highp is supported in shaders’ by Jhonnyg ES2/WebGL1 shaders that have specified highp as the default precision qualifier might not work on all devices since highp for fragment shaders is not guaranteed to work on ES2.

To fix this, the shader build pipeline now patches the cross-compiled ES2 shaders with the following snippet:

#version 100 es

// If highp is specified as the default precision for floats:
#ifdef GL_FRAGMENT_PRECISION_HIGH
    precision highp float;
#else
    precision mediump float;
#endif

// If highp is specified as the default precision for ints:
#ifdef GL_FRAGMENT_PRECISION_HIGH
    precision highp int;
#else
    precision mediump int;
#endif

FIX: (#11951) ‘Add xdg-open fallback on Linux when attempting to open a link in the browser’ by JosephFerano

FIX: (#11054) ‘Apply skeleton transforms for orphaned joints’ by Jhonnyg In the cases where animations coming from a .gltf file where the root node of a skeleton has non-identity transform, the skinned objects in the engine would not be correctly placed when animating.

NOTE: This could mean that your projects with skinned characters might be rotated, scaled or positioned differently now when animating. If this happens, you need to fix this in your authoring package (e.g Blender) and re-export the offending .gltf files!

FIX: (#11524,#11643) ‘Fix glb rendering issue’ by JosephFerano Fixed issue on Linux and Macos where glb models weren’t being rendered correctly on systems with locales that use commas for decimal numbers.

FIX: (#12106) ‘Allow go.property() only in .script files’ by vlaaad Both editor and bob will now only allow go.property() in .script files. It never worked in .lua files, but now it explicitly generates a build error.

As a side effect of this, the editor now loads faster on big proejcts, where it no longer needs to parse all .lua files for properties. On an example big project, the observed improvement in load time was 6% (1m31s -> 1m25s).

FIX: (#12025) ‘Insert call arguments for LSP completions’ by vlaaad Accepting Lua function completions from the Lua language server now inserts the call with parentheses and arguments instead of only the function name.

FIX: (#9430) ‘Fix build error log parse exception’ by vlaaad

FIX: (#8570,#3660) ‘Replace SSDP/UPnP target discovery with mDNS/DNS-SD for Defold debug targets’ by AGulev Debug engine builds now advertise themselves over mDNS/DNS-SD using the _defold._tcp service and the editor now discovers debug targets through mDNS instead of SSDP/UPnP. iOS debug builds now publish the discovery service through Bonjour, so they can be discovered by the editor over the local network without an extra entitlements.

It fixes the issue that iOS targets can’t be discovered by the editor.

⚠️If you are using a custom Info.plist in your project, please make sure it is updated with the changes introduced in this version (new section):

        {{^variant_release}}
        <key>NSBonjourServices</key>
        <array>
                <string>_defold._tcp</string>
        </array>

        <key>NSLocalNetworkUsageDescription</key>
        <string>Discover Defold targets on the local network.</string>
        {{/variant_release}}

Scottish game development studio 8BitSkull partners with Defold

Wed, 29 Apr 2026 00:00:00 +0000

In the wake of their recent success with Skull Horde the Scottish game development studio 8BitSkull has decided to partner with Defold for future indie titles

STOCKHOLM, SWEDEN - Apr. 29, 2026 - The Defold Foundation today announced that Scottish game development studio 8BitSkull joins the foundation as a corporate partner. The Defold Foundation will work together with 8BitSkull to accelerate development of new features for the Defold game engine.

“8BitSkull has established their studio as the creators of high quality Steam games. My personal favorite is the arcade action game Void Scrappers, but the recently released masterpiece Skull Horde will give it a run for its money. We are immensly proud that 8BitSkull have chosen Defold as their game engine of choice.”, said Defold Product Owner Björn Ritzl.

The Defold Foundation will work on general performance improvements and desktop specific functionality in the Defold game. The new features will be used by 8BitSkull in their upcoming titles and made available to all Defold users through the normal monthly product releases.

“We have been using Defold for almost 10 years and the engine has been a significant contributor to our success as a studio. We are very happy to now be in the position to formalise our support for the engine and excellent team behind it through a corporate sponsorship.”, said Alex Asvegren, lead developer at 8BitSkull.

About 8BitSkull

8BitSkull is an independent game development team known for exciting games with a focus on satisfying power fantasies, with titles such as Bore Blasters, Void Scrappers, and Fates of Ort. Their latest project is Skull Horde, real-time auto battler dungeon crawler with a roguelite structure.

About Defold Foundation

About Defold

CONTACT

Alex Asvegren Lead Developer, 8BitSkull alex@8bitskull.com

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

Defold Newsletter April 2026

Tue, 21 Apr 2026 00:00:00 +0000

News

Read the formatted newsletter here or read its content below:

Defold x GamedevJS Jam 2026

We’ve announced the rewards for the best games made with Defold at the GamedevJS Jam 2026. Join the jam and have a chance to win!

Join the GamedevJS Jam 2026

Making of Hill Climb Racing Lite

We talked with Shiho Kaneko from Fingersoft about bringing the classic mobile hit game to the web with Defold. Read how it was made and published on Poki.

Read the Interview with Shiho Kaneko

New Games Made with Defold

Game of Fitna

by FIAgames

A thrilling death game visual novel set in 2030. You’re Zayn, a high school student thrown into sinister survival games.

Wishlist on Steam

Sprint City

by Second Stage Studio

This shared-world, fast-paced competitive platformer from the original creators of SpeedRunners is out now in Early Access.

Sprint City on Steam

Skull Horde

by 8bitSkull

This auto battler dungeon crawler, where you summon a horde of skeletons, launched on Steam on April 10, 2026.

Skull Horde on Steam

Push Titans

by Toonminator

Push Titans is now globally released on Poki. The game was also showcased on the Defold Forum.

Play on Poki

Read the Forum Post

Break the Forest

by Aeolian Codelab

A card-based roguelike where you must survive a dangerous journey through a cursed forest, out now on Google Play.

Get it on Google Play

Knight Bolts

by Hydraware

A physics-based game where you drop knights to defeat the orcs before they destroy the castle.

Check it out on the Forum

Assets, Extensions, and Tools

Defold Event with Queues and Promises

by Insality

This powerful library for cross-context events now includes modes, callback-based events, queues, promises, and more.

Learn More

Biplanar Mapping Shader

by Selim Anaç

Apply textures based on world position and surface normals, useful for terrain, rocks, and organic geometry.

Learn More

Defold WebP Native Extension

by Halfstar

WebP supports both lossless and lossy images as well as alpha channels, and it’s now available in Defold through this native extension.

Learn More

Defold Mic Native Extension

by Halfstar

Read microphone input with this extension, useful for voice-controlled games or chat features.

Learn More

DeFragCoord: Shaders to Defold

by Paweł Jarosz

Convert shaders from FragCoord.xyz to Defold directly using this simple guide.

Learn More

Asobi: Open Source Multiplayer Backend

by Daniel Widgren

A multiplayer game backend with open source code written in Erlang/OTP.

Learn More

Worth Reading

Creator Spotlight: Orenji Spark - Moving from Unity to Defold

We talked with Iwan from Orenji Spark about sustaining a long-running indie game studio and switching to Defold to publish lightweight web games.

Make Games, Not Engines: Why I Chose Defold

Erick reflects on how to choose the right game engine for stable, sustainable game development.

Push Titans: Unity Developer Makes a Game with Defold for Poki

Victor Corvalán describes the process of making Push Titans in Defold and publishing it on Poki.

Why HTML5 Is Blooming in Online Gaming Platforms

This article looks at the web games market and the continued growth of HTML5 game development.

New Defold Examples: Billboarding and Texture Scrolling

We’ve shared new examples, including billboarding with two modes and texture scrolling using new shader semantics and exposed time.

Billboarding Example

Texture Scrolling Example

Worth Watching

New Tutorial Series

by Asatte Games

Build a top-down island defense incremental game from scratch with Asatte.

Watch on YouTube

Every Game Engine Explained in 6 Minutes

by The Kernel Core

A quick overview of Defold and other game engines.

Watch on YouTube

Cube Mining 3D

by cenker cennet

Chunk system, custom 3D particles, and an infinite map are now part of this open source Minecraft-inspired clone.

Watch on YouTube

Defold 1.12.3 Has Been Released

Highlights:

Time exposed to shaders
Texture Transform semantic, useful for scrolling textures
Script Structure: list of functions and variables in the sidebar
Duplicate text selection
Filters in Input Bindings to assign inputs to actions more easily
New Properties API for Editor Scripts
OpenAPI for the Editor HTTP Server

And many more.

Check Release Notes

Help Defold Grow

Support the Defold Foundation and help us cover operational costs. Donations are used to pay for the native extension build servers, which are provided free of charge to everyone.

Support Defold

From Unity to Defold - how Orenji Spark rebuilt Jane's Fashion Studio for Poki

Thu, 02 Apr 2026 00:00:00 +0000

In this Defold Creator Spotlight we invited Iwan from Orenji Spark to tell us about his journey from a decade of mobile and web development to independent game creation, and about rebuilding Jane’s Fashion Studio in Defold during its Poki soft-launch.

Orenji Spark is a two-person team, with Iwan handling development and his wife shaping the art and creative direction. Together they have already released several smaller Defold projects such as Capybara Suika, Pool Merge Mania, and Tiny Farm, while continuing to grow Jane’s Fashion Studio for the web.

Jane’s Fashion Studio

Hello! Introduce yourself to the Defold community - who is behind Orenji Spark?

Hi! First of all, thank you for the opportunity. I really appreciate being featured in the Creator Spotlight.

I’d also like to thank Poki, not just as a platform, but also the team behind it. Their support and guidance throughout the process have been very helpful.

I’m Iwan, the developer behind Orenji Spark. I’ve been building games and applications for around 10 years now, mostly across mobile and web platforms. More recently, I decided to move into independent development.

Orenji Spark is actually a team of two. My wife is also a big part of it. She handles the art and creative design for our games, so it’s a collaborative effort between us. I focus more on the technical and development side, while she shapes the visual identity and overall feel of the games.

You’ve spent a decade building games and applications. How did that experience shape you as a developer, and what pushed you toward independent development?

Over the years, my mindset has shifted quite a lot. Earlier in my career, I tended to focus on building systems that were flexible and feature-rich, sometimes a bit over-engineered.

But with experience, I’ve learned to value simplicity, iteration speed, and clarity much more. Shipping something playable and improving it step by step has become more important than trying to perfect everything upfront.

Moving toward independent development felt like a natural step. I wanted more control over both the creative and technical direction, and also the freedom to experiment with different ideas more quickly.

Which game engines have you worked with so far?

I’ve explored quite a few engines over the years, including Cocos Creator, Construct, and Godot.

But the ones I’ve spent the most time with are Unity, Phaser, Cocos Creator, and now Defold. Unity was one of my primary engines for many years.

More recently, I’ve been leaning toward engines that are better suited for lightweight and performant web games, which is what led me to Defold. I’ve also released a few small games using Defold on platforms like Google Play and web portals, such as Capybara Suika, Pool Merge Mania, and Tiny Farm.

Capybara Suika

Looking back, how did your priorities change as you shifted more toward web games and performance-sensitive platforms?

The biggest shift was putting performance at the center of decision making.

For web games, things like build size, loading time, and stability across devices have a direct impact on player retention. Even small delays can affect whether a player stays or leaves.

So I started designing with constraints in mind from the beginning, keeping assets lean, simplifying systems, and making sure the game runs well even on lower-end devices.

For readers who haven’t played it yet, what is Jane’s Fashion Studio, and what kind of player experience were you aiming for with the game?

Jane’s Fashion Studio is a casual dress-up and styling game where players help different characters by choosing outfits and styling combinations.

Each character also has their own small storyline, so the experience is not just about dressing up, but also progressing through these character moments.

The goal was to create something relaxing, cozy, and accessible, while still giving players a sense of progression and creativity.

Jane’s Fashion Studio gameplay

You shared on the Defold Forum that Jane’s Fashion Studio started in Unity and was later rebuilt in Defold during the Poki soft-launch phase. What feedback or warning signs made you realize that porting the game was the right move?

During the soft-launch phase on Poki, we started to see clear signals that something needed improvement, especially around loading time and performance.

We also received direct feedback from players mentioning that the loading felt too long.

Poki’s dashboard was really helpful. It provides very detailed insights, gameplay metrics, engagement, conversion (C2P), device breakdowns, error tracking, and even player feedback.

Seeing all of that together made it much easier to identify where the issues were and how impactful they were. At that point, it became clear that we needed a more optimized approach for the web, which led me to try rebuilding the game in Defold.

Which of the improvements mattered most in practice, and how did they affect the game’s path to a global Poki release?

The improvements were quite significant.

The build size was reduced by around 65%, which had a big impact on initial loading time. The game became noticeably faster to start and more responsive overall, especially on lower-end devices.

We could also see the impact reflected in the Poki dashboard. Engagement and C2P started improving.

These changes made the experience more consistent across devices and gave more confidence moving toward a wider, global release.

“The build size was reduced by around 65%, which had a big impact on initial loading time.”

Which parts of the project were the most straightforward to recreate in Defold, and which parts forced you to rethink your approach from scratch?

The core gameplay logic was relatively straightforward to recreate.

The biggest difference was in data flow and structure. In Unity, I relied a lot on component-based patterns, ScriptableObjects, and prefabs to manage data and mappings.

In Defold, I approached it differently, using atlases and carefully structured naming for mapping. It required a bit of rethinking at first, but it actually made the workflow feel cleaner and lighter, with less overhead.

One feature I really like is GUI Layouts, which makes it much easier to handle different layouts like portrait and landscape without complicating the setup.

I also want to highlight the Defold community here. The extensions and libraries created by the community made the migration process much smoother and very enjoyable. They were genuinely helpful and saved a lot of time.

Jane’s Fashion Studio in the Defold Editor

For developers who currently have a 2D game in Unity and are considering Defold for web deployment, what would you tell them based on your own experience?

I’d definitely recommend trying it, especially if your focus is web, performance, or reaching a wide range of devices, including lower-end ones.

It’s not a one-to-one transition from Unity, and you may need to rethink some systems. But that process can actually lead to simpler and more efficient solutions.

What kinds of projects do you think are especially well suited to Defold?

I’m still learning Defold myself, but from my experience so far, it works especially well for 2D games that require good performance, particularly on web platforms and across a wide range of devices.

That said, I’ve also seen developers create very impressive and diverse projects with Defold across different genres. It definitely has more flexibility and capability than I initially assumed.

Tiny Farm in the Defold Editor

You’ve now released multiple smaller Defold games, including Capybara Suika, Pool Merge Mania, and Tiny Farm, and you also shared work in the community challenge and the Defold showreel. What have these smaller projects taught you?

These smaller projects have been really valuable for learning and experimentation.

They allow me to try different ideas quickly, test workflows, and understand the engine better without the pressure of a large project.

One key takeaway is the importance of keeping scope manageable and focusing on the core experience first. Each project becomes a stepping stone for improving both technical decisions and game design.

Your Tiny Worlds challenge entry and your other community posts show that you’re not just using Defold privately, but also engaging with the community. How has being part of the Defold community influenced the way you learn, experiment, or choose what to build next?

The Defold community has been a really positive experience for me.

The forum is especially helpful. I often find solutions there, and what’s interesting is that even posts from years ago are still relevant and still work well today. That consistency makes it much easier to learn and troubleshoot.

Participating in community activities like the Tiny Worlds challenge has also been very meaningful for me. My entry was selected for the Rookie Award, which was a really encouraging experience as someone still exploring Defold.

Being part of the community makes learning more enjoyable. Seeing what others are building and how they approach problems often inspires me to explore new ideas and different approaches.

The community is also very supportive, and the available resources are solid and reliable. Many older tutorials still work today, which reflects how stable and well-structured Defold’s fundamentals are.

Pool Merge Mania in the Defold Editor

What are you most excited to explore next, either in this project or in future games?

Right now, I’m mainly excited to continue growing Jane’s Fashion Studio, adding more stories, new characters, and more outfit variations so the experience can keep expanding over time.

At the same time, I also want to keep creating and publishing more games on web platforms using Defold. I really enjoy the process of building smaller projects, learning from each release, and gradually improving both the technical and design side.

I’m also interested in deepening my understanding of Defold itself. Seeing other developers create really impressive projects with it makes me realize there’s still a lot of potential I haven’t explored yet.

Capybara Suika in the Defold Editor

Finally, how can our community follow you?

If you’re interested, you can find our work and updates here:

Website: https://orenjispark.com
Instagram: https://instagram.com/orenjibrush
X (Twitter): https://x.com/orenjibrush
TikTok: https://www.tiktok.com/@orenji.brush

I’ll be sharing updates about our games and new releases there.

Thank you very much for the interview, and we wish you a success with Jane’s Fashion Studio and your future Defold games!

Why did Fingersoft use Defold to bring Hill Climb Racing to Poki?

Thu, 12 Mar 2026 00:00:00 +0000

We invited Shiho Kaneko from Fingersoft, to tell us about their adventure with Defold to create Hill Climb Racing Lite for Poki.

Hill Climb Racing Lite made with Defold

Hello Shiho! Introduce yourself to our community! What is your role at Fingersoft? What are your favorite games?

Hi, I’m Shiho Kaneko, producer of Hill Climb Racing Lite. I love games like Rhythm Heaven, Gorogoa, and Don’t Starve Together.

For readers who know Fingersoft, but not Hill Climb Racing Lite on the web, what kind of game is it, and what were your goals for making a web version?

Hill Climb Racing Lite on the web is based on the original Hill Climb Racing, but it’s not just the classic endless driving mode. We kept the infinite mode that players already know, but we also added a new mode called World Tour. This mode has a more linear progression and focuses more on skill-based challenge levels. In the World Tour, there are no unlocks or upgrades. Players can jump in and use powerful vehicles right away, without needing to grind first. The idea was to let players focus purely on mastering their skills.

Hill Climb Racing has always had a lot of hidden mechanics and depth that not all players notice at first. With the web version, one of our goals was to make those mechanics more visible. At the same time, we wanted to create something that feels fresh for modern web players, while still keeping the core feeling of the original game.

During the soft launch, we learned or at least formed a hypothesis that our original format might not be the best fit for modern browser audiences. We noticed that browser players tend to prefer short-term goals rather than long-term commitments, and they expect more frequent changes in gameplay.

“Based on this, we designed the World Tour mode around three key ideas: a clear sense of progression, minimal decision-making friction, and strong variety.”

In addition to offering different vehicles and levels, this mode shifts the focus from simply driving as far as possible. Instead, players are given different objectives and win conditions, encouraging skill-based play and alternative play styles.

Hill Climb Racing Lite - World Tour

Why web and why now? What did you see in the web games market that made this release a reality?

The Hill Climb Racing franchise is evergreen on mobile, and the original is one of the incumbents of the free-to-play mobile gaming era. We realized that web gaming, after the decline of Flash, was making a comeback and we wanted to offer an authentic Hill Climb Racing experience for the players who’d rather play short, instant sessions on web platforms like Poki.

Why did you choose Defold for porting the game to the web?

We evaluated several different engines before selecting Defold — in fact, it was the last one we tested. Previously, we had released a predecessor of Hill Climb Racing Lite on YouTube (YouTube Playables), so we were already familiar with platform-agnostic technical requirements.

There were a few key constraints. The game had to run in HTML5, the engine size needed to be very small, and solid Box2D integration was essential for our physics-based gameplay. Another important requirement was support for portrait orientation, as the game needed to be fully playable in that format.

We shortlisted around five HTML5-capable engines and built prototypes with each of them. Many had significant limitations when it came to Box2D support. While Defold does not offer built-in Box2D integration at the same level as some native engines, we discovered that someone had implemented a full Box2D conversion using Defold’s native extensions (Editor’s note: defold-box2d by user d954mas). This made it viable for our needs. Additionally, Defold’s visual editor was a major advantage.

The original Hill Climb Racing still doesn’t use visual tools, so having a proper visual UI editor, especially for portrait layout, significantly improved our workflow.

“Considering all these factors, Defold turned out to be the best fit for our technical and production requirements.”

Hill Climb Racing Lite in the Defold Editor

That’s awesome to hear! How did Defold feel in production at your scale? What did the day-to-day workflow look like?

Our production team is small and agile, typically consisting of one to three programmers. In that setup, Defold worked well for collaboration, especially since all project files are stored as text. This made version control and merging much smoother compared to engines that rely heavily on binary files.

That said, the beginning was quite frustrating. Initially, we tried to use Defold the same way we had used other engines like Unity or Godot. Over time, we realized that this approach didn’t work well. Defold is fundamentally different in its architecture, and once we accepted that and started using it as intended, things improved significantly.

One of the biggest mindset shifts was adapting to Defold’s strong emphasis on decoupling through its message-passing system between objects. Instead of tightly connected components, communication happens via explicit messages, which encourages a more modular structure. After adjusting to this paradigm, the workflow became more predictable and efficient for our small team.

What challenges have you faced during the development of Hill Climb Racing Lite, if any, and how did you overcome them?

One of the day-to-day challenges was actually the built-in Defold code editor — particularly the undo functionality, which didn’t feel up to modern standards. This sparked multiple heated internal debates :)

In the end, we handled it in two different ways: one of us accepted the situation and adapted, while the others “escaped” to Visual Studio Code. Moving to VS Code significantly improved the development experience and solved most of the frustration (Editor’s note: VS Code integration by user Roman Silin).

Good that we have options then! By the way this undo functionality change is our priority in the Defold roadmap now - we hope it will be satisfying then. And how was the release workflow?

We found the Poki Playtesting feature very helpful. It helped us to identify potential UX related issues.

Hill Climb Racing Lite - main menu

What did you learn about a “web-first” game design during this project? Was there anything particularly surprising?

On mobile, it’s relatively safe to design for multi-day progression and deeper meta systems, since players have already committed by downloading the game. You can rely on longer retention loops and layered progression.On the web, however, player behavior is very different. Users tend to look for quick gratification and immediate fun. Sessions are shorter, and the commitment level is much lower.

As a result, deep multi-layered meta systems don’t work as well — players are less willing to invest time before the game becomes rewarding. What surprised us most was how quickly web players decide whether to stay or leave.

“A “web-first” design needs to deliver value almost instantly, rather than building up slowly over time.”

This forced us to rethink onboarding, pacing, and reward timing.

What would be your recommendation for developers new to Defold?

Just try it yourself, it’s free! Give it at least a week before forming an opinion. Defold has a different architecture and mindset compared to engines like Unity or Godot, and it can feel unfamiliar at first.

Hill Climb Racing Lite - to the moon!

Our company’s main focus is still on supporting the growth of Hill Climb Racing and Hill Climb Racing 2, but in addition we’re developing and iterating on the next title of the franchise, Hill Climb Racing 3. That being said, we are keeping a keen eye on what platforms and distribution opportunities emerge, and aim to provide supply wherever there is demand for Hill Climb Racing.

Thank you very much for the interview, and we wish you a tremendous success with Hill Climb Racing Lite!

Check out the game on Poki:

Hill Climb Racing Lite

Follow Fingersoft on social media:

Join Hill Climb Racing Discord:

Discord

And subreddit:

And follow Hill Climb Racing accounts:

Defold

Building Mad Skills Motocross 2 for Poki with Defold

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

Why did Turborilla specifically choose Defold for this port?

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?

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

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?

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

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

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

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

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

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

Best practices when building for the web

Quick summary

The web is a different playground

Session 0 is everything

Continuous gameplay performs best 🔁

File size is one of the biggest success factors

Controls need to feel great everywhere

Simplicity usually beats complexity

Readability matters more than realism

Support both landscape and portrait

What Poki looks at during testing

The biggest mistake developers make

Final takeaway

Gaming platform Wavedash partners with Defold

About Wavedash

About Defold Foundation

About Defold

CONTACT

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

Introduction

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

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?

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

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?

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?

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?

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?

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?

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?

Which markets are most important to you, and which languages would you recommend other developers consider for localization?

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

8BitSkull Studio

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?

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?

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?

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?

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

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?

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

Consoles

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

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

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

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

Defold Newsletter May 2026

News

8BitSkull Now Supports Defold

Meet Us in Poland and Czech Republic

New Games Made with Defold

Clean-up Crew

Jane’s Fashion Studio

Throst

Assets, Extensions, and Tools

DefDragon - DragonBones Extension

Live Unbundler

Random Number Generator

Graph Pathfinder

Defold A* Pathfinding

DAABBCC

DAABBCC3D

Worth Reading

How We Stayed on the Front Page of Itch for Over a Month

Unity to Defold - Understanding the Shift in Component Architecture