Feature Specification

Clans & Squads

Full clan + squad systems — CONFIRMED. Players can form small tactical groups (squads) and larger persistent organizations (clans). Group identity drives cooperation, base ownership, and territory.

Status: draftOwner: UnassignedUpdated: 2026-08-27

Production context

Canonical sourceGDD/04-Multiplayer/03-Clans-and-Squads.md
Decision markers1 confirmed · 2 recommendations · 5 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

Document contract coverage

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

  • ReviewPurpose & Player Value
  • ReviewScope
  • ReviewOut of Scope
  • ReviewTerminology
  • ReviewFunctional Behavior
  • ReviewStates & Flows
  • ReviewRules & Edge Cases
  • ReviewDependencies
  • ReviewAcceptance Criteria
  • ReviewOpen Questions

Canonical GDD content

Full clan + squad systems — [CONFIRMED]. Players can form small tactical groups (squads) and larger persistent organizations (clans). Group identity drives cooperation, base ownership, and territory.

Squads (small, tactical)

  • Small group (size [TBD], e.g., 4–6) for playing together right now.
  • Friendly identification: squadmates shown on HUD/markers; reduced/disabled friendly-fire [TBD] (full-loot games sometimes keep FF for realism — decide deliberately).
  • Shared access: squadmates can use each other's bases/storage (governed by build privilege — see ../01-Gameplay/05-Building-System.md).
  • Squad utilities: map pings, voice/text [TBD], shared respawn at squad beds, downed-revive [RECOMMENDATION].
  • Squads are session-oriented but membership can persist.

Clans (large, persistent)

  • A persistent organization with a name/tag, roster, and ranks/roles (leader, officer, member) with permissions.
  • Shared territory & bases: clan-owned build privilege so many members can build/maintain shared bases.
  • Clan progression / territory: controlling regions and shared infrastructure (ties to the "Base/Territory" progression vector and ../01-Gameplay/07-Crafting-and-Progression.md).
  • Persistence: clan data (roster, ranks, ownership) is part of server persistence (see 01-Network-Architecture.md).

Ownership & permissions model

The core question free-form building + groups must answer: who can build, open doors, and access storage where?

  • Build privilege via territory anchor (Tool-Cupboard-like) — [RECOMMENDATION]. The anchor stores an authorized list (player/squad/clan). Within its radius, only authorized players can place/modify/open.
  • Permission granularity (build vs. door vs. storage vs. anchor management) is [TBD] but should be role-based for clans.

Friendly fire & griefing — [TBD]

  • Friendly-fire on/off within squad/clan.
  • Anti-grief for shared bases (e.g., logged actions, role-gated demolition).
  • These decisions materially affect tone (hardcore vs. accessible). Decide deliberately with the owner.

Implementation guidance

  • Squad/clan membership is replicated state (likely on PlayerState + a server-side group registry/subsystem).
  • Build-privilege checks are server-authoritative in UBuildComponent placement validation.
  • Group management UI is UMG (Blueprint) over replicated C++ state.
  • Scope note: full clans are Phase-2; squads are Phase-1 (needed for co-op boss hunts). See ../00-Overview/02-Scope-and-Constraints.md.