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.
NexusForge Persistence
VerifiedA game-agnostic persistence framework for Unity: atomic local storage with recovery, a versioned container, ordered schema migration, integrity, authentication, authenticated encryption, bounded compression, autosave, checkpoints, stable object identity, Unity object capture and restore, and a vendor-neutral cloud seam.
Unity 6000.6 · .NET Standard 2.1 · one runtime dependency · 582 Edit Mode tests and a 12-check IL2CPP player probe.
Sample projects and examples
AvailableFour importable Unity samples ship with the package: basic save and load, cloud synchronisation against an in-memory transport, migration and versioning, and persistent objects with checkpoints. Each has its own README and its own assembly definition.
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 | Transports for REST-shaped services and the major game backends, so the seam is not the only thing between a project and its provider. REST comes first, because it needs no vendor SDK. |
| 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.