Beasty Save System

Beasty Save System saves and loads your game without dragging anything else into your project.

NO DEPENDENCIES

It ships its own JSON engine. No Newtonsoft.Json, no third-party DLL, nothing to version-conflict with what you already have. Import it into an empty project and it compiles.

A RESULT YOU CAN CHECK

Every call hands back a typed result instead of throwing. A save that failed says so — it does not look like a save that worked. That one detail is the difference between a player who sees "could not save" and a player who closes the game believing their progress is safe.

    var settings = new BeastySaveSettings { Folder = "Saves", Extension = "save" };

    SaveResult saved = BeastySave.Save(myData, "slot1", settings);

    if (!saved.Success) Debug.LogError(saved.Message);

    LoadResult<MyData> loaded = BeastySave.Load<MyData>("slot1", settings);

    if (loaded.Success) Use(loaded.Value);

    else if (loaded.BackupAvailable) BeastySave.RestoreBackup("slot1", settings);

SCENE STATE WITHOUT WRITING A SERIALIZER

Drop a BeastySaveable on an object and tick the components you want persisted — including inactive objects, and several components of the same type on one object. A BeastySaveManager in the scene saves and loads all of them at once, straight from a uGUI button. Objects you spawn at runtime get a stable id of your choosing, so a chest you instantiated finds its own state again next session.

It saves what Unity itself would serialize: public and [SerializeField] fields, including private ones inherited from a base class, plus arrays, List, Dictionary, HashSet, SortedSet, Queue and Stack, and the Unity value types (Vector, Quaternion, Color...).

SAFE BY DEFAULT

• Atomic writes: the file is written to a temp and swapped in, so a crash mid-write cannot leave half a save behind.
• Backups: the last good version of each slot is kept, and a corrupted slot can be restored from it. Saving on top of a damaged slot does not destroy the recoverable copy.
• Strict loading is all-or-nothing: if any component fails, nothing is applied and the world is left exactly as it was. Tolerant loading skips the offending field, reports it in Warnings, and loads the rest — the escape hatch for when you rename a field mid-production.
• Optional AES-256 encryption with a random IV and a key derived with SHA-256. It is obfuscation against casual save editing, not real security, and the package says so out loud: the key ships inside your game.
• And it tells you what it did: every save, load, delete and restore logs its slot, size and timing — with a Verbose mode for chasing bugs — in the editor and development builds, silent by default in a release build.

LOCAL FILES OR THE CLOUD

Saves go to local files by default — or to a database: pick a storage backend from a dropdown on the Beasty Save Manager. The Firebase modules (Cloud Firestore and Realtime Database) compile only when the Firebase SDK is in the project — nothing to set up beyond importing it — sign the player in anonymously, and store each user's saves under their own id. The same slot API works against any backend, async-first: a synchronous call on a cloud backend comes back as a typed error instead of blocking, and the manager's UnityEvent entry points route asynchronously on their own. Want your own endpoint instead? Implement IBeastySaveStorage and register it, or use SaveToJson / LoadFromJson and ship the JSON wherever you like.

CUSTOMIZABLE

The converter layer is open: write a converter for your own type, or replace the one for a Unity type, and the pipeline picks it up. The settings object (folder, extension, encryption, strict mode, storage backend) is passed per call, so an autosave and a manual save can behave differently in the same project.

Genre-agnostic — it persists C# objects and scene components, so it fits an RPG, a survival game, a visual novel or an editor tool equally well. It is the same save system that ships inside Beasty Visual Novel, extracted and usable on its own.

Documentation: https://bauflowbeasty.github.io/