The Defold engine team is passionate about their work and a lot of care and craft is put into every line of code that goes into the engine. We care a lot about the quality and performance of the Defold engine and this manifests itself in many different ways:
Memory usage
The engine should be smart about its memory usage and have a small memory footprint, both on disk and when run-time memory is measured. This keeps startup times low, memory sequential and efficiently accessed and install rates high.
As a developer this means that you can tune the pre-allocated memory for various systems via game.project. You can use texture compression to reduce texture size and the app manifest to remove parts of the engine that you don’t use.
CPU usage
The engine shouldn’t do any unnecessary work and the work it does should be done as fast as possible. This keeps your game running smoothly and your battery consumption low. There is still room for improvement here, but we’ve seen from benchmarks done in the past that we’re in a pretty good state when compared to our competitors.
From a game developers point of view this means handing off work to the engine instead of spending time doing it in Lua. It also means to embrace a reactive way of writing code where you run code only as a result of some kind of event, be it user input, animation callbacks or a collision response.
GPU usage
The engine should render graphical components in an efficient way that reduces load on the GPU. This means to batch draw calls, reduce the amount of data and in other ways optimize the work passed to the GPU.
As a developer you are given a lot of control of the OpenGL ES rendering pipeline through the render script and you can control how graphical components are batched together through layers in the gui and through a well defined set of rules on batching.
Stability
The engine should be stable and never crash. This is probably the hardest goal to reach. Bugs still slip through, even though we carefully design every feature we implement, peer review the code, write unit and system tests and test on a multitude of devices both manually and automatically. When you factor in the wide range of hardware and software that Defold is designed to run on it is little surprise that we’re unable to fully live up to our ambition of 100% crash and bug free code.
We use Defold internally here at King and we have live games with tens of millions of installs, but we do not release new versions of these games in sync with the bi-weekly engine releases, which means that we do not get instant feedback on the quality of our releases when “sent out into the wild”. We also do not have any means of getting analytics data from any Defold games released by our community of developers.
We need your crashes!
This means that when it comes to crashes and ANRs we rely on feedback from our developers as much as on the analytics data from our own games. If you have a game live on Apple or Google or on any other system and you collect crash statistics then we would really appreciate if you could share your data with us so that we can improve the quality of the engine. You can send aggregated crash data or crash details in a PM here on the forum (or publicly if you want to be open about it) or directly in an e-mail to me (bjorn.ritzl@king.com) or anyone else in the engine team (@Mathias_Westerdahl, @sven, @jhonny.goransson, @Johan_Beck-Noren or @inactive-vilse)
Many thanks in advance (and spooky halloween coding to you all)!
