Feature Specification

Zombie Design

Zombies are the primary threat and feature multiple types — CONFIRMED. They provide constant PvE pressure that coexists with PvP, drive loot/resource gain, and culminate in boss encounters (see 02-Boss-Zombies.md(02-Boss-Zombies.md)).

Status: draftOwner: UnassignedUpdated: 2026-08-27

Production context

Deprecated source referenceGDD/03-Enemies/01-Zombie-Design.md
Decision markers4 confirmed · 4 recommendations · 1 TBD
Browser document roleThis standalone HTML file is authoritative; edit this file directly 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 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

Zombies are the primary threat and feature multiple types — [CONFIRMED]. They provide constant PvE pressure that coexists with PvP, drive loot/resource gain, and culminate in boss encounters (see 02-Boss-Zombies.md).

Design goals

  • Readable in third person: clear silhouettes, telegraphed attacks, distinct audio per type.
  • Threat through numbers and variety: a single zombie is manageable; groups and mixed types are dangerous.
  • Always-on pressure: zombies make every location risky, so safety must be built (base) or earned (gear), never assumed.

Current zombie roster — [CONFIRMED]

TypeBehaviorRole
Zombie_GeneralGeneral-purpose common zombie; exact stats remain data-driven.Baseline regional pressure and ordinary groups.
Zombie_HulkLarger body, higher health and attack damage, slower movement.Durable heavy threat that consumes time and ammunition.

This is the confirmed initial roster. Any additional zombie archetypes require a later explicit decision.

Behavior & AI

  • States: idle/wander → alerted (investigate sound/sight) → chase → attack → search/lose-target → return.
  • Senses: sight (cone + range) and hearing (gunfire, sprinting, vehicles are loud). Stealth (crouch, suppressed weapons) reduces detection — [RECOMMENDATION].
  • Implementation: the project already enables StateTree and GameplayStateTree plugins — [RECOMMENDATION] drive zombie AI with StateTree (modern, data-friendly, performant) rather than Behavior Trees. Use EQS for target/danger queries (the existing combat template already includes EQS contexts).
  • Weak points (head) give bonus damage; some types have armored zones. See ../01-Gameplay/03-Combat-System.md.

Spawning & density

  • Density controls — [CONFIRMED]: dedicated-server settings define the global density multiplier, while each authored region defines its own local density rate. Effective density combines the server-wide setting with the regional value.
  • Dynamic horde events — [CONFIRMED as zombie role]: periodic roaming hordes / surge events that create emergent pressure and pull players (and PvP) together. Triggered by timers, noise, or activity. Event design/cadence is [TBD].
  • Spawn managed by server-side spawners/volumes with caps to protect performance.

Networking & performance — [RISK]

  • Many AI agents + ~40–60 players is a major server CPU cost. Mitigations: AI LOD (cheap logic when no players near), capped active counts, spawn/despawn by relevancy, and efficient pathfinding. [RECOMMENDATION] evaluate Mass/MassAI for large crowds if hordes must be very large — but only if needed; classic AIController + StateTree is simpler for moderate counts.
  • Zombies are server-authoritative; clients receive replicated transforms/states.
  • Visuals: zombies must not be full MetaHumans — use optimized skeletal meshes with shared materials and aggressive LODs. See ../06-Art-Audio/01-Art-Direction-and-MetaHuman.md. Body blood stains use the shared visual contract (per-mesh mask + BloodAmount): ../01-Gameplay/10-Blood-Visual.md. Rain wetness uses WetAmount on the pawn (visual only in v1; no AI change from rain): ../01-Gameplay/11-Wetness-and-Rain.md.

Implementation guidance

  • A base AZombieCharacter (C++) with a UZombieStatsComponent-style setup; type differences are data-driven (HP, speed, damage, senses, attack set) plus per-type StateTree where behavior diverges.
  • Reuse damage/health model with the player (shared damage system; [RECOMMENDATION] GAS).