Menu
  Log out
 

Persistent Data and Shared State for Multiplayer Games

Game Server Backend Guide • Updated Apr 11, 2026

Persistent Data and Shared State for Multiplayer Games

Progression systems break when all saved data gets dumped into one giant profile blob. Supercraft GSB separates player-scoped documents from project-scoped shared documents, so you can model progression, inventories, flags, rotations, and server-visible state without mixing everything together.

Two Document Scopes

Scope Use It For
Player documents Profiles, loadouts, unlocks, quest flags, progression snapshots, and per-player inventories.
Project documents Shared rule sets, current events, server rotations, live world settings, and environment-wide flags.

Typical API Surface

GET /players/{player_id}/documents/{key}
PUT /players/{player_id}/documents/{key}
POST /players/{player_id}/documents/batch-write

GET /documents/{key}
PUT /documents/{key}
POST /documents/batch-write

Why JSON Documents Work Well Here

Game teams rarely need a single rigid schema for every feature. They need a safe way to store structured data that changes as the game grows. JSON documents fit that reality, as long as you keep boundaries clean.

  • Keep identity separate from progression.
  • Keep inventory separate from social state.
  • Keep shared environment flags out of player profiles.
  • Use batch reads and writes for hot paths that touch several small documents together.

A Practical Layout

player/profile
player/inventory
player/progression
player/quests/current
project/liveops/current_rotation
project/match_rules/default
project/event_flags/spring_drop

This is easier to reason about than a single save object that every system mutates for unrelated reasons.

Environment Isolation Matters

GSB scopes data to both a project and an environment. That gives you clean production, staging, and test separation. It also stops balance testing or data repair work from contaminating live player state.

Operational benefit: your support tools, server runtime, and liveops tooling can all touch the same platform without sharing the same environment.

Roblox-specific boundary: if you are deciding between native Roblox storage and a broader backend, read Roblox DataStore vs External Database and Roblox Cross-Experience Progression.

When Servers Should Read or Write Player Data

Dedicated servers should be the caller for authoritative progression updates, match-end rewards, or anti-cheat-sensitive state changes. Let the client read and display where it makes sense, but do not make the client the final authority for economy or reward writes.

Related in This Hub

See how Supercraft structures multiplayer state on the Game Server Backend page.

← Back to Game Server Backend Guides
Top