Installation files

[hydroper]

Heavy games with a large number of assets (that doesn't make sense to store in the RAM) often store these asset files in the app's installation directory and load them on demand. One example is Phantasy Star Online 2, which is present at Steam and Microsoft Store, weighting over 90GB. These asset files are typically read-only in the API, but writeable by the store (Steam and Microsoft Store for example).

The problem of std::fs is that it's not "aware" of the actual app's installation path. It varies per platform and also based on the app's id (e.g. com.ea.n4s). In Android, the installation path looks like /data/com.ea.n4s/_installation.

For Android, to obtain this installation path you typically use the app's context and call getFilesDir.

---

Valorant and other Epic Games games are other examples of this not using a cloud solution

[hydroper]

Cloud storage and loading from there is also a solution though... The game I cited uses file storage instead.

[rlidwka]

So what do you suggest to do?

And can you make proof-of-concept as a bevy crate? Pretty sure that this can be configured by user with providing custom assetio, an in an example here.

[hydroper]

What I've thought of was:

• A build script at your Bevy's project (build.rs), which looks like:

#[bevy::build_script]
fn main() {}

bevy::build_script will get app id from reading Bevy meta-data from Cargo.toml, and, with that, it'll generate a Rust script at the recipes directory. This generated script is a script that mutates a static variable used to hold the app's installation path for specific platforms. For Android though, the Java API's Context has to be used instead and the getFilesDir(), because the app's installation path varies per SD card.

• The Bevy's project entry point looking like:

#[bevy::main]
fn main() {}

// `bevy::main` does this:
// `include!(concat!(env!("OUT_DIR"), "/bevy_engine_main.rs"));`

This will include the script generated by the build script, which like I said basically mutates static variables indicating installation path.

• Provide an API for accessing files from installation path. Within that API you may choose to even support custom URIs if desired to indicate the kind of file resolution.