Home > Net >  How is the Godot Engine itself structured?
How is the Godot Engine itself structured?

Time:11-04

I'm looking into making some changes within the source code of the engine
so I looked at the source code on github but I'm absolutely clueless to how it's actually made up.

and on the web I couldn't find anything on how the engine itself is made, only what it can do.

Several questions come to mind:

  1. Where does the main script start from? is it from the Main::setup()?

  2. What would be the flowchart of how the engine operates?

  3. How is the engine UI built? (from a web dev point of view, what is the equivalent HTML for it?)

I'm no advance expert in c so even a general abstracted overview would be really helpful to get started

CodePudding user response:

Godot build is orchestrated from python using SCons as you can read in the documentation Introduction to the buildsystem. It is different for each platform (e.g. you need the JDK for Android).

As you are aware, you can find the Godot source code on github. Before going further I need to point out that at the time of writing the master branch of the repository corresponds to the development builds of Godot 4. You might want to change to a different branch depending on the version you want to work on.

Disclaimer: I'm more familiar with Godot 3 code base.

Now, not only the build process different for each platform, also are the API bindings, and the entry point. You want to see inside the platform folder for operating system specific code.

For example, the entry point for Windows can be found in godot_windows.cpp and it looks like this:

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) {
    godot_hinstance = hInstance;
    return main(0, nullptr);
}

You can follow the logic from there, you will find that ultimately they do some initialization and call the methods setup and start of the Main class. You can find the Main class in the aptly named main folder. Afterwards the platform specific code will enter its main loop, and after it finished it will call the method cleanup of the Main class, and then release any platform specific stuff.

By the way, when I say a class is in a folder, I mean there are both the .cpp and .h files.

The main loop might do other things, but it must call the iteration method of the Main class. You can see the code computes time, calls into different "servers", dispatches input among other things.


We don't a flowchart. Sadly we have to piece together the overarching processes. For example, I've written about what happens when you instance an scene elsewhere. I did also look into queue_free which you can find elsewhere.

I'll talk a little further about the main loop below. But first I want to point you to the the diagrams we do have:


Now, the more familiar part of the main loop is that there must be an instance of the MainLoop class. It defines initialization and finalization methods, and also methods to be called on each iteration of the main loop. By default it will be an instance of the SceneTree class (which extends the MainLoop class), but you can change that in project settings. You can find the MainLoop class in the core/os folder and the SceneTree class in the scene/main folder.

The SceneTree class has the means to propagate calls of _process and _physics_process on the… scene tree, among other things. The SceneTree has a root object of type Viewport (in Godot 4 it is a Window, which is a type of Viewport). And, as you know, Viewport is a type of Node, and can have children. The children of the root are the autoloads, the current scene, and whatever else you put there… Thus from there down it is Nodes which I expect you to be more familiar with.

On the other side you have sigletons (actual signletons, not autoloads) including the "servers" and some other static utility classes. If you recall Godot has different rendering backends, which are all behind the façade of a "server" (the VisualServer in Godot 3, the RenderingServer in Godot 4). In Godot 3 we had a choice of GLES2 and GLES3 for rendering backend. And the backends also require bindings which you can find back again in the platform folder.

Here is where my familiarity with Godot source code runs out: I don't know how the shader pipeline works.

The UI? Just like everything else, it is rendered with whatever rendering backend is being used. On the web? It will be on a Canvas HTML element (on a WebGL context). The HTML? The HTML code of the web build template is configurable too (The Custom HTML shell option on the build export settings) see Custom HTML page for Web export. The build process for the web? it uses Emscripten (to webassembly). No, there is no Node.js stuff in Godot, just to be clear.


As per making changes, you probably can work on the relevant class. For example if you want to work on the AnimationPlayer you can find it on the scene/animation folder and make your changes there without much worry about how the rest of the engine works.

To build the engine, as I said at the start you need SCons. Please see Compiling and follow the steps for your platform from the documentation.

And about getting your changes merged into Godot, you want to start with an issue or a proposal (written by you, or somebody else). Followed by a pull request. Please refer to Contributing for the overall process and guidelines to get your changes merged into Godot.

Finally if you are having trouble modifying the engine, you can try the Godot Contributors Chat.

  • Related