We started working on a Defold manual targeted for people that have prior experience in Unity. The first version is drafted on a branch:
And a preview is available here:
It was revised with few people with Unity experience, but we’re still looking for a feedback and input, especially from users who were using Unity a lot in the past and switched to Defold:
what were the main pain points?
what had to be changed regarding “mental model”, regarding how to approach gamedev?
what similarities and differences you spot?
And so on, any feedback will be very appreciated and useful to make the friction weaker!
It is still a little bit long, so we plan to make it also more concise somehow, so it’s also important to us, to know, which topics to focus on to explain properly, so a perspective of Unity users will help do so
I have limited experience with Unity, but some experience talking to Unity developers. I’ve noticed that many of them, when trying Defold, treat scripts as if they were MonoBehaviours - and as a result, they often misuse them. They tend to attach a script to every object, exchange countless messages between scripts, avoid using Lua modules, and eventually turn even a simple game into a spaghetti mess of thousands of messages. I’m pretty sure that almost every Unity-to-Defold developer falls into this trap.
So, it might be worth adding a “Caveats” section or at least including a note in the documentation about scripts, explaining this key difference from Unity. In Defold, scripts should be viewed as managers or systems rather than per-object components. A single script should control thousands of game objects that don’t have scripts of their own. Creating a separate script for each object is a mistake. In a well-architected project, you’ll usually have no more than a handful (around ten) of scripts. Messages in Defold scripts are mostly used to handle events from built-in components and to send data to the GUI.
I did something similar the first time I tried the engine, and honestly I still struggle a bit to find the best architecture for my small games. Are there any articles or videos that discuss high level game architecture in Defold?
One that I was hearing on the other site are problems understanding why there are no Sorting Layers, and it was hard to explain that it is somehow in GUI only, but in game objects’ world sorting layers would be maybe “tags”? But this is not optimal in Defold as it breaks batching, and that is totally different level to explain it to users, that expect Sorting Layers usage like in Unity.
Do you have similar experience? How to explain the “Defold way” for this topic?
I think it would be useful to mention Lua modules. Maybe in the messaging section.
‘no cross-object method calls between scripts’ maybe Lua modules can kind-of do this?
Although I am guessing at what it means. I no nothing about Unity so I am not the target audience; so no worries.
I would add that this particular aspect of the approach is also encountered by those who are just starting to familiarize themselves with the Defold game engine. When I was studying the official documentation and examples on the website, I got the impression that the main emphasis is on using a separate script for each object, active message passing between scripts, and relatively infrequent use of Lua modules, which can ultimately lead to a noticeable complication of the structure even in simple projects. At the same time, I had no experience working with other game engines, except for game constructors.
One expert once noted: “This is not a problem with the engine or the official documentation. It’s more about those who are not yet familiar with architectural approaches, and the task of the official documentation is to explain the tools, not to teach programming.”
Я добавлю, что с этой особенностью подхода сталкиваются и те, кто только начинает знакомиться с игровым движком Defold. Когда я изучал официальную документацию и примеры на сайте, у меня сложилось впечатление, что основной акцент делается на использовании отдельного скрипта для каждого объекта, активном обмене сообщениями между скриптами и сравнительно редком применении Lua‑модулей, что в итоге может приводить к заметному усложнению структуры даже простых проектов. При этом у меня не было опыта работы с другими игровыми движками, кроме конструкторов.
Один из экспертов однажды отметил: «Это не проблема движка или официальной документации. Речь скорее о тех, кто ещё не знаком с архитектурными подходами, а задача официальной документации — объяснять инструменты, а не обучать программированию».
I totally agree with that! Defold is not my first game engine, and I have experience in programming, but having some big picture on how “the pros” would organise and use the engine in a middle to big project that scales would be a precious adition to the documentation. It will help new comer to tackle the engine and apply best practice from start, and it will help and motivate users of other game engines (like Unity) to use Defold because “look, in Defold you can just code OOP like any other engine, but just organise things like this it will work awesome in the long term”.
Thank you very much for your help, we took your comments and added appropriate paragraphs, Bjorn also prepared a “central management” version of the spawning example, that is linked in the manual too:
