// the find
NiklasEi/bevy_asset_loader
Bevy plugin helping with asset loading and organization
A Bevy plugin for declaring the assets a game needs as a struct of handles. Derive AssetCollection, add a loading state, and the plugin waits until every file is loaded before inserting the struct as a resource and moving to your next state. It suits Bevy developers who are tired of hand-written load-tracking systems, and the derive still works without a loading state.
The derive covers the common cases without a custom system: single files, explicit path lists, folders, texture atlas layouts, image sampler settings, and standard materials. The full_collection example shows the whole attribute surface in one file, which is the quickest way to see what is possible. Compile-time paths and dynamic assets share one collection type, so swapping a path attribute for a key moves configuration into a RON file and avoids recompiling for asset tweaks. The loading state guarantees handles are fully loaded before the next state starts, so downstream systems can take Res<T> without Option handling, and finally_init_resource extends that to FromWorld resources that depend on loaded assets. Progress tracking is opt-in behind a feature flag and plugs into iyes_progress, so a progress bar does not need its own polling system.
A failed load leaves the app stuck in the loading state unless you call on_failure_continue_to. Beyond Bevy's own warnings in the log, nothing tells you it happened, which is an easy thing to ship by accident. Each Bevy release needs a matching crate release, and the compatibility table shows the churn: 0.19 maps to 0.27 and 0.18 spans two crate versions. Some features quietly drop out depending on setup: folders do not work on wasm, and collections built without a loading state cannot use folders, dynamic assets, or image annotations. The README links an open issue for that gap, so it is known, but it limits the no-loading-state path. Unloading is manual: you have to remove the collection resource yourself when leaving a state, because strong handles keep assets in memory. That is documented, but it is easy to forget in a long-lived app.