26 releases (15 breaking)
new 0.16.0 | Mar 15, 2025 |
---|---|
0.14.0 | Feb 28, 2024 |
0.13.0 | Dec 1, 2023 |
0.12.0 | Nov 30, 2023 |
0.4.1 | Mar 9, 2023 |
#227 in Encoding
44 downloads per month
375KB
1.5K
SLoC
Bevy_save
A framework for saving and loading application state in Bevy.
Features
Save file management
bevy_save
automatically uses your app's workspace name to create a unique, permanent save location in the correct place for any platform it can run on.
World::save()
andWorld::load()
uses the managed save file location to save and load your application state, handling all serialization and deserialization for you.- These methods accept a
Pipeline
, a strongly typed representation of how you are going to be saving and loading. - The
Pipeline
trait uses theBackend
trait as an interface between disk / database andbevy_save
. - The
Backend
trait uses theFormat
trait to determine what format should be used in the actual save files (MessagePack / RON / JSON / etc)
Save directory location
With the default FileIO
backend, your save directory is managed for you.
WORKSPACE
is the name of your project's workspace (parent folder) name.
Windows | Linux/*BSD | MacOS |
---|---|---|
C:\Users\%USERNAME%\AppData\Local\WORKSPACE\saves |
~/.local/share/WORKSPACE/saves |
~/Library/Application Support/WORKSPACE/saves |
On WASM, snapshots are saved to LocalStorage
, with the key:
WORKSPACE.KEY
Snapshots and Rollback
bevy_save
is not just about save files, it is about total control over application state.
This crate introduces a snapshot type which may be used directly:
Snapshot
is a serializable snapshot of all saveable resources, entities, and components.
Or via the World
extension methods WorldSaveableExt
and WorldRollbackExt
:
World::snapshot()
captures a snapshot of the current application state, including resources.World::checkpoint()
captures a snapshot for later rollback / rollforward.World::rollback()
rolls the application state backwards or forwards through any checkpoints you have created.
The Rollbacks
resource also gives you fine-tuned control of the currently stored rollbacks.
Type registration
bevy_save
adds methods to Bevy's App
for registering types that should be saved.
As long as the type implements Reflect
, it can be registered and used with bevy_save
.
App.init_pipeline::<P>()
initializes aPipeline
for use with save / load.App.allow_rollback::<T>()
allows a type to roll back.App.deny_rollback::<T>()
denies a type from rolling back.
Type filtering
bevy_save
allows you to explicitly filter types when creating a snapshot.
Entity mapping
As Entity ids are not intended to be used as unique identifiers, bevy_save
supports mapping Entity ids.
First, you'll need to get a SnapshotApplier
:
The SnapshotApplier
will then allow you to configure the entity map (and other settings) before applying:
let snapshot = Snapshot::from_world(world);
snapshot
.applier(world)
// Your entity map
.entity_map(HashMap::default())
// Despawn all entities matching (With<A>, Without<B>)
.despawn::<(With<A>, Without<B>)>()
.apply();
MapEntities
bevy_save
also supports MapEntities
via reflection to allow you to update entity ids within components and resources.
See Bevy's Parent Component for a simple example.
Entity hooks
You are also able to add hooks when applying snapshots, similar to bevy-scene-hook
.
This can be used for many things, like spawning the snapshot as a child of an entity:
let snapshot = Snapshot::from_world(world);
snapshot
.applier(world)
// This will be run for every Entity in the snapshot
// It runs after the Entity's Components are loaded
.hook(move |entity, cmds| {
// You can use the hook to add, get, or remove Components
if !entity.contains::<Parent>() {
cmds.set_parent(parent);
}
})
.apply();
Hooks may also despawn entities:
let snapshot = Snapshot::from_world(world);
snapshot
.applier(world)
.hook(|entity, cmds| {
if entity.contains::<A>() {
cmds.despawn();
}
})
Partial Snapshots
While bevy_save
aims to make it as easy as possible to save your entire world, some applications also need to be able to save only parts of the world.
SnapshotBuilder
allows you to manually create snapshots like DynamicSceneBuilder
:
fn build_snapshot(world: &World, target: Entity, children: Query<&Children>) -> Snapshot {
Snapshot::builder(world)
// Extract all resources
.extract_all_resources()
// Extract all descendants of `target`
// This will include all components not denied by the builder's filter
.extract_entities(children.iter_descendants(target))
// Entities without any components will also be extracted
// You can use `clear_empty` to remove them
.clear_empty()
// Build the `Snapshot`
.build()
}
You are also able to extract resources by type:
Snapshot::builder(world)
// Extract the resource by the type name
// In this case, we extract the resource from the `manual` example
.extract_resource::<FancyMap>()
// Build the `Snapshot`
// It will only contain the one resource we extracted
.build()
Additionally, explicit type filtering like SnapshotApplier
is available when building snapshots:
Snapshot::builder(world)
// Exclude `Transform` from this `Snapshot`
.deny::<Transform>()
// Extract all matching entities and resources
.extract_all()
// Clear all extracted entities without any components
.clear_empty()
// Build the `Snapshot`
.build()
Pipeline
Pipelines allow you to use multiple different configurations of Backend
and Format
in the same App
.
Pipelines also let you re-use Snapshot
appliers and extractors.
Stability warning
bevy_save
does not yet provide any stability guarantees for save file format between crate versions.
bevy_save
relies on serialization to create save files and as such is exposed to internal implementation details for types.
Expect Bevy or other crate updates to break your save file format.
It should be possible to mitigate this by overriding ReflectDeserialize
for any offending types.
Changing what entities have what components or how you use your entities or resources in your logic can also result in broken saves.
While bevy_save
does not yet have explicit support for save file migration, you can use SnapshotApplier::hook
to account for changes while applying a snapshot.
If your application has specific migration requirements, please open an issue.
Entity
For all intents and purposes,
Entity
should be treated as an opaque identifier. The internal bit representation is liable to change from release to release as are the behaviors or performance characteristics of any of its trait implementations (i.e.Ord
,Hash,
etc.). This means that changes inEntity
’s representation, though made readable through various functions on the type, are not considered breaking changes under SemVer.In particular, directly serializing with
Serialize
andDeserialize
make zero guarantee of long term wire format compatibility. Changes in behavior will cause serializedEntity
values persisted to long term storage (i.e. disk, databases, etc.) will fail to deserialize upon being updated.
bevy_save
serializes and deserializes entities directly. If you need to maintain compatibility across Bevy versions, consider adding a unique identifier Component
to your tracked entities.
Stabilization
bevy_save
will become a candidate for stabilization once save versioning and migration is finished.
Compatibility
Bevy
Bevy Version | Crate Version |
---|---|
0.15 |
0.16 2 |
0.14 1 |
0.15 |
0.13 |
0.14 |
0.12 |
0.10 , 0.11 , 0.12 , 0.13 |
0.11 |
0.9 |
0.10 |
0.4 , 0.5 , 0.6 , 0.7 , 0.8 |
0.9 |
0.1 , 0.2 , 0.3 |
Save format changes (since 0.15
)
-
bevy
changedEntity
's on-disk representation -
bevy_save
began usingFromReflect
when taking snapshots
Platforms
Platform | Support |
---|---|
Windows | Yes |
MacOS | Yes |
Linux | Yes |
WASM | Yes |
Android | No |
iOS | No |
Feature Flags
Feature flag | Description | Default? |
---|---|---|
bevy_asset |
Enables bevy_asset type registration |
Yes |
bevy_render |
Enables bevy_render type registration |
Yes |
bevy_sprite |
Enables bevy_sprite type registration |
Yes |
brotli |
Enables Brotli compression middleware |
No |
License
bevy_save
is dual-licensed under MIT and Apache-2.0.
Dependencies
~26–62MB
~1M SLoC