Universal Data Modeling and State Management

This document explains one core part of the Playserv technology stack:
a universal system for modeling game data and managing its state in real time.

The goal of this system is simple:
make complex multiplayer data predictable, observable, and scalable.

The problem we solve

In most multiplayer projects, data modeling evolves chaotically:

• game state is split across client, server, and backend
• each system has its own data format
• synchronization logic is written manually
• debugging requires logs, breakpoints, and guesswork

As the project grows, this leads to:

• inconsistent state
• hard-to-reproduce bugs
• fragile networking code
• slow iteration speed

Core idea

Playserv treats all game data as structured entities with explicit state.

Instead of thinking in terms of packets, RPCs, or replication rules, you work with:

• entities
• schemas
• versions
• state changes

Everything else is derived from that.

Entities

An entity is a typed object that represents something meaningful in the game world.

Examples:

• Player
• Character
• NPC
• Item
• Quest
• Match
• World object

Each entity has:

• a unique identifier
• a schema (structure of data)
• a current state (snapshot)
• a history of changes (versions)

Schemas

Schemas define what data an entity can have.

They answer questions like:

• What fields exist?
• What types do they have?
• Which fields are optional?
• Which parts of the state are public or restricted?

Schemas are defined once and reused everywhere:

• server logic
• validation
• subscriptions
• debugging tools

This removes ambiguity and reduces accidental complexity.

State and versions

Every time an entity changes, Playserv creates:

1. A new version number
2. A state diff
3. A change event

This means:

• state is never silently overwritten
• every change is traceable
• clients can reconcile state safely
• debugging becomes deterministic

Example (conceptual):

{
  "entity": "Player:42",
  "version": 128,
  "changed": {
    "position": { "x": 10, "y": 4 },
    "hp": 95
  }
}

Why versioned state matters

Versioned state enables things that are hard or impossible otherwise:

• time-travel debugging
• replaying game sessions
• auditing player actions
• resolving desyncs deterministically

Instead of asking “what is the state now?“
you can ask “how did the state get here?”

Unified mental model

The same data model is used across the whole system:

This dramatically reduces cognitive load for the team.

Result

With universal data modeling:

• multiplayer logic becomes declarative
• state synchronization becomes automatic
• visibility and access rules stay explicit
• systems scale without rewriting fundamentals

This is the foundation on which the rest of the Playserv platform is built.