this post was submitted on 11 Mar 2025
81 points (98.8% liked)
Godot
6406 readers
36 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
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
Rules
- Posts need to be in english
- Posts with explicit content must be tagged with nsfw
- We do not condone harassment inside the community as well as trolling or equivalent behaviour
- Do not post illegal materials or post things encouraging actions such as pirating games
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
Credits
- The icon is a modified version of the official godot engine logo (changing the colors to a gradient and black background)
- The banner is from Godot Design
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
But, why?
100mb are already negligible. I want a reasonable size (less 20GB) and ok performance.
@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.
Updates also make this difference larger.
EDIT: A better way to say this is that this probably makes a lot of sense for small developers to do in stable releases at-very-least. Even then I could see picking-and-choosing for all sorts of different reasons. If this is part of an export script I could see it being practically free minus a slightly longer build time that is probably still in an acceptable range.
@Gladaed @popcar2 web, mobile, and as always, less space and optimization is always a good thing.
Wasting time on metrics that don't matter is waste. I get and agree with mobile/web constraints. I did not consider them.
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.
For mobile this is a legit difference imo
Also what raptor said.
@Gladaed @popcar2
See https://mastodon.gamedev.place/@popcar2/114144232496373416