Contributing to the Defold Repository

#1

Happy Monday! :cloud_with_rain:

After a few recent conversations in the Discord about the pace and priority system of how features and bugs are handled in the engine and editor, I thought I’d post my thoughts on the matter here so that I can potentially hear from more people.

Although Defold is source-available on GitHub and there is a rather formal process for contributing features or fixing bugs, the repository is just too big and complex for most people to understand where things are located and how the larger project is structured. I know for a fact there are many power users in the Defold community who would like to contribute by adding small editor features, fixing bugs that have existed for years but are low priority, etc. I understand there is a superficial description of the directory hierarchy somewhere in the repository, but it’s not comprehensive nor very helpful beyond the absolute bare basics that most developers could figure out on their own rather quickly. I believe there is potential for the engine and editor to improve more quickly. Some of the more niche and low-priority features and bugs are still important to some people, but these tickets are perhaps years old by now since these aren’t issues that corporate sponsors are asking for or they’re just kind of… yeah, niche issues.

My proposed half-solution to this problem is for the Defold team to create a video, writeup, or maybe a live demonstration, stepping through the repository and explaining the structure of at least a fraction of it. One small example would be to trace a call to go.property() through the engine to see how it actually works and which files it touches. Imagine how much could be learned from a simple demonstration like that. I understand that contributing to a large codebase isn’t out of reach for some developers since they are used to that sort of thing and have ample time to do so, but most developers don’t have that kind of time or experience diving into many-years-old codebases and making changes. In my opinion, this is one of the most difficult ways of programming… it’s tough for people to understand just how much more difficult it is than writing something small from scratch. I call it "grep programming" or "ctrl f programming." :laughing: :sob: I also think this proposed half-solution is quite conscientious of the Defold team’s time, since it would be more than likely a one-time thing instead of an endeavor that needs to be maintained over time.

What do you think? I’m hoping something like this happens so that we can more easily add useful but overlooked things like fixing the extremely zoomed-in default in the editor, adding markdown support for those all-important README.md files, adding an option to increase and decrease the UI size of all elements of the editor instead of just scripts and graphical views, and much more.

14 Likes
Problem with physics.set_shape()
#3

We can’t do anything about the lack of time to contribute. Even if you know every line of the Defold codebase by heart it will take time to make a change. Yes, it will be faster for someone with experience, but still, time is required.

As for experience, it is something you have to acquire. We can’t help with that. What we can do is to help with some additional documentation about the structure of the engine codebase to help people find their way around the source code. We will definitely consider this.

I usually do this exact thing myself to find my way around a codebase. One thing which I find helpful is to start from the scripting layer of the engine, from the entry point of a Lua function if you will. The Lua scripting layer is usually in a file named script_foo.cpp. You find most of them here:

Here are the bindings for the sprite.* namespace:

(this is exactly how it works in most extensions when you set up your Lua bindings into the extension code).

The code in the script layer will read Lua arguments from the stack, do some validation of the data, and then send it to the associated component, using an internal message. Example for sprite.set_hflip():

This is all you need to know about the code if you want to fix a bug in the scripting layer. For instance something like a bug with arguments to one of the Lua API functions of Defold. If you on the other hand need to go one step further and investigate an issue on the component level you need to find the corresponding component code. Component files are named comp_foobar.cpp. You find most of them here:

Here’s the message handler for the Sprite component, which will be the receiver of that internal h-flip message from script_sprite.cpp:

Specifically this part:

Component are where a lot of the engine code is found. The components have a bunch of standard lifecycle functions, such as Create, Update, Render, Destroy:

11 Likes
#4

I’ve also updated the engine documentation with a main page, listing the other documentation concepts. It’s sorted mainly “in order or relevance” for a newcomer to our source code.

I have added an engine life cycle document, and also a engine code structure document (which goes through some of what Björn mentioned above).

I hope that helps a bit.

I have also added Android to the simplified build flow. In essence, you don’t have to deal with local packages or the install_sdk when building the engine. Only exception is HTML5, and we’ll fix that later on as well.

I’ve updated the README_BUILD.md to highlight this, but to iterate it again: our build system will pick up your local install of Visual Studio, XCode or Android studio, and for Linux it will look for clang as before.

11 Likes