Persistent saves

PixelRifts can keep selected player progress between authoritative play sessions. Saves are bounded platform data, not custom files or browser state.

Enable an autosave

1. Select the player object.
2. In Object inspector, choose Add → Persistent save.
3. Choose at least one category: checkpoints, seen dialogue, inventory, or equipment.
4. Add an Inventory component before enabling inventory persistence.
5. Publish and play with a signed PixelRifts guest identity through authoritative realtime play.

The server saves after a player reaches a checkpoint, sees new dialogue, or collects an item in an enabled category. A returning player loads one autosave for that exact published version.

What is saved

• The checkpoint entity ID; its safe position is recalculated from the published Rift.
• IDs of dialogue triggers the player has seen.
• Bounded item IDs and quantities, with labels, slots, and stack limits revalidated from the published Rift.
• Optional weapon, armor, and tool item IDs, revalidated against both saved Inventory and the published Player's Equipment catalog.

Position, velocity, score, arbitrary variables, HTML, scripts, global pickup state, and account economy goods are not saved. A new published version has a separate save slot. Test Rift/local play can exercise the component rules but does not claim durable server persistence.

Players without a signed identity can still play, but their session is not saved. If the save service is unavailable, a save-enabled signed join stops safely instead of starting from stale state and overwriting progress.

Versions, migrations, and quotas

Every save includes a platform save-state schema version. Legacy saves without the field and v1 saves migrate deterministically to v2; they receive no equipped items. Creator code never runs during migration. Unsupported future save versions fail closed. See Runtime and save migrations.

One player may retain up to eight active immutable-version saves for a Rift project, using at most 128 KiB combined; each version state is limited to 32 KiB. Resetting progress for an old version frees its active slot and bytes while retaining a generation marker that rejects delayed stale writes.

The server derives the project/version relationship from the immutable publication. A client cannot relabel a save to evade these limits.