Servers & Hosting · Game Documentation

Production context

Canonical sourceGDD/04-Multiplayer/02-Servers-and-Hosting.md

Decision markers1 confirmed · 3 recommendations · 4 TBD

Browser document roleRead-only production view; edit the GDD source or this generated system through the project workflow.

Verified implementation evidence

Not verified for this documentation pass.

Relationships

TECH-NETWORK-ARCH

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

Both official-dedicated and player-hosted servers — [CONFIRMED]. Players can join servers run by the developer and can also rent/run their own dedicated servers (Rust-like).

Hosting models

Official dedicated (developer-run)

Developer operates a fleet of dedicated servers.
Controlled quality, monitoring, anti-cheat, and live-ops.
This is the curated/"trusted" experience.
[RISK] ongoing hosting cost + ops burden; this is a real operating expense for an indie. Plan capacity and cost before launch.

Player-hosted dedicated

Players run the Linux/Windows dedicated server binary themselves (rented box or home server), Rust/DayZ-style.
Grows the community and offloads hosting cost; enables custom rules/mods.
Requires: a shippable, documented server build; configuration files; an admin/RCON toolset. This is a Phase-3 deliverable (tooling/docs), though the dedicated build itself must work from Phase 1 for development.

Server configuration — [RECOMMENDATION]

Expose via config (.ini/JSON) so server operators can tune without code (see ../05-Technical/05-Project-Setup-Steps.md): - Max players, server name/description, map/region selection. - Rates: gather multipliers, craft speed, decay timers, loot respawn. - Rules: PvP on/off zones [TBD], raid windows [TBD], offline-raid protection [TBD]. - Wipe schedule (see below).

Persistence per server

Each server has its own persistent world (bases, players, progress are per-server, not shared across servers).
Permanent boss buffs are per-server (see ../03-Enemies/02-Boss-Zombies.md).
Backed by the persistence layer in 01-Network-Architecture.md.

Wipes — [RECOMMENDATION]

Persistent survival servers typically need periodic wipes (reset of bases/progress) to keep servers fresh and competitive and to bound save-data growth. Cadence (e.g., weekly/monthly), and what wipes (map vs. blueprints vs. nothing) is [TBD]. Decide before live, as it affects how "permanent" boss buffs and progression feel.

Administration

Admin/moderation tools: kick/ban, teleport, spawn, inspect — [RECOMMENDATION], needed for live and for player-hosted operators.
Logging/telemetry for cheat detection and balancing.

Build targets

Client: Win64 (PC).
Server: dedicated server target (LambeerServer.Target.cs) for Linux (and Win64 for local dev). See ../05-Technical/05-Project-Setup-Steps.md.