I have a follow-up post here
This is a continuation of my post on general game engines and frameworks.
After having moved away from Godot due to issues I’ve detailed elsewhere, Defold seemed like a good choice. More than a month in, and pretty much all of the issues I had with Godot are nonexistent. While it lacks features available elsewhere, those it does have are extremely stable. It also has a massive amount of official integrations.
Issues
Before going ahead, let me get what I don’t like out of the way.
Defold’s editor isn’t made with the Defold engine, but with JavaFX. I think it’s a missed opportunity to dogfood, but Defold doesn’t have the built-in UI system to actually MAKE an editor. I sort of understand, as Defold is supposed to be a framework to make performant games, NOT full-fledged applications.
My major gripe is the use of “magic strings”. It’s very error-prone, and makes it difficult to track what global strings you have.
That’s it. I may have some gripes with usability within the editor (like not being able to search for input keys) but it’s not nearly as bad as some people find it.
Learning / Knowledge Base
- Building blocks of Defold
- Components
- Official Defold Tutorials
- Repo of Defold samples
- Monetization
- Defold Tutorials channel
- Defold for beginners playlist (+ missing part 6)
- Window Callbacks
- Messaging:
#is for the specific script,.is to the script’s owning game object meaning it will go to all components * - There are limits on physics worlds *
Honestly, just follow the samples, and I highly, highly recommend just doing the official tutorials. They are clear and complete enough for getting yourself off the ground. Only once you want to know more complex subjects should you look elsewhere, and honestly most of it won’t be Defold-specific.
It’s also good to look at the official creator spotlight blog posts / interviews:
Scences, Worlds, and Switching Scences
The last (or first) concept is that of Collections. While a Game Object can be seen as a group of Components, a Collection is pretty much just a group of Game Objects. However, you may quickly find that you can only have one scene defined in the bootstrap.
Switching scences is done through a Collection Proxy (example).
Lua
Programming in Lua is a great resource covering the very basics to more advanced topics. Lua is very similar to Javascript as they are both prototype-based.
Some notes:
- nil is the only value that is treated as false (0 and empty strings are thuthy)
- indexes start at 1, or any index you set (I wanna cry)
- ternary operators might as well not exist
- metamethods
- performance tips
Input
- General Manual
- Mouse and Touch (finally, considered to be the same!)
- Extension
- Mouse and touch events sample
- Down duration sample
Note: for text inputs, use something like Druid, because building it all yourself looks tedious [*]
Collision Groups & Masks [*]
Two things that aren’t clear in the docs:
- An entity can have many groups & masks by seperating groups with a comma
- Note that there is a max of 16 layers
Rendering & the 2D Camera System
The system is there, but I find it fucky and not super friendly out-of-the-box. It’s very customizable, and most importantly well documented, so do please read the render pipeline manual. Also, make sure to read the camera manual.
Missing Features
Internationalisation
A very important feature that doesn’t exist in the editor is the ability to translate text. There is an asset that wraps i18n, however this still requires you to set Text nodes’ text property values through scripts.
Physics interpolation
Godot only recently added 2d physics interpolation.
Defold doesn’t really have this, but you can fake it with kinematic physics, update(), and fixed_update().
You can read more in this thread.
Screen to world & other camera helpers
While very easy to do yourself, I don’t know why this isn’t just built into the engine. Check out the sample on how to do it (source).
Lighting
This will require knowledge of shaders. Please read the manual as well as this amazing post. There are also some very good examples: lightning vfx, pixel planets, and animal crossing world bending
For lights in particular, there are the videos below, as well as the 2D lights sample (source), britzl’s post about this sample, and this detailed post on pixel-perfect shadows.
Performance
Defold is highly, highly opinionated, mostly to make it as performant as possible. Unlike many other projects, Defold’s manuals will generally tell you what to do.
Debug mode performance is expectedly bad, but release mode is better than Godot, with a 1/6th of the memory impact. I’ll need to investigate CPU usage differences more thoroughly. Bunnymark is a funny benchmark, able to render 2^15 bunnies, so do check it out.
Size is very important, and the resource manual page covers this very well. Do note that you should use a low amount of atlases *.
Performance - Collections vs Game Objects
Use Game Objects where possible. Collections are scenes / worlds, so use them for that purpose; it isn’t great to use them as a holder for complex Game Objects. You also get performance hits when messaging between all the game objects / components / scripts, so centralize things as much as possible.
Some things to consider from this post:
“game objects are cheap”
Multiple scripts controlling different parts of an entity This could potentially have a bit of negative impact on performance, especially if you have a lot of messages going back and forth between the different scripts on a game object. Also if you have multiple scripts you’ll end up with multiple transitions from engine native code across the boundary to the Lua lifecycle functions. The more you can collect your logic in a single script the better.
Patterns
Please read Game Programming Patterns. Design Patterns are, generally, a good way to solve a common problem with a common solution. While each solution will invariably be similar in each language, framework, or tool, there will invariably be changes to make to appropriate it to the environment. This is particularly important for Defold, as the scripting language, Lua, is prototype-based. While you can emulate classes, do try to use the natural syntax of the language *.
Godot is a good example of pattern appropriation, where a Finite State Machine can be implemented by each state being it’s own node.
I’m going to go over some of the most important design patterns, and how you can appropriate them in Defold.
Object Pooling
Unity is the token child of object pooling [1]. However, do NOT implement this in Defold, unless you are in the native c/c++ side. Defold already does some form of object pooling under the hood (according to Britzl), so doing it yourself on the scripting side is not going to give you any real improvements.
Command
Command is a vague pattern for what can be seen as messaging. It is also a very important for lua as well *. GDQuest has a good overview of it for use in games.
State
State patterns like FSMs are probably the most prevailent pattern. There are some minor things to consider when using it in defold *.
Data Driven Design / Data Oriented Programming
This is probably the most important, watch Nic Barker’s video for a breakdown of why. Some game engines have built-in systems that simplify this pattern. Notably, Unity has Scriptable Objects, and Godot has Custom Resources.
Defold doesn’t have any systems like this, BUT, if you want editor support, you can use go.property.
I think using asset packs with Textures & JSON files is good enough, especially when delivered through Live Update.
However, there are three ways to include resources: compiled-in, compiled custom, & bundled:
 |
|---|
| image comes from this manual |
While there are some tools that allow directly modifying the archive formats, I don’t recommend it. If you want your game to be easily moddable, then you need to consider the modifiability of these approaches:
| Characteristic | Custom Resources | Bundle Resources |
|---|---|---|
| Modify files after bundling | No - files stored inside a binary archive | Yes - files stored on the local file system |
For easy modding support use bundled resources.
Add the paths of your assets (relative to the project root) in game.project -> Project -> Bundle Resources.
Then, the raw files will be available within the build.
This means it should be relatively easy to manage data packs through something like mod.io.
- Resources manual
- Bundle Resource Project Setting
- Working with bundled files manual
- mod.io REST API
- Steamworks Workshop documentation
A possible restriction is Defold-type resources can’t be put here, i.e. Atlases or Collections. This is based on some old posts by Britzl, but recent changes allow runtime generation of resources like Atlases:
What’s left
I’ll be doing more things in the project section of the site about Defold later on as projects progress. However, that’s it for this post, as it’s given a good overview of what I’ve figured out and the most important resources.