|
|
PixelBullet
0.0.1
A C++ game engine
|
Weapon combat and loadouts are owned by framework/scene_play. Presentation is a separate, optional layer documented in Weapon Presentation.
ActorWeaponLoadoutComponent defines an actor's logical weapon slots. Each ActorWeaponSlot has:
The component carries an authored activeSlot. Runtime state copies the authored default and owns the current active slot for the run. Slot selection by ID or enabled-slot index produces inspection records and cancels combat work that cannot continue on the inactive slot.
The world weapon entity is the logical identity that connects combat, animation, world presentation, and inspection. It is not merely a rendered mesh. A valid combat binding requires the loadout, active enabled slot, world weapon entity, and prefab instance expected by the slot/profile contract.
.weapon_combat_profile.yaml assets are framework-owned schema. A profile may define a world weapon prefab and primary hitscan behavior:
The active-pawn combat path resolves the active logical slot and loads its profile. It owns trigger gating, cadence, hit selection, ammo consumption, reload start/completion, slot-switch cancellation, damage events, and hitscan discharge facts. Aim-ray selection and physical hit testing remain controller responsibilities; presentation cues do not decide damage.
NPCs may use RangedHitscanAttackComponent directly through the combat controller. That path owns its range, damage, cooldown, timing mode, notify, origin socket, occlusion, and damage application without requiring a weapon combat profile.
If a logical loadout is available, the resulting discharge may carry a weapon slot and world entity for presentation. A missing loadout does not block the direct NPC ranged attack; it produces an explicit missing-presentation binding status. This is an intentional bypass, not profile-backed player weapon combat.
Runtime inspection exposes active loadout binding, selected slot, combat-profile status, magazine/reserve state, reload state, active-pawn combat facts, combat agents, combatants, and emitted discharges. Runtime UI projects this into slot bindings and an ammo/reload HUD. BulletSketch's playtest diagnostics consume the same inspection surface.
| Coverage | Scenes |
|---|---|
| Complete multi-slot player combat | @shared/scenes/humanoid_weapon_slots_first_person_runtime.scene.yaml |
| Complete pistol combat and owned-view/world variants | @shared/scenes/humanoid_pistol_first_person_runtime.scene.yaml, humanoid_pistol_third_person_runtime.scene.yaml, humanoid_pistol_player_runtime.scene.yaml, and related humanoid pistol scenes |
| Integrated NPC and encounter pressure | @shared/scenes/behavior_lab_combat.scene.yaml and @shared/scenes/combat_lab.scene.yaml |
| Reduced gameplay-lab integration | @shared/scenes/level_slice.scene.yaml and level_slice_exit.scene.yaml |
Level Slice and Combat Lab carry a player logical combat loadout and combat profile but do not carry ActorWeaponPresentationLoadoutComponent. They prove combat integration, not the complete owned-view/world presentation contract.
Focused proof includes weapon profile schema, slot input, fire/reload, ammo, notify/socket, NPC ranged attack, damage lifecycle, runtime HUD, and representative session suites.