this post was submitted on 11 Mar 2025
72 points (100.0% liked)

Godot

6386 readers
121 users here now

Welcome to the programming.dev Godot community!

This is a place where you can discuss about anything relating to the Godot game engine. Feel free to ask questions, post tutorials, show off your godot game, etc.

Make sure to follow the Godot CoC while chatting

We have a matrix room that can be used for chatting with other members of the community here

Links

Other Communities

Rules

We have a four strike system in this community where you get warned the first time you break a rule, then given a week ban, then given a year ban, then a permanent ban. Certain actions may bypass this and go straight to permanent ban if severe enough and done with malicious intent

Wormhole

!roguelikedev@programming.dev

Credits

founded 2 years ago
MODERATORS
 

This was a fun one. Here's my newest post on how to dramatically reduce Godot's build size.

Some sacrifices were made... But the end result is a Godot project that works exactly the same, albeit with slightly worse performance. Hope this can help others in achieving tiny build sizes!

top 10 comments
sorted by: hot top controversial new old
[–] jlothamer@programming.dev 1 points 7 hours ago

Very interesting. I was thinking about doing this, but went the Defold route instead. Defold is much smaller out of the box than even these results, but the sacrifices in functionality are pretty severe and the editor and engine are, shall I say, cantankerous. I may have to circle back to trying this at some point for my web games. Thanks for the post!

[–] Kelly@programming.dev 7 points 16 hours ago (1 children)

Some sacrifices were made... But the end result is a Godot project that works exactly the same, albeit with slightly worse performance.

The write up has lots of hard numbers for the executable size but only describes the performance impact in general terms.

It would be good to see some before and after performance numbers.

[–] popcar2@programming.dev 2 points 15 hours ago

Performance testing is a whole can of worms. It's hard to get an idea of how performance changes because it'll depend a lot on the nodes and scripts being used. There could be huge regressions in specific cases and functions and no difference in others. Usually you'll need a suite of tests to see what changed.

[–] Gladaed@feddit.org 2 points 1 day ago (5 children)

But, why?

100mb are already negligible. I want a reasonable size (less 20GB) and ok performance.

[–] lucastucious@ludosphere.fr 3 points 9 hours ago (1 children)

@Gladaed @popcar2 web, mobile, and as always, less space and optimization is always a good thing.

[–] Gladaed@feddit.org 2 points 8 hours ago

Wasting time on metrics that don't matter is waste. I get and agree with mobile/web constraints. I did not consider them.

@Gladaed @popcar2 because every bloated 100gb game is a mix of a thousand different assets/executables/libraries where the developer thought "why optimize, 100MB is nothing".

Often with little more than symbol stripping, removing unneeded files, and basic lz compression you can cut most game sizes in half, reduce load times, and free up terabytes of space on your system.

[–] myersguy@lemmy.simpl.website 9 points 23 hours ago* (last edited 21 hours ago)

The article begins by talking about web exports. The default there is 42MB, which is kind of a lot for the web

Edit: Of course, compressed it is ~9, which isn't so bad, I suppose.

[–] unexposedhazard@discuss.tchncs.de 9 points 1 day ago* (last edited 1 day ago)

For mobile this is a legit difference imo

Also what raptor said.