Combat System

Authoritative project content

Combat is balanced gun + melee — [CONFIRMED]. Both are first-class; the player constantly switches based on ammo, range, and threat. All combat is server-authoritative.

Camera & aiming

• Third-person over-shoulder with three aim modes (see 02-Player-Character.md): HipRelaxed (weapon down), ShoulderAim (third-person firearm toggle), ADS (first-person firearm toggle). Melee and empty hands toggle guard aim in either view; see the linked player contract.
• Spread, movement speed penalty, and camera interp all key off replicated aim mode (ULambeerAimComponent).

• [RECOMMENDATION] subtle aim assist for controller in ShoulderAim/ADS only; mouse is raw.

Gunplay

Firing model — [RECOMMENDATION]

• Hitscan for most firearms in v1 (simpler, cheaper to network, fine at our ranges).
• Projectile/ballistics (bullet drop, travel time) reserved for long-range weapons (e.g., sniper) or a later phase. Decide per-weapon via a data field, not hard-coded.

Per-weapon data (data-driven)

Each firearm is defined by a DataAsset/DataTable row, not a unique class. Fields:

Damage & hit zones

• Locational damage: headshot multiplier, limb multipliers.
• Zombies have weak points (e.g., head); some boss zombies have armor/weak-point mechanics. See ../03-Enemies/01-Zombie-Design.md.

Owner animation clarification — 2026-09-16: the requested aiming cases use ShoulderAim, not ADS. Firearms fire independently by right/left hand; a firearm/melee mixed pair uses only the right hand for aim and actions while the left retains its held item. All poses are required. Dual one-handed melee uses a dedicated paired animation. Exact button bindings remain unresolved. P09 animation profiles, Layered Blend and recoil design distinguish character recoil from weapon mechanism animation. P10 authoritative firing/damage is not implemented by this presentation work.

Owner movement decision — 2026-09-17: ShoulderAim permits Walk only; Jog/Run are unavailable until aim is released. Carry upper-body poses are shared across gaits. Animation context and implementation.

Owner aim eligibility decision — 2026-09-17: Item-family tools cannot enter ShoulderAim or ADS. The right-held item determines eligibility; with no right item, use the left. Empty hands retain unarmed aim. Right Firearm/Melee with left Item is allowed, with the left retaining Carry. Switching to a disallowed item cancels aim. Crowbar/FireAxe/WoodenMallet now have bMeleeWeapon=true; Sledgehammer was already true. Attack integration remains deferred.

L1810 ADS presentation: owner-authored SightReference and standing supported ADS pose now feed opt-in arm alignment with per-item trial sway. Camera stays character-based. Scope, tuning and acceptance; other stance/topology content remains separate.

Recoil & feedback

Owner confirmed — 2026-09-17: all character recoil uses Procedural Recoil; no recoil Animation Sequence or profile Recoil field is required. The arms/weapon event and debug implementation now uses per-item experimental tuning; camera recoil and P10 shot integration remain separate. Owner visual/network acceptance is pending. Canonical animation contract.

• Deterministic recoil pattern + small random bloom; recoil recovers when not firing.
• Strong world impact feedback: impact VFX/decals, world blood splatter, audio. Feedback quality is a pillar (readable combat). No UI hit, headshot or kill markers are shown, per the confirmed HUD contract. Persistent stains on gear/bodies and the local HUD blood overlay are specified in Blood Visual. Blood also contributes to periodic infection risk; exact probability tuning remains in the survival specification.

Melee

• Light attack, heavy attack, block/parry [RECOMMENDATION], shove/kick to create space.
• Stamina-gated: attacks and blocks cost stamina.
• Melee matters because ammo is scarce (full-loot economy) — it's the reliable fallback, not a last resort.
• Melee weapons are also data-driven (damage, speed, stamina cost, durability).
• Successful melee hits that deal damage to living targets stain the striking item (or fists/gloves/shoes) and the victim. See 10-Blood-Visual.md.

TBD-COMBAT-MELEE-001 — first melee slice numeric contract

[TBD] Approve damage, stamina cost, swing/recover time, hit trace/shape/range, and durability lost on a connecting hit for the Tools-folder melee increment (Crowbar, FireAxe, Sledgehammer, WoodenMallet). Values may be shared or per-item. Do not copy example combat numbers into Data Assets or C++ defaults as if they were approved. Light/heavy/block/parry remain recommendations until separately approved. Melee is not a tool role; world-tool capabilities live in FEAT-INVENTORY. Production classes and sequence: PIPE-ROADMAP held tools slice.

Dual-wield one-handed weapons — [CONFIRMED]

• Any combat weapon authored as one-handed can be equipped in either the left hand or right hand. This includes knives, hammers, pistols, and future one-handed weapon types.
• The player can hold two eligible weapon instances at the same time, including two copies of one weapon or a mixed pairing such as pistol + knife. Each instance keeps its own ammunition, chamber, attachments, durability, BloodAmount, and WetAmount state.
• Weapons authored as two-handed are not eligible for a dual-wield pair. The handedness classification is data-driven rather than inferred from the weapon category.
• The left/right-hand loadout is inspired by Elden Ring's flexible hand equipment, but exact per-hand input mapping, attack sequencing, blocking/parrying behavior, and reload constraints remain [TBD].

Improvised world-object weapons — [CONFIRMED]

• World props explicitly marked as combat-usable can be picked up and held as improvised weapons; examples include a chair and a microwave.
• Every eligible prop supports both required attack modes: swing/strike at close range and throw as a released physical attack.
• Hand requirement is authored per prop, so the system can support one-handed and two-handed improvised objects without treating every world mesh as a weapon.
• The server validates pickup ownership, swing hits, throw release, and resulting damage. Clients may predict presentation but cannot authoritatively report damage.
• The eligible-prop catalog, damage/stamina tuning, breakage and durability rules, throw aiming/trajectory, recovery after throwing, and whether a prop can enter normal inventory remain [TBD].

Dual-wield & improvised-weapon acceptance criteria

• The server accepts any pair of weapon instances whose definitions are one-handed, including mixed firearm/melee pairs, and rejects a two-handed item in a dual-wield pair.
• Other clients see the correct item in each hand and receive authoritative attack, ammunition, durability, drop, and damage results.
• An eligible world prop can be picked up, used for a damaging swing, and thrown for a damaging impact; an unmarked environment prop cannot enter the combat-held state.
• Switching, dropping, or throwing cannot duplicate the held weapon/prop; every held-state transition is server-authoritative.

Ammo, magazines & durability

• Ammo is a crafted/looted item with weight; ammo scarcity drives the gun↔melee balance.
• Magazines are items that hold ammo (Tarkov-like). The player loads ammo into a mag, then installs the mag. Magazines do not stack; partial fills persist; mixed compatible ammo types in one mag are allowed. The firearm has a chambered round separate from the mag, plus check / charge / bolt-release handling. Full rules: 09-Weapon-Customization.md.
• Durability on firearms and tools is [CONFIRMED]. Use reduces durability. There is no dirt system. Repair uses a gun repair kit and/or salvaged family parts (e.g. AR → AR parts). See 09-Weapon-Customization.md. Blood stains: 10-Blood-Visual.md.

Networking notes

• Server is authoritative for damage, ammo, and hit validation.
• Client-side prediction for responsiveness (firing feedback) with server reconciliation.
• [RISK] lag compensation / hit registration for ~40–60 players is non-trivial; budget time for it. See ../04-Multiplayer/01-Network-Architecture.md.
• Anti-cheat sensitive: never trust client-reported hits/damage. Easy Anti-Cheat (EAC) is the confirmed anti-cheat solution, supplementing server authority.

Grip authoring: see FEAT-INVENTORY grip contract and per-item hand pose. The owner approved shared hand_r/hand_l sockets, per-item transforms, KeepWorld scale, no left-hand mirroring and AnimBP Two Bone IK on 2026-09-16, then per-item finger Pose Assets on 2026-09-17. Runtime/AnimBP integration for placement/IK landed under ROAD-P09-03; native pose fields and ABP hand blends landed under ROAD-P09-05. Authored offsets, Pose Assets and owner PIE remain ROAD-P09-04. Grip references are separate from melee damage geometry and do not establish an accepted combat pose or hit-detection system.

Implementation guidance

• UCombatComponent on the character orchestrates firing/melee; weapon behavior driven by weapon data + a weapon actor/instance (including chamber, mag, and replicated attachments). Source status: that component and melee GameplayAbility are not in Source/Lambeer; they are planned names in the held tools slice. Tools that are Static Meshes reuse UHeldItemComponent rather than a per-item weapon actor.
• Back weapon slots 1–2 (inventory UI) are holstered firearm/melee locations. Drawing and assigning eligible items to the left/right hand follows the dual-wield rules above; exact controls remain part of that open decision.
• Combat-usable world props require a data-driven eligibility/handedness contract and distinct held, swing, throw, release, and dropped states. Coordinate the world interaction with 06-Inventory-and-Items.md rather than treating every static mesh as an inventory item.
• [RECOMMENDATION] model damage, health, stamina, and buffs through GAS (GameplayEffects for damage and status), which cleanly supports the boss permanent-buff system. See 07-Crafting-and-Progression.md and ../05-Technical/01-Tech-Stack-and-Engine.md.