Hacker News new | ask | show | jobs
by reitzensteinm 1624 days ago
Congratulations on release!

I was wondering if there is any low hanging fruit for WebGL build size improvements.

I did a Unity test build for comparison against your rect example, with a cube and a single script that does nothing (so they can't e.g. strip out Mono).

Listing sizes uncompressed, 7z Ultra (a decent proxy for Brotli), and wasm-opt + 7z Ultra respectively:

Rect example: 13473kb, 1964kb, 1720kb

Basic Unity: 9528kb, 2304kb, 2291kb

Bevy is still leading, but it's getting uncomfortably close.

The uncompressed sizes matter a lot more than any other asset type, as it's all code that has to be compiled, running poorly until the optimized compiler has finished with it. On a Chromebook, my experience is that much code gives you 30-60s of poor FPS before it comes good.

I understand this is not necessarily a focus of Bevy, but I do think that you have an opportunity here to build the first game engine without significant downsides on any single platform. Filling the code base with a bunch of feature flags may not be worth it to achieve that goal, though.

The modularity of Bevy is super exciting (I've asked you before about WebGL builds on here before and you mentioned this). But Unity ships quite a bit of stuff in a basic build and is probably fairly similar in scope to Bevy with all crates.

1 comments

There are a number of techniques available to shrink wasm size in rust, this is the best collection of them I'm aware of https://rustwasm.github.io/docs/book/reference/code-size.htm....

Please also consider Unity web used to be significantly worse and it took multiples of bevy's lifetime for it to get to where it is now :)