Technical Design

Network Architecture

RISK This is the highest-cost, highest-risk area of the project. Persistent, server-authoritative, raidable PvPvE for ~40–60 players is genuinely hard. Treat the networking + persistence backbone as a Phase-1 first-class deliverable, not something to retrofit.

Status: draftOwner: UnassignedUpdated: 2026-08-27

Production context

Canonical sourceGDD/04-Multiplayer/01-Network-Architecture.md
Decision markers1 confirmed · 2 recommendations · 3 TBD
Browser document roleRead-only production view; edit the GDD source or this generated system through the project workflow.

Verified implementation evidence

  • Source/Lambeer/Persistence/SaveSubsystem.*
  • Source/Lambeer/Persistence/InMemorySaveBackend.* (temporary in-memory backend)
  • Source/Lambeer/Core/LambeerPlayerState.*

Relationships

Document contract coverage

Use these required Technical Design areas during review. The imported GDD below is canonical; items not stated explicitly remain unresolved.

  • ReviewProblem & Scope
  • ReviewCurrent vs Proposed
  • ReviewArchitecture
  • ReviewData Model
  • ReviewInterfaces & Events
  • ReviewReplication / Persistence
  • ReviewPerformance & Failure Handling
  • ReviewImplementation Plan
  • ReviewVerification Strategy
  • ReviewTechnical Decisions / TBDs

Canonical GDD content

[RISK] This is the highest-cost, highest-risk area of the project. Persistent, server-authoritative, raidable PvPvE for ~40–60 players is genuinely hard. Treat the networking + persistence backbone as a Phase-1 first-class deliverable, not something to retrofit.

Model — [CONFIRMED]

  • Dedicated-server authoritative. The server owns all gameplay truth: damage, inventory, stats, building, loot, AI. Clients are never trusted.
  • No listen-server / P2P for live play (a listen-server mode may be used purely for local testing).
  • ~40–60 players per server instance, plus AI hordes.
  • Linux dedicated server build target (MetaHuman plugins are already configured for Win64 + Linux).

Core principles

  1. Server authority everywhere. Clients send requests (RPCs/input); the server validates and applies. This is the foundation of anti-cheat for a full-loot/raid game.
  2. Client prediction for feel. Movement and firing feedback are predicted client-side and reconciled with the server.
  3. Replication discipline. With ~40–60 players + AI + bases, naïve replication will not scale. Use relevancy, dormancy, update-frequency tuning, and consider the Replication Graph for relevancy management. [RECOMMENDATION], validate need by profiling.
  4. Lag compensation for hitscan combat (server rewind) so shooting feels fair. [RISK] non-trivial; budget for it.

Replication hotspots (plan for these)

System Challenge Mitigation direction
Building (hundreds of pieces/base) Too many actors to replicate ISM/HISM visuals + lightweight per-piece records; dormancy; distance relevancy
AI hordes Server CPU + replication AI LOD, active caps, relevancy despawn; evaluate Mass if needed
Inventories Bandwidth + privacy Replicate owner-only; server validates all changes
Combat hits Fairness + cheating Server-authoritative + lag comp; never trust client damage
Bosses + PvP in one area Replication spike Relevancy + effects budget

Persistence backbone — [RISK], design [TBD]

Persistent world means the server must save and restore world/player state across restarts:

  • Player data: inventory, equipment, survival stats, unlocked recipes, permanent boss buffs, position/respawn point, clan/squad membership.
  • World/base data: placed building pieces (transform, tier, HP, ownership), container contents, deployables, vehicles, territory anchors.
  • Loot/world state: container respawn timers, dropped death-bags (with despawn timers).

Open decision [TBD]: persistence technology. Options to evaluate: - Embedded/local (e.g., SQLite or flat binary saves) — simplest for player-hosted servers. - External database (e.g., Postgres/Redis) — needed for official fleet, analytics, cross-instance features. - A hybrid: a save abstraction (USaveSubsystem) with pluggable backends so player-hosted uses local and official uses external.

[RECOMMENDATION]: define a clean persistence abstraction layer early; do not couple gameplay code directly to a storage technology. Save format must be versioned (schema migrations) since the game will evolve.

Connectivity & ops (later phases)

  • Matchmaking/server-browser, sessions, and a backend for official servers are Phase-2/3. See 02-Servers-and-Hosting.md.
  • Anti-cheat: [TBD] solution (EAC/BattlEye/other). Server authority is the first line; a dedicated anti-cheat is needed before/at launch given full-loot stakes.

Implementation guidance

  • Build gameplay systems server-authoritative from day one — retrofitting authority is far more expensive than designing for it.
  • Use GameState/PlayerState for replicated shared/per-player state; keep large/private data in owner-only-replicated components.
  • Co-locate persistence with a UGameInstanceSubsystem/UWorldSubsystem save service. See ../05-Technical/04-Source-Code-Structure.md.