Defold Engine Design Questions

Questions
#1

Hi friends,

I’d like to learn more about the design decisions that have gone into building Defold so that I can better employ them while using the engine. I have built a few small projects with Defold and am familiar with the core concepts and features, and would like to know more of the “why” (as opposed to “how to”).

Please note that the following questions come from a place of curiosity, rather than critique:

  • One of Defold’s features is its minimalism, offering lower level building blocks to avoid engine bloat. Why is some functionality provided out-of-the-box, rather than others? E.g., why are things like colliders included, but not primitive shapes?

  • Along those lines, how have other higher-level systems been determined to be extraneous to the core engine and editor, such as GUI development? Assets like Defold-Input and Gooey seem like they would be central to a broad swath of game types, but clearly a calculus has been made that they are better served as asset dependencies.

  • Why is Lua chosen as the scripting language of choice, to the exclusion of others? I recognize that it’s an industry standard and lines up neatly with the C API. But, why select it over something like JS (for similar overhead), C# (for industry popularity, even if it has a heavier footprint), or in lieu of multiple scripting options?

  • What kind of decisions were made that led to the low level APIs becoming available through Native Extensions, rather than directly through the normal workflow? (I suppose this question is similar to the previous one: why not just provide for direct C/C++ access in addition to Lua scripting?)

  • The focus on message passing, rather than drawing upon OOP concepts such as inheritance and member functions, is a clear directional choice, perhaps to benefit from decoupling and allowing game objects to be discrete in their relationships to one another (it reminds me a bit of ECS). I’d love to know more about why this approach was chosen.

Thanks for any insight! I feel like if I know why a fork is shaped the way that it is, I’ll be less likely to try to use it as a spoon. :slight_smile:

7 Likes
#2

By primitive shapes I suppose you mean drawing primitive shapes? Being able to simulate 2D and 3D physics is very important in many games. Defold would in most cases not be a complete engine without it. BUT at the time, we had no extension system, so the decision was made to include Box2D and Bullet in the engine. Now, many years later, it is possible to exclude the physics engine from the binary if it is not included, thus reducing the binary size.

If you look at APIs for high level gui components such as lists, buttons and so on, you find that most APIs are very opinionated. Some people like GUI framework X, while others prefer Y. We do not want to force a certain style of GUI design onto our users and instead we decided to provide only the very very basic building blocks. Was it a good decision? Maybe. There are some great Defold specific frameworks out there, with Druid being the most advanced. There is also a Dear ImGUI extension, and several other alternatives.

The fact that these things are extensions is not necessarily a bad thing, but I do think we could make a better job of promoting them.

For us, size is everything. And Lua is tiny compared to JS or C# or anything else. And LuaJIT delivers great performance. And the interop with C is great.

I’m not sure I follow. We have an internal/private C API for the engine. Selected parts of this API is exposed through Lua. Later on, when we introduced native extensions, we also started to move some of the private C APIs to public headers available to native extensions. We’ll continue to expand on the public C API, but it is unlikely that the C API will ever have feature parity with the Lua API.

Correct. This is a very conscious choice. My personal opinion is that OOP should be kept as far from game development as possible. It adds a lot of overhead and complexity for very little gain (if any!). We believe in a data centric approach with systems operating on the data to produce a new state, rather than complex hierarchies of objects with the data spread out among the objects of the system. This is in many ways similar to ECS, and it is also what you find in the engine code if you study it closely.

I think @JCash and others in the team can provide even deeper insights into some of the design decisions.

17 Likes
#3

This is so wonderful, @britzl. Thank you so much for these great insights!

1 Like
#4

If you don’t mind , could I also ask few questions ?

It’s only been two months since I’ve known Defold and I’m impressed with its approach of making games.

I am very new in game dev and programming and my first Engine is Godot.

So the first question that arises is related to the size of the engine. Is it possible to separate that Exporting part from engine binaries and offer it separately than in single bundle ? Just like Godot is doing ?

It would decrease a lots of size won’t it ?

And I assume this size may be the reason people did not like monthly updates in engine.

And my second question is, If I want to Extend Engine’s functionalities via Extensions or assets then would they hinder Engine and Games’s performance ? (Happens in Godot due to a badly coded plugin and bugs).

My third and last question is, Different users prefer different programming languages and It always varies.

But what if Lua alone is not efficient for Performance ( I know that in 2D this problem will almost never come but even then) Can I use C++ directly to overcome this nag or I would have to do some other stuff ( IDK Yet) ?

Thank you very much ! :smiley:

#5

You mean the size of the Defold editor downloaded from here: Download Defold? The reason that I’m asking is that when you write “engine” I mainly think of the the runtime part which gets installed with your game content. Anyway, yes, the editor and tools would decrease in size if we didn’t have to package the bundlers for each platform and instead let users download the bundlers as plugins. It would also to some extent complicate things and it is not something we plan to do at the moment.

That is of course a risk, but such a thing would quickly be spotted by the users and hopefully the extension author would then address the performance issues and fix them. The extension system itself is designed to be performant, but there is always a little bit of overhead each time you call from Lua into native code. If you call your extension code thousands of times per frame it will be noticeable.

It doesn’t really have anything to do with if your game is 2D or 3D. I don’t see any problems with using Lua for game logic in a 3D game. The engine is still written in C++ and will give you enough performance regardless if it is 2D or 3D. But yes, if you end up in a situation where you can’t get enough performance from Lua, then sure, move that piece of performance critical code to an extension and use C++ instead!

6 Likes
#6

I think @Alex_8BitSkull used native extension for raycasts or AABB in Void Scrappers - and I think VS is a great benchmark with thousands of enemies on screen, so I think this is not that much of an issue actually :grin:

As @britzl mentioned above, it’s not necessary, but you have an option to write your game in C++ as a native extension - for this check out what @sergey.lerg is doing - making a whole game in C++ in Defold (but he is generally a magician and uses also Lua for game data and Godot for some other magic :sweat_smile:)

Related:

6 Likes