- cross-posted to:
- hackernews@lemmy.bestiver.se
- cross-posted to:
- hackernews@lemmy.bestiver.se
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!
@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.
Also needlessly uncompressed audio or poorly compressed video (that likely could instead be in-engine) particularly when multiple resolutions are needed. Sometimes one of these might be the bigger issue, particularly with remasters.
@Gladaed I have less-than-stellar internet* (~6mb/s, shared with others), 20GB is definitely not a reasonable size for me. 100MiB is fine, but not negligible. Consider also storage space, particularly because users will run games from slower(->cheaper) drives when they deem games too big (which for me is already at 1GiB+, at least in terms of having a library because that adds up).
* and I live in the US, not even in the woods! The price isn’t even great, either.
As I see it, data size is an inverse multiplier for viability. The smaller a download is the more likely that users will be able to get and store it (long-term even) without issue. The difference between a day and an hour is huge, the difference between an hour and 5 minutes is still worthwhile (especially if this impacts household internet speed). Less than that (nearing instant download) is peak.