Dynamically loaded assets and/or lossy compression

[andrigamerita]

Hi people, first of all congratulations on this port! I'll say you've actually beat me on time, because I had the same idea about a week ago, but didn't actually start anything, and then today I decide to Google "celeste wasm" and magically I see this project appear out of nowhere!

The game runs pretty well even on Firefox, performance-wise, although in general it uses a lot of system memory, and the huge download makes jumping into the game to have fun slow. Loading issues are especially prevalent with the single-file HTML version. I think that this port could be made much more enjoyable by implementing one (or both) of two practices that are pretty standard when creating web games, regarding game assets (music, sfxs, textures, backgrounds, ...):

• Dynamic asset loading (realistically applies only to the HTTP-served version): I'm not sure of if there are implementation difficulties with the runtime environment you're using here, but it would be useful to have the game download just the assets it needs as it's being played. The game could start almost immediately, as it would only need to download the code initially, and maybe things like localization data, and the rest would be downloaded as the player progresses. Vanilla JavaScript games can do this easily (on there it would require more effort to preload assets, actually), but a notable example of a WASM-based game engine using this technique is Ren'Py, which can be made to load everything as needed, usually with pixelated version of images being preloaded to avoid annoying pop-in effects. In the wild, I've also seen Unity Web games do this to a degree (at least with music, I don't know about the rest), as well as other minor engines.

• Using lossily-compressed assets (applies to all): Another common practice, especially when porting games initially made for other platforms to the web, is using lossy compression, applied to assets to a degree where the space savings (and, in some cases, performance gains due to faster decoding) are notable, but the game is still pleasant to play. Many ports of mobile games do this, and you will probably notice it by playing a random one on HTML gaming sites, but a notable example is Eaglercraft, a port of Minecraft Java edition that, for release 1.8, manages to pack the entire game in a single HTML file of just ~15 MB. Optionally, this port could be distributed in two flavours, one with the unaltered assets for the most hardcore gamers (sorry I had to write it it's too funny), and the highly-optimized one for everyone else. I think I would actually like to try and implement this improvement myself, but I'm standing at a dead end after being confronted with Celeste's .data file format, which I can't really find much information online, and the most I've found is extractor programs with no repacking feature. (I haven't yet tried to write any packing code myself by reading the unpacking one, because I can't get if this is a Celeste-specific format or is just a strange but common format for which good tooling already exists.)

Let me know if these ideas fit on your roadmap! This porting has so much potential, it's truly the Universal Binary Executable for Celeste, and I think these two improvements would go a long way to making it more accessible and pleasant (even realistically usable on mobile, I predict).

[velzie]

thanks! the download is only for the first time, the assets should get cached in your browser's local storage. we're already using vorbis compression on the sounds and LZ4 for the entire assets bundle. there's definitely more to compress out of the .data files but i don't know how much png/jpg compression would do for the mostly pixel art assets. RE: asset streaming, emscripten FS operations generally cannot be async so the main thread would have to be blocked during chapter loading which would be pretty annoying on slower connections (other option would be to callback js from the game to "predict" when assets would need to be loaded before they are). there's definitely things to be improved though and i'm glad someone's as interested in the project :)