Players operate as Agents. Official media establishes the player-facing action, while named records require page-level community verification before the archive attaches biography, allegiance, mechanics, or story claims.
Player role
Start with the player-facing Agent record.
The official experience and its media support a stable orientation: the player enters as an Agent inside a co-op survival experience with a maximum server size of five. That is enough to define the primary record without inventing a protagonist, canonical appearance, or fixed squad composition. An Agent page should connect the player to perk roles, trait slots, weapons, supplies, the scavenging-and-defense loop, and the evacuation objective.
Official imagery is used as action context rather than as a portrait database. The frame below depicts the experience’s player-facing world, but the archive does not crop figures into named portraits or assign identities that the media record does not provide. A dedicated named-character page should receive imagery only when a source binds the image to that record.
Signature record
Agent case file and system links.
- Player role
- Agent
- Maximum server size
- 5 players
- Active trait limit
- Up to 3
- Perk role groups
- Basic · Frontline · Backline · Support
The case file is deliberately compact. It records the stable facts that change how the rest of the wiki is navigated: a player is an Agent, the server supports up to five players, current community data lists a maximum of three active traits, and the current perks index organizes entries by Basic, Frontline, Backline, and Support. Each field points to a system route rather than pretending the Agent record contains every mechanic.
The comparison table below keeps roles and records separate. “Agent” identifies the player role. Allies, raiders, bosses, and story or ending records are browsing families observed in the community route surface. A row’s existence means the archive has a place to verify it; it does not assert current allegiance, spawn behavior, or narrative status.
4 records
| Record family | What is confirmed here | Next verification |
|---|---|---|
| Agents | Player-facing role and system links | Perk, trait, equipment, and walkthrough routes |
| Allies | An Allies index route is observed | Verify each named record and relationship on its source page |
| Raiders and bosses | Official description names militarized raiders; boss routes are observed | Verify encounter mechanics and current status separately |
| Story and ending records | Named and ending routes exist in the community surface | Keep narrative claims bound to a dedicated source |
Observed names
Browse names without importing unsupported dossiers.
The current community route inventory exposes named records including Adrian, Agent “Jericho,” Deadeye “Ilija,” Defector “Daemon,” Sledge Queen, and Yosef. Those names are useful search targets, but the inventory alone does not establish whether a record is playable, allied, hostile, historical, event-specific, or narrative. This page therefore presents them as observed records and sends detailed claims to a future page-level review.
That boundary prevents two common wiki errors. First, a redirect or duplicate title can be mistaken for a second character. Second, a combat guide, boss-wave page, or ending route can be collapsed into biography. The archive preserves the exact observed label and the type of source check still required, making later expansion traceable instead of speculative.
6 records
| Observed record | Observed route surface | Required before detail |
|---|---|---|
| Adrian | Named community page | Identity, role, and current relevance |
| Agent “Jericho” / Jericho | Two related route labels | Redirect or distinct-record relationship |
| Deadeye “Ilija” / Ilija | Two related route labels | Alias relationship and source scope |
| Defector “Daemon” / Daemon | Two related route labels | Alias relationship and encounter context |
| Sledge Queen | Named page plus combat-guide surface | Current role, encounter, and mechanic source |
| Yosef | Named community page | Current role and narrative boundary |
Operational identity
Use character records to clarify team responsibility.
For play, the most useful character question is often not “who has the longest biography?” but “what responsibility does this Agent own during the current cycle?” Perk role, selected traits, weapon category, ammunition needs, and carried supplies create a temporary operational identity. The squad can change that identity whenever recovered equipment or an injury shifts the plan.
A character page should therefore link outward. Agents connect to perks and traits for loadout shape, weapons and items for resource demands, enemies for threat vocabulary, and the walkthrough for timing. Named allies or hostiles connect to their source-specific encounter or story records. This graph keeps the character archive practical while respecting the difference between a player build and a narrative entity.
The result is a roster that can grow without a generic portrait wall. Records earn dedicated pages when the available source can support an identity, relationship, mechanics section, current status, and media treatment. Until then, the observed-name table remains the honest index.
Frequently asked questions
Are all names in the table playable characters?
No. The table records names observed in the current community route inventory and explicitly avoids assigning playability, allegiance, encounter type, or story status from the title alone. The verified player-facing role on this page is Agent. Each named record needs its own source review before receiving a detailed dossier.
Why does the Agent case file link to system pages?
An Agent’s practical role is shaped by perk grouping, up to three active traits, equipment, supplies, and the squad’s current task. Linking those systems keeps the record useful during play and prevents the character page from duplicating volatile mechanics that belong in dedicated databases.