Built while we build games
NexusForge Studio is a game studio first. Some of what a game needs is not specific to that game, though: when a problem is general enough, we turn our solution into a tool, document it properly and keep it reusable for the next project. That is this page, and it is a side of the studio rather than its centre.
Published technology
One tool is published today, and it is used in the studio's own work. Its documentation is held to the same standard as the code: every capability carries a status, and the limitations are written before the feature list.
PersistKit
VerifiedA save and load package for Unity. One line saves a value and the same line loads it, or one component remembers a scene object from a few ticks in the Inspector. Named slots with rotating backups, a recovery ladder for a damaged file, asset references by registry key, the objects a game spawned from prefabs, AES-256 with HMAC authentication on request, ordered migrations that copy before they write, and cloud copies that ask rather than overwrite.
Unity 6000.3 · .NET Standard 2.1 · Unity's own packages only (Unity UI; the Unity Test Framework for the tests), no third-party code · 462 Edit Mode and 74 Play Mode tests, and an IL2CPP player built and run twice for 1.0.0 (77 checks, 0 failures).
Sample projects and examples
AvailableThe package ships one importable Unity sample today — 01 Quick Start: saving a score, then a data class, a list and a dictionary, and loading them back. Three larger samples (a clicker, a physics sandbox and a multi-scene RPG) are on the roadmap rather than described as if they were here.
Free to read, free to delete, compiled as part of the package's verification.
Where the technology goes next
These are directions, not commitments. When something moves from planned to available, this page and the changelog change on the same day.
| Area | Status | What it means |
|---|---|---|
| Cloud adapters for common services | Roadmap | The folder and REST providers are released and verified. Adapters for services whose SDK needs an account, a plan or a platform toolchain (Unity Cloud Save, Steam Cloud, Firebase, Supabase, PlayFab) are documented but not written, because none of them can be run here. |
| Verification beyond Windows x64 | Roadmap | Running the existing suite and probe on mobile and console targets, and reporting exactly what was found. Verification is the product here, not a marketing step. |
| Further Editor tooling | Roadmap | More of the same kind of thing: checks with remedies, in the one finding format that already exists. |
| Visual scripting integrations | Roadmap | Nodes over the existing facade, for teams that do not write C#. |
What turns into a tool here
Three questions, in order. A tool has to pass all three.
Does a game we are building need it?
The persistence framework exists because the studio's own projects each needed the same unglamorous infrastructure. Nothing gets built here for a market that might exist.
Can we verify it?
If a capability cannot be tested in a real environment and reported with evidence, it does not ship as "available". It ships marked as unverified, or it does not ship.
Does it stay reusable?
Anything that knows what a "player" or an "item" is belongs in a game, not in a tool. The moment a tool learns about one game's world, it stops being useful to the next.
What will not become a tool here
Not supported A bundled cloud service, accounts, leaderboards, telemetry, key management, save-file editing tools and server authority. The reasons are on the limitations page, next to everything else we choose not to do.