GDExtension is more important than Godot -- change my mind

General
1

I’m an indie dev currently building an RTS in Unity — ant colony simulation, thousands of units, pheromone systems, custom pathfinding, the works. I’ve had to build half my core systems from scratch because the engine wasn’t designed for my genre. I spent the weekend tinkering with Godot, and it got me thinking.

Right now every major engine ships as a monolith. You get everything whether you need it or not, and most of it assumes you’re making a third-person action game. Making an RTS? A city builder? A sim? You’re fighting the engine’s assumptions from day one.

GDExtension changes that equation entirely. Imagine Godot’s future as a lean core — scene tree, input, windowing, the extension API — and everything else is opt-in. Physics, navigation, AI, rendering features — all swappable modules maintained by people who actually care about those specific problems.

The implications are wild. You’re building an RTS? Pull in a flow-field pathfinding module, a spatial partitioning module, a fog of war module — all built by devs who live and breathe that genre. FPS devs pull in a completely different set. The engine stops trying to be decent at everything and instead enables a community that’s excellent at specifics.

This is basically the trajectory that made Linux win. Lean kernel, massive ecosystem on top. npm mattering more than Node. The platform becomes the API, and the value lives in the modules.

I know GDExtension isn’t fully there yet — most core systems are still baked in and the current use is mostly third-party addons. But the architecture points in this direction. The question is whether the community and the Godot Foundation are about things this way. I’m genuinely curious about the current climate.

What are the barriers? What would it take to start moving core systems into official GDExtensions? Am I crazy or does this feel like Godot’s actual competitive advantage over Unity and Unreal — not being a better monolith, but being a different category entirely? Also pardon me if this is the current conversation around GDExtension, I’m new here– Cheers!

1 Like
2

Sounds like you’d want SDL2/3 or Raylib. A C library for input, window management, and some 2D rendering. If you aren’t using the engine’s physics, rendering, and/or level editor it may not be worth it, try out a framework instead.

1 Like
3

Hey thanks for the reply – Not quite what I’m getting at though, I’m not looking to drop down to a framework. Godot’s editor, scene tree, and tooling are the value. The argument is that the systems plugging into that core — physics, navigation, AI, etc — should be opt-in modules via GDExtension rather than baked in. You’d still have a full engine experience, just one where devs can swap and compose the pieces that matter for their genre. Less “use SDL” and more "what if Godot’s core was the platform and GDExtension was the ecosystem.

4

It kind of works like that now. You can, in fact, explicitly remove bits you don’t need when compiling if you want to make a super-small version.

I remove a bunch of stuff when I do my builds, for example.

4 Likes
5

I guess that’s already very possible. You can build a release template for your project with very specific components enabled or disabled. Check out “Project > Tools > Engine Compilation Configuration Editor”, this will create a compilation target based on what you’ve used in your project, you can then build the engine with only those features. Down to specific nodes, not just systems.

From a new user standpoint it would be annoying to have to find and weight different plugins. This is certainly the case with Unity’s multiple Input systems and Particles systems, thousands of posts on which to choose for what and why. Sensible defaults should also streamline development, focused on maintaining only one version of this and that.

What you ask for is an advanced feature, it is hidden behind advanced techniques, but it does exist.

5 Likes
6

image
image1392×1666 153 KB

It even makes it pretty easy to remove features, and can even autodetect what’s in use.

2 Likes
7

As said by others, this is already how Godot works. All those libraries are already maintained by people who care. And those people come and go, but the project remains alive. Things that are not supported by the engine are supported by the greater Godot community through plugins/addons.

Now let’s compare the Linux community to the Godot community. In the beginning, the Linux community was all software developers who had a deep knowledge of software and hardware architecture, as well as the ability to program in C++ and Assembly Language. The Godot community is mostly hobbyists with a very few being experienced developers with the requisite skills to add to the core (and even less of those actually contributing). The people who add to the core typically are cherry-picking what interests them, and may or may not be learning C++ to make their changes. Which is why we get a lot of GDScript plugins. Those live as long as the maintainers keep them up. Typically those are one-person projects that are supported by contributors, but kept alive by that one person.

What you suggest would be nice for more experienced developers, but it would push away the hobbyists that are putting Godot on the map. As stated before, you can strip out anything you want from the engine to achieve what you want.

4 Likes
8

oh cool, pardon my ignorance I was excited by the prospect but didn’t know you could do that now. To what extent can you strip core parts out? can you swap the renderer, etc? I suppose what I’d then riff of that would be on first install, you select the components you want and that first compile is the custom engine you’re after, which could later be reconfigured via something like a package manager that ties bits in through GDExension. Sort of like GD’s own NuGet.

1 Like
9

Yeah that’s true, even just getting stuck on URP vs HDRP. Good point yeah, there’s a lot to consider.

10

Good stuff! I guess I got the answer I was looking for, eh!

1 Like
11

To the point where it’s no longer functional. Take a look at the docs here: Optimizing a build for size — Godot Engine (stable) documentation in English

Then check out the blog entry @popcar2 did on this that really shows how much you can shrink it and what that looks like: How to Minify Godot's Build Size (93MB -> 6.4MB exe) | Popcar's Blog

For changing the physics engine, you can currently use Jolt, which as of Godot 4.6 is now the default 3D engine. You can also use Rapier as either a 2D or 3D engine.

For changing rendering, take a look at Project → Project Settings → Rendering → Rendering Device. You can make choices per OS for supported rendering methods. And if you wanted to add your own, you could.

image
image1192×727 70.8 KB

2 Likes
12

Uh, is there a Rapier implementation for Godot available or are you just pointing at the possibility? I wanted to give it a test a few months back but lack the experience in Rust.

1 Like
13

Yes. Sorry, probably should have linked to it directly. Just FYI, I have used it and it drops a dll that cannot be incorporated into the pck. It caused us some issues with the iPhone build.

2 Likes