Production schedule — 2026-09-13: PIPE-ROADMAP now defines 32 focused phases (P00–P31). Phase 0/1/2/3 references retained in this document are legacy scope bands, not the new phase numbers. The owner confirmed limited-area core-loop proof before full-map expansion; see the roadmap for dependencies, audited status and remaining work.
Production context
GDD/04-Multiplayer/03-Clans-and-Squads.mdVerified implementation evidence
- Not verified for this documentation pass.
Relationships
FEAT-LOCK-ACCESS— installed-lock Squad accessTECH-NETWORK-ARCH
Document contract coverage
Use these required Feature Specification areas during review. The HTML content below is authoritative; 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
Authoritative project 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)
- Squads have no design-level member cap — [CONFIRMED]. Practical server and UI behavior must be profiled at large membership counts.
- Squad identity: [RESOLVED 2026-09-30] A Squad must have a name on creation; its logo is optional and uses a placeholder until uploaded. Only the current Leader may rename or replace the logo. Names are 1–16 characters, unique within one server without case distinction. Uploads accept PNG only, at most 5 MB and 256 × 256 pixels; no approval is required before display. The server validates changes and persists the name and logo with the Squad identity. The first member of a legacy Squad record becomes Leader and must provide a name on rejoin. The initial file picker targets Win64. The activity log retains the latest 100 entries across restart/rejoin.
- Friendly identification: squadmates are shown on HUD/markers. Friendly fire is dedicated-server configurable — [CONFIRMED].
- Shared access: squadmates can use installed Lock items owned by another current Squad member on eligible doors, windows, World Containers and Player-built Storage. This does not grant vehicle ignition: every Squad member still needs the exact vehicle key unless that key is inserted or the vehicle was permanently Hotwired. Canonical rules:
FEAT-LOCK-ACCESS. - Unfinished construction: [OWNER CONFIRMED 2026-09-29] a player must create or join a Squad before placing any building piece; players without current Squad membership cannot place a hologram. A placed building hologram belongs to its Squad. Only current members see it; every member may contribute materials or remove it without holding a Hammer. A departing member loses those rights while the Squad retains the site. The final member may leave, but the Squad is not deleted: it remains an empty group with the same site identity, and no current member can see or act on that site. Removal or support loss returns all contributed materials to the ground at the site. Canonical building rule.
- Squad utilities: map pings, text chat, proximity voice and squad voice, shared respawn at squad beds, and 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 — [CONFIRMED] server-configurable
- Friendly fire within squads/clans is enabled or disabled by dedicated-server configuration.
- Anti-grief rules for shared bases (logged actions and role-gated demolition) remain part of the permissions design.
Implementation guidance
- Squad/clan membership is replicated state (likely on
PlayerState+ a server-side group registry/subsystem). - Build-privilege checks are server-authoritative in
UBuildComponentplacement 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.
Group UI contract — [CONFIRMED]
FEAT-HUD-UI includes Create, Invite Inbox, Name/Tag, member management, and roles Leader / Officer / Member, but no Search/Join browser. The Squad screen shows its logo and editable name; Upload Logo and Edit Name are Leader-only controls. Leader and Officer may invite and manage Members; only Leader may manage Officers or transfer leadership. A Leader must transfer before leaving while others remain, then becomes Officer. Build, door, and storage access do not differ by role. There is no squad roster HUD; squad world/map/compass markers and speaking state remain. The persistent activity log retains the latest 100 actor/action/target entries for invite, membership, role, identity, death and online/offline events.
Player interaction invitation — [OWNER CONFIRMED 2026-10-01]
Aim at another connected player within the existing IA_Interact reach and press Interact. Open the same Night Ops Command Ring used by the building menu, with one action: Invite to join squad. This player menu needs no Hammer and stays open after Interact is released. Mouse movement selects; LMB confirms; RMB or ESC cancels. Confirmation closes the ring without firing a weapon or creating a building preview. Player focus requires an aimed collision hit; proximity fallback does not choose players. Pawn collision that ignores Visibility still works, while a nearer wall blocks selection. The third-person camera offset does not consume the pawn's existing interaction reach; the extended player trace still checks intervening Visibility geometry and pawn-to-player distance.
The server checks range, obstruction, connected pawns, interaction stance, current Leader/Officer permission, persistence readiness, target membership and an existing pending invite before issuing an invitation. The recipient immediately sees a centered Yes / No dialog on the existing CommonUI modal layer, showing the inviter and Squad name. Use the existing Night Ops surfaces, thin borders, cyan interaction states and primary font. No opens as the initial focus. Yes requests server-authoritative acceptance; No or ESC requests rejection. Disable both responses while waiting, show a rejection if acceptance fails, and restore the previous UI/input context when the modal closes. No Squad screen or Inbox visit is required. The Squad screen's Invite action now explains this interaction flow instead of listing online targets; Inbox remains available for an outstanding invitation.
Acceptance uses the existing ULambeerSquadSubsystem::AddInvitedMember membership/activity update and dirty capture through ULambeerWorldPersistenceSubsystem / USaveSubsystem. Pending invitations remain transient; this change adds no durable fields or schema version. An invite whose sender lost Leader/Officer permission is cleared when acceptance is attempted.
Validation, 2026-10-01: LambeerEditor Win64 Development and Lambeer Win64 Development builds pass. PlayerCharacter, PlayerController and ClanSquad Blueprints compile without warnings and save through Unreal MCP. Both Lambeer.Squad.InvitePresentation and Lambeer.Squad.InviteTarget pass in non-PIE fixtures: one command, explicit initial selection, named Yes/No question, default No focus, multiline raster rendering, aimed Pawn-channel focus, self exclusion, first-/third-person reach, obstruction and focus clearing. The target fixture reports the existing unconfigured GameplayCueNotifyPaths warning; this task does not change GAS configuration. The existing Squad layout check passed and all 10 persistence tests passed earlier in this change. Validation record. Synthetic widget evidence: Command Ring, Yes/No dialog and long-name dialog. Fixtures are not gameplay captures or owner acceptance. No owner PIE result is recorded.
Owner-only PIE checklist: start Dedicated Server + two client Preview windows. Create a named Squad as Leader on client 1; aim at client 2 and press Interact without a Hammer. Verify the single action, mouse/LMB selection, RMB/ESC cancellation and no accidental shot. Confirm client 2 immediately sees the same-theme Yes/No dialog during gameplay and above an already-open Inventory/Squad screen. Test No and ESC, then reinvite and test Yes. Confirm both rosters update, a Member cannot invite, players already in a Squad or already invited are rejected, and moving out of reach or behind a wall before confirmation prevents delivery. Save/restart/rejoin and verify accepted membership persists. Retest building R release/selection and ordinary pickup interaction.
Squad UI visual selection — [OWNER SELECTED 2026-09-29]
Use Option 1 — Simple Full Roster with Logo as the selected Night Ops layout reference. The Squad screen opens from the top-edge Inventory / Squad tabs. It keeps a compact logo and display name in the header, Leader-only Upload Logo and Edit Name controls, Invite guidance and Inbox actions, a full-width member/role/status table, and the activity log below. Keep the restrained dark surfaces, thin steel borders and limited cyan focus; do not add character portraits. The example name, logo mark, members, statuses and events in the image are placeholders, not gameplay data or an implemented upload flow. Options 2 and 3 remain unselected concepts. A native ULambeerSquadScreen supplies the runtime layout behind WBP_ClanSquad; ULambeerSquadUISubsystem opens it from Inventory or the Command Ring. Owner correction, 2026-09-30: the initial runtime screenshots did not match the selected layout. Both screens must use centered Inventory / Squad tabs at the top edge, above their content panels, with Close separately at the upper right. The revision fixes the logo at 88 × 88 reference units, keeps identity and Leader controls on one compact row, aligns the three roster columns, outlines the selected member, and gives Activity its own lower panel. Edit Name opens a transient dark dialog; member management opens from the selected row without changing column widths. Activity uses readable action text and relative time with the exact UTC timestamp in a tooltip. Owner correction, 2026-09-30: keep gameplay visible behind Squad, matching Inventory. Use the Inventory shell color at alpha 0.80 on the main and Activity panels, leave the screen outside those panels transparent, and avoid opaque roster/activity row fills. Switching Inventory / Squad tabs preserves the clicked mouse position; it must not center the cursor. This supersedes the earlier opaque-background interpretation. Keep character portraits absent. Native compilation and non-PIE widget rendering are implementation checks; owner PIE visual and restart/rejoin acceptance remain pending.
Implementation evidence, 2026-09-30: LambeerEditor and Lambeer Win64 Development builds pass. Both Widget Blueprints compile and save through Unreal MCP. Lambeer.UI.SquadReferenceLayout passes without errors or warnings in the Editor world, without PIE, a pawn, RPCs or save mutations. It renders the actual Blueprint/native tree at 1672 × 941 and 1280 × 720, verifies aligned roster columns and top-centered navigation, checks that a synthetic 256 × 256 logo remains inside the compact frame, and composites the actual Squad tree over light/dark synthetic backdrops to verify that both panels and roster/activity rows remain translucent. The primary font remains the project's FF_UI_Primary. Fixture names, members and events below are synthetic; this is not owner visual approval or multiplayer acceptance. Translucency compositing evidence: light synthetic backdrop and dark synthetic backdrop; neither is a gameplay capture.
Owner PIE check: start the usual PIE session, open Inventory with Tab, verify the shared tabs above the panel, then select Squad. Compare logo/header, member column alignment, selected-row outline, and separate Activity panel with the selected reference. Confirm gameplay remains visible through the Squad panels and that the mouse stays at the clicked point when switching Inventory / Squad in both directions repeatedly. As Leader, open Edit Name and check the dark dialog, validation message and Back/Close behavior; upload a valid PNG and verify it stays inside the square frame. Agents do not start or control this test.