We’d love to hear your feedback on the biggest challenges you face when working with Defold. This could be anything—from bugs in the engine, to usability issues in the editor, or even workflow improvements in our tools. No matter how big or small, your input will help us identify what matters most and make Defold more efficient and enjoyable to use.
The aggregated results will be shared here. We will carefully review the results and start working through the most frequently reported issues one by one.
Pro Tip: If there are any pain points that you can’t find easily using issue search or Google search - ask ChatGPT or similar - describe your issue and let it search for you, if it has internet access with web search - sometimes it really finds the issue you are thinking about, but was phrased or named differently.
If you yet still can’t find an issue you wished to point out - it’s high time to report it on Github!
Streamline the Shader System
Why Writing Shaders in Defold Feels More Complex Than It Should
Defold is a fantastic engine in many ways—lightweight, consistent, and developer-friendly. However, when it comes to shaders, the workflow can feel more complicated than necessary, especially when compared to engines like Godot or LÖVE.
Currently, creating a shader in Defold involves several steps: preparing a material file, writing a shader program file (with both vertex and fragment stages), and then assigning the material to the appropriate sprite, model, or GUI component. This structured approach is powerful, but for newcomers it may feel like too much setup for something as simple as “apply this shader.”
The situation becomes even more challenging with post-processing. To achieve effects such as blur, glow, or grayscale, developers need to modify the render script, set up custom render targets, manage buffers, and carefully control render passes. While this offers fine-grained control, it can also be intimidating for those who simply want to experiment with common visual effects. By contrast, in LÖVE a shader can be applied in a single line, and in Godot a ShaderMaterial can be attached directly to a node.
This complexity can slow down experimentation and discourage creativity, especially for beginners.
Suggestions to Improve the Workflow
Direct Shader Assignment
Allow shaders to be applied directly to sprites, GUI nodes, or models without requiring a separate material file. Materials would still be valuable for advanced customization, but having a shortcut would make simple use cases much more approachable.
Built-in Shader Templates
Provide a small set of ready-to-use shaders (e.g., grayscale, blur, outline, distortion). Since many developers end up creating these anyway, offering them as templates would save time and help newcomers get started.
Enhancing Post Effects
Defold’s post-processing system is very capable, but making it easier to use would greatly benefit developers:
Post-Effect Stack System
Enable multiple effects (like blur, bloom, and vignette) to be combined without requiring manual render script modifications. Developers could add effects to a stack, with Defold handling the underlying render targets.
Preview & Debugging Tools
An editor panel for testing and adjusting post effects in real time would make iteration faster and more artist-friendly.
Closing Thoughts
Defold’s shader and rendering system is powerful, but its current workflow can feel more complicated than it needs to be. By introducing simpler ways to assign shaders, providing starter templates, and improving the usability of post-processing effects, Defold could make shader development more welcoming—while still preserving the flexibility that advanced users value.
Unify Game Object and Collection Concepts
Rethinking Defold’s Collection Concept
One of Defold’s most confusing aspects for newcomers is the difference between game objects (go) and collections. While collections are powerful for structuring a project and instantiating groups of objects, they also create extra mental overhead. Beginners often wonder: Why can’t a game object just contain other game objects?
Imagine if Defold allowed nested game objects, where a single go could serve as both a standalone entity and a container for other gos. In practice, this would remove the need for collections in most simple cases. For example:
Instead of creating a collection for a player that contains the player object, weapon, and effects, you could simply have a Player go that directly holds its child objects.
Prefabs could be represented as reusable game objects with children, instead of requiring an entirely different “collection” asset type.
Benefits of This Approach
Reduced Cognitive Load
New developers wouldn’t have to learn two different systems (“game object” vs “collection”). Everything is just a game object, and objects can contain children naturally.
Simpler Workflow
Instantiating and organizing objects would feel more direct. A developer could drag and drop children into a parent go without having to wrap them in a collection first.
Prefab-Like Behavior
Nested game objects would function like prefabs in Unity or Godot scenes—self-contained hierarchies of objects that can be reused anywhere in the game.
Cleaner Code
Instead of spawning collections for relatively simple entities, scripts could work with a unified API that handles both individual objects and hierarchies.
Possible Implementation
Game Object as a Container: Extend the go definition to allow an embedded hierarchy.
Unified Instantiation: factory.create() could spawn both simple objects and nested structures transparently.
Optional Collections: Keep collections for advanced use cases (large levels, modular loading), but remove the requirement to use them for everyday entities.
By allowing game objects to embed other game objects, Defold would drastically reduce the mental friction around collections. Collections would still remain valuable for scene organization and streaming large levels, but beginners could focus on a single, intuitive concept: everything is a game object, and objects can contain other objects.
Merge Game Object and GUI APIs
The current duplication of APIs for go and gui is redundant and confusing. A single unified API would make development more consistent and easier to learn, without forcing developers to constantly switch between two nearly identical systems.
I’ve submitted my responses in the form, but I’d also like to mention an issue that I know was discussed at length, for which I can’t find the GitHub issue (maybe it was only discussed in this forum?):
When you have GOs in the Assets section of the editor (i.e., prefabs) and instantiate them in the Outline, trying to change the instances’ properties in the editor will change the properties of the original prefab. Would be nice if the instances were copies so that this didn’t happen.
From my experience with Defold, the idea of game objects and collections is perfectly clear, reasonable, and reflects Defold’s concept of maximizing engine performance. It’s quite convenient to work with. Those who find it unclear or inconvenient, as I’ve noticed, are simply trying to adopt their experience from other engines.
There is one issue that I constantly stumble upon, forgetting that this should not be done:
In my opinion the concept of Collections and Game Objects should not be changed. As it is now, they both serve 2 different solutions. Former is for grouping game objects, and latter is for grouping components. I think it would complicate things when you start having nested game objects. Initially, this may sound intuitive, but for complex scenes the hierarchy imposed by Collections and Game Objects will be a life saver!
Being able to specify the rendering order of GUI nodes and Game Objects within the same layer groups will make life so much easier.
I think it should still be possible to make the initial approach for people simply looking to add a shader effect less painful and maintain the full control experienced user need.
This is a constant discussion point when approaching Defold and it’s not only for shaders. Think about stencil masks, camera units (although this is better now) and of course post effects.
Since there are templates for the editor already available, I don’t see why a more beginner friendly and complete render script and other elements like materials, etc shouldn’t be provided together with a minimalistic one for power users.
Regarding Collections and Game Objects, I believe that everything is acceptable in its current form, but only as long as you have planned your project well. As soon as it becomes clear that you need to expand the prototype of a simple Game Object with something else, you need to replace it with a Collection, then replace the factory type, and finally, the code that calls this factory, and then check all the places where the ID of the generated object is used. This is not a quick process.
Editor scripts can create a resource from a template.
Adding the ability to create a template from a resource and translate a resource format, would result in a translation route, but it could get quite messy.
Given protobuf_to_lua() and lua_to_ protobuf() functions you could possibly front-end the whole outline tree in Lua, and do very interesting things.
In what way exactly? Because something tells me that they are designed this way for a reason. I’m still fairly new to the engine but I’ve learned that with Defold there must be something happening ‘behind the scenes‘ for better performance/resource management.
The design of Defold’s render pipeline does show some significant limitations in terms of flexibility. The render script is the only core part of the engine that developers must manually replace when they need to extend rendering features. For example, if you want to use an orthographic camera, implement lighting simulations, add post-processing effects, or use other rendering-related extensions, in almost all cases you are required to fully replace the render_script.
This creates a practical issue: different extensions are rarely compatible with one another, and developers often need to manually merge and modify code, carefully testing to avoid breaking something in the process. For beginners, this becomes a major barrier. Most new developers don’t even fully understand how the render pipeline works, yet they are asked to directly edit or replace its core script. For more experienced developers, it still means extra time is required whenever introducing a new extension—comparing, merging, and carefully managing different versions of the render script. In many ways, working with Defold’s render pipeline feels like trying to manage multiple branches of code without a version control system, relying solely on copy-and-paste—tedious and error-prone.
I completely understand Defold’s philosophy of prioritizing performance, minimalism, and transparency, and this philosophy is one of the engine’s strengths. However, I believe that adding a few basic extension points—such as hooks, callback functions, or even optional condition checks—would not cause any measurable performance loss, yet would greatly improve usability and extensibility. For a game engine still actively evolving in 2025, developer experience and extensibility are just as important as raw performance.
I haven’t read through the engine’s source code in detail, but from what I understand, both go and gui operations require passing in an ID. I believe the engine internally should be able to determine whether a given ID belongs to a GUI node or a game object. If that distinction were handled inside the engine, then the upper-level API could be unified—developers would not need to worry about whether they are calling a go or gui function. Of course, this might add a very small amount of overhead due to the extra checks, but it could also significantly reduce the cognitive load for developers.
My main thought here is that go and gui expose almost identical sets of API methods. From a high-level perspective, I wonder whether maintaining two nearly redundant interfaces inside the engine is necessary. Would it make sense to consider refactoring them into a single unified API? Or is the internal implementation between go and gui so fundamentally different that merging them would not be practical? This is something I don’t have enough insight into, so I can’t make a definitive judgment.
If there are strong reasons behind this separation, I fully trust the engine team’s decision. I’m simply raising this from the perspective of high-level API design, which may not capture the full technical picture.
I see a lot of discussion in this thread. I don’t mind the discussions, but if someone provides their feedback here instead of via the survey form we will not take it into consideration when reviewing the results.
I submitted them via the form, but here’s my attempt to bump visibility on what are, in my opinion, 7 of the sharpest pain-points of defold, in terms of how limiting they are for building things and how difficult they are to work around:
Get actual world position: https://github.com/defold/defold/issues/7902
Since you can’t trust defold’s get_world_position fn, you’ve gotta do a bunch of math when you need to know where something actually is
Instancing: https://github.com/defold/defold/issues/3908
I was super excited to see that little blue dot appear when I started making local-instance edits to things. Little did I know, that was a lie and none of that data gets saved anywhere or used! The workaround here is writing a bunch of initialization code for any object you’re going to instance.
Crashing on raycasting: https://github.com/defold/defold/issues/10312
Even when I check the coords before passing them in, this happens sometimes. It’s just a hard crash, too. My workaround has been to wrap all raycast code and to use double the minimum scale.
String properties: Add support for string values to go.property · Issue #8420 · defold/defold · GitHub
Hashes are great but sometimes you need strings. A simple example is setting a character’s name via a GO property. A harder example is integrating with an Ink project. The workaround for this is nuts: write a file that stores every string you use anywhere. Then build a lookup module that hashes each one of the strings and compares its hash to the hash of a GO property to recover the string.
Yep my “not sure it fits into defold” one is type safety. Working in a typed language all day then coming to Lua where I can’t confidently / automatically refactor is strange. I’ll make a local change that I expect to light up a checklist of things that need to respond to it but… nope just runtime errors.
Perhaps the closest concrete match would be first class support for teal?
Basically, the screen and world coordinates are so different (particularly when Zoom enter the fray) is a pain in the most intelligent part of me.
The fact trying to make an object stuck on the same Screen coordinate when the camera pan and zoom (and sometimes simply zoom) is so hard, with elements following the camera THEN jumping back (moving an object is VISIBLY slower than moving the camera), and sometimes even disapearing at some zoom level for reason of their own is horrible.
And you can’t replace it with Gui because Gui and Go communicate very badly (why ? Is there any reason for Gui and Go to not be able to Set and Get each other ?), and you can’t make Collision shapes in Gui (why ? It’s litteraly the simplest mean to make cascading UI).
There has to be a reason why dev refuse to make Screen and World have simple “World_to_Screen“ and “Screen_to_World” function. If that’s a coding problem, why not simply say it and let the community try to help you to resolve it ?
A mean to have an Object at fixed coordinate and zoom (as if it was simply attached to the Camera Object…) would help much : We could then make complex UI made of sprites with all the possibilities of the Game Objects (like Collisions). I’m trying that actually, but Defold is SO SLOW at moving my “UI object” when I move/zoom the camera…
And it’s so complicated it’s always buggy…
For example : I’m building an UI with Objects. That part is no problem. Objects works like a dream if you read the trigger in the good order in the script).
But The UI only appears if you click on some other object (As intended) with enable/disable.
With the camera in ortho mode, I have to take into account not only the world position, but the zoom for the UI appears and keep its “apparent” screen position with the good zoom level.
It’s laggy, but it’s work.
BUT : If I zoom past some point BEFORE (and only before) I enable the UI, some elements of the UI simply don’t show anymore. Ever. whatever I do after that.
I mean, come on ! It’s so complicated !
Please, of please, make at least ONE the those works :
GUI and GO can fully communicate by GET/SET (and functions like that).
Let us attach objects to the camera so some objects are ALWAYS at the same position and zoom level
Let us put some “fixed screen position/zoom” as stats for objects.
Let us simply just attach a second camera to an object, and the two images are just in front of each other
If GUI could use collision objects, it could be cool.
