Enable users to create GUI-only optimized builds for web and mobile

[willnationsdev]

Bugsquad edit: Depends on #1653

Describe the project you are working on:
Building a mobile application.

Describe the problem or limitation you are having in your project:
I wanted to use Godot to build a mobile app since it's a great customizable tool with a strong community and a plethora of built-in UI tools that can deploy to multiple platforms. However, Godot also has a variety of built-in systems for game development that aren't really necessary for a GUI-only app (even if it were a GUI-only game, of which there are many possibilities). And if you are developing for mobile or web, you want the smallest possible size binary.

I believe there should be additional build options, just like disable_3d and disable_advanced_gui that are tailor-made for GUI-only mobile/web apps. The only thing I can specifically think of to add would be a disable_physics option, perhaps with a dummy server implementation. But if anyone can think of other things, then that would be great. I already know that a lot of unnecessary features can be stripped out via the module_<name>_enabled=no option.

Describe how this feature / enhancement will help you overcome this problem or limitation:

It would help minimize binary sizes for mobile/web platforms when you want to build a GUI-only Godot project.

Show a mock up screenshots/video or a flow diagram explaining how your proposal will work:

I want to be able to do this:

scons p=windows disable_3d=yes disable_physics=yes disable_other_stuff=yes module_X_enabled=no... -j6

Describe implementation detail for your proposal (in code), if possible:

1. Add the implementation of the additional options to the SConstruct script.
2. Add C++ macros for conditionally building any relevant code that can be stripped out.
   1. In the case of physics, we'd need a dummy PhysicsServer implementation so as not to break code everywhere that is referencing it. It would also remove all nodes in the scene directory that are related to collision detection and physics. Maybe also remove the PhysicsServer global variable / core bind?

If this enhancement will not be used often, can it be worked around with a few lines of script?:

It is related to engine builds, not script code.

Is there a reason why this should be core and not an add-on in the asset library?:

It is related to engine builds, not script code.

[Calinou]

We should also look at providing SCons options to only compile a single renderer into the binary. When developing a GUI app, you most likely want GLES2 to be available but you don't care about GLES3 or Vulkan. This can reduce the binary size by several hundred kilobytes.

See also godotengine/godot#21992, where WebGL 2.0 support was removed from the HTML5 export template (but this wasn't merged).

[willnationsdev]

So then, would you recommend separate options for removing individual renderers, one at a time? That would sound good to me. Like disable_renderer_gles3=yes.

[Calinou]

@willnationsdev It probably makes sense to have a single renderer flag instead, like renderer=gles2 or renderer=gles3 (renderer=all would be the default). You can't disable both of them at the same time, so having two flags wouldn't make sense.

[golddotasksquestions]

Would it be possible to also do this on exporting the project instead of just when compiling Godot?
Because I would also like to create stripped down apps that does not need physics or 3D rendering for instance.

[Calinou]

@golddotasksquestions Doing this directly in the export process sounds quite complicated, as you have to make sure the user has a development toolchain installed, while also downloading the Godot source code and building it.

We technically have something similar for Android export templates, but only the Java part is compiled. In this case, it's much easier to install dependencies (even Gradle will install itself using a wrapper if you don't have it locally).

[golddotasksquestions]

@Calinou Unfortunately I did not understand much if anything of what you wrote. That's my lack of knowledge in these areas, though.
My thinking was just that (taking the Windows export as an example), there is the executable which is basically the Godot editor if I am not mistaken, and the pck file, which is all my projects data.
When I press "export", does Godot just make a copy of itself for the executable? Because if it builds this file, when I press "export", could it not build the executable with less features? Sorry for the nativity of my question.

[willnationsdev]

No, what you do is download an "export template" which is really just a production optimized build of the engine with no editor tools built in. It copies the export template (more or less). It does not actually build the engine. To build the engine, you need to have compilers installed, Python, the scons build tool, and a plethora of build scripts, none of which would be present in the binary file in the tools-enabled version of Godot that the editor runs on.

In order to compile the engine on the fly with more or less sections in the core engine, you would need the target platform to have the same set of tools that developers install on their desktops in order to build the engine source code. And having that expectation severely limits where you could install your project since no platform but the most heavily customized ones would have those kinds of things installed by default.

So the short answer is, no, you can't really do that.

[aaronfranke]

Building on this, I would like to see a disable_2d option, which disables all Node2D-descendant nodes. You could, for example, only have disable_2d=yes for a 3D-only game with GUI elements, or have disable_2d=yes disable_3d=yes options for a GUI-only build.

EDIT: Also, while we're at it, it might be better to refactor these options into enable_3d=no etc, or maybe allow_3d=no or use_3d=no, and have them default to yes instead of no. This would help avoid double negatives and would make it more consistent with module_X_enabled.

[willnationsdev]

@aaronfranke I think, to match the convention of the module stuff, I would use 3d_enabled=no, advanced_gui_enabled=no, physics_enabled=no, etc.

[aaronfranke]

@willnationsdev On second thought, 3d_enabled=no would not be valid because 3 is not ID_Start. In core the define is currently _3D_DISABLED because 3D_DISABLED is not valid. The leading underscore actually violates the C standard for preprocessor define names as pointed out by @marstaik on IRC.

[willnationsdev]

@aaronfranke Maybe do render3d_enabled=no instead?

[shafnaz]

Any progress or goals so far to make this real?

Godot Engine allows you to prototype faster than other game engines. Using this to provide the freedom to build apps sounds like a great idea.

[aaronfranke]

@shafnaz I have several PRs that work on this, the first of which moves 2D and 3D resources to their own folders. This has been discussed in a PR meeting but the core devs don't want to merge it yet because they want to do a big redesign of the folder structure of Godot, so in the meantime no progress is allowed to be made.

[shafnaz]

Looking forward to an amazing future!

[shafnaz]

Any updates on this feature?

[aaronfranke]

@shafnaz The status has not changed much in 2 years, I still have PRs open that need to be reviewed. However I did open this smaller PR which can be reviewed and merged first godotengine/godot#66744

EDIT: Split it up even further to make it easier to review: godotengine/godot#79183 and godotengine/godot#79185. Reviews are very much appreciated.