Body Physics¶

The Body Is Physics¶

Every character in the game (player, NPC, boss) is a physics simulation. Not a mesh driven by animations. Not a ragdoll that activates on death. A body that obeys physics every frame, the same way the sword obeys physics, the same way the arrow obeys physics, the same way everything in the engine obeys physics.

Humans have to obey physics. A body should obey physics. If anything looks weird, the physics is wrong. Fix the physics, not the animation. There is no animation.

The Skeleton¶

A human skeleton for combat purposes is ~20 rigid segments connected by constrained joints:

                    Head
                     │
                   Neck
                     │
              ┌──── Spine Upper ────┐
              │      │              │
         Shoulder L  │         Shoulder R
              │    Spine Lower      │
          Upper Arm L │         Upper Arm R
              │      │              │
          Lower Arm L │         Lower Arm R
              │    ┌──┴──┐          │
            Hand L │     │        Hand R
                 Hip L  Hip R
                   │     │
               Thigh L  Thigh R
                   │     │
                Shin L   Shin R
                   │     │
                Foot L   Foot R

Each segment is a rigid body with mass, moment of inertia, and a collision shape. Each connection is a joint with per-axis rotation limits. The physics engine handles rigid body simulation and joint constraints. The skeleton is a constrained multi-body system: entities, components, queries, and systems. The same ECS. The same weaver. The same WorkerPool. The same SoA transpose.

Mass Distribution¶

A real human body has specific mass ratios that determine how the body moves:

Scale these by character build. An angel with lighter build has different mass distribution than a demon with heavier build. The physics produces the racial combat differences, not animation sets, not stat modifiers. A heavier torso rotates slower. Longer limbs have more moment of inertia. The body is the stats.

Joint Constraints¶

Each joint has per-axis rotation limits:

• MinAngle / MaxAngle: the physical range of motion
• Stiffness: resistance to rotation (Nm/rad). Produces natural posture without animation. A joint at rest returns toward its rest angle.
• Damping: energy absorption rate. Prevents oscillation. Makes movement look controlled rather than springy.
• RestAngle: preferred resting angle. All joints at rest angles with minimal gravity correction is the idle pose. No idle animation needed.

A character standing idle has every joint at its rest angle with muscles applying minimal corrective torques against gravity. That is the idle pose. The body stands because the physics holds it up: the same way a real body stands.

The Muscle Model¶

Muscles are force generators that span joints. They are the only way the character moves.

• MaxForce: maximum torque this muscle can produce (Nm). THIS IS STRENGTH. Not a stat. A physics parameter.
• ActivationSpeed: how quickly the muscle reaches full activation (1/s). THIS IS SPEED.
• FatigueRate: how quickly sustained effort reduces MaxForce. THIS IS STAMINA. Not a bar. A muscle property.
• RecoveryRate: how quickly resting restores MaxForce.

Fatigue replaces stamina. No stamina meter. No resource bar. The character's muscles fatigue based on how much force they've produced over time. The player feels the fatigue through the physics. Swings slow down, redirects take longer, guards weaken. The player learns to manage effort the way a real fighter does. By not overcommitting, by using efficient technique, by resting between exchanges.

Character strength is not a stat. It is the MaxForce of the muscles. A stronger character's muscles produce more torque. A fatigued character's muscles produce less. A character who has been fighting for minutes has accumulated fatigue across all muscles: their swings are slower, their guard is weaker, their recovery is longer. Not because of a stamina bar. Because the muscles are tired.

Motor Control¶

The player's input doesn't directly move the body. The player's input sets intent. The motor control system translates intent into muscle activations that produce the intended movement through physics.

Player Input → Intent → Motor Planning → Body Objectives → Muscle Activations → Joint Torques → Body Movement

Intent is high-level: "move forward," "swing from the right," "block high," "slip left." The motor control system knows which muscles to activate and in what sequence to produce that movement.

For the player character, the motor control system is well-tuned: the tribrid body functions naturally. The skill expression is in the player's choice of intent (which attack, when, from where), not in the execution fidelity.

For AI characters, motor control tuning represents combat skill: - A skilled angel's motor control produces crisp, minimal-effort movements - An unskilled demon's motor control wastes energy on excessive force - The visual difference is the physics: efficient vs. inefficient force application looks different because it is different

The Control Contract¶

The action lifecycle and device-independent bindings are owned by the Player Interface and Input contract. This controller begins from an intent request; it does not reinterpret a released action or silently consume unsafe input during focus, device, or context changes.

The motor controller exists to make a physically complex body feel direct, not to make the player operate sixty joint axes. A requested action should begin producing visible response immediately; a working production target is less than 50 milliseconds from device input to the first attributable on-screen response. Weight appears in how the motion develops and resolves, not as unexplained dead time before the character obeys.

The best reachable attempt must remain recognizably related to the request. Materially equivalent intent from a materially equivalent physical state should produce a materially equivalent attempt. When the result differs, the difference must be attributable to state the simulation actually owns: stance, momentum, contact, traction, fatigue, pain, injury, equipment, obstruction, suppression, or an applied force. The controller may be imperfect while it is being proved; unexplained foot skating, idle oscillation, input lag, rubbery correction, or arbitrary refusal is a defect, not difficulty or character weight.

Player skill lives above routine anatomy. The player judges range, line, timing, target, commitment, risk, and whether to continue, redirect, guard, evade, cast, build, absorb, or restrain. The controller coordinates balance, foot placement, joint motion, grip, and force application within the body's real limits. This division lets the first action be understandable while leaving the interactions among actions hard to master.

Assistance Is Delegation¶

Accessibility and assistance operate at the input-to-intent and intent-to-motor-planning boundaries. They may remap or simplify simultaneous controls, infer a broader high-level request, hold an expressed posture, help preserve facing or guard, or delegate selection among physically reachable trajectories. They may use only information the player character is authorized to perceive.

Assistance does not change the body's mass, muscle force, fatigue, wounds, traction, momentum, swept contact, damage, enemy capability, or world history. It never adds invulnerability, aim magnetism that bends a physical trajectory, a hidden parry window, or a privileged escape. Different delegation can produce a different attempted motion; once that motion enters the simulation, the authoritative contact and consequence pipeline is identical. Replaying the same realized body and weapon trajectories must therefore produce the same result under every assistance setting.

Reachable Movement and Evasion¶

Evasion uses the ordinary motor-control pipeline. There is no DodgeState, RollDodge, invulnerability flag, or solver instruction meaning "make this attack miss." The input layer may provide a remappable movement, posture, lean, or evasion-oriented control, but it only expresses intent.

The motor planner derives objectives such as:

move the center of mass offline
lower the pelvis and head
rotate the torso
withdraw the threatened arm
preserve facing
retain as much weapon control as possible

It then derives—or, if the bounded rollout architecture proves worthwhile, searches for—a body trajectory that can approach those objectives through foot placement, support changes, joint targets, and available forces. The current support polygon, contacts, joint limits, body pose, momentum, muscle ceilings, activation speed, fatigue, pain, wounds, traction, equipment, weapon state, surrounding geometry, and genuine supernatural forces define the reachable set. An impossible request is not snapped into existence or rejected by an action gate: the body makes the best reachable attempt, which may become a short step, a slip, a stumble, a fall, or a collision.

Named movements are semantic vocabulary and may be recognized before or after execution, but they never own contact. A requested weave can clear the head while leaving the shoulder inside the blade sweep. A requested roll can be interrupted at any point. A shield carried through either movement blocks only where its real body and support place it.

For AI, combat skill includes selecting among reachable future configurations. Candidate trajectories can be scored for threat clearance, balance, support, weapon control, counterattack geometry, energy expenditure, exposure to other perceived threats, and the next reachable set. The AI uses the same controller and physical limits as the player and may score only information the character is authorized to perceive. A skilled opponent therefore finds better geometry rather than receiving a hidden dodge probability or privileged reaction.

Movement labels, near-miss classifications, and presentation are derived observations. They may describe or emphasize what happened; they cannot change the body's trajectory, the swept contact result, or the world state.

Armour as an Articulated Assembly¶

Solid plate retains its shape during ordinary character movement. Each plate has a construction-defined shape, thickness, material, mass, inertia, attachment relationship, and collision representation. The suit moves through hinges, straps, sliding rivets, overlapping lames, and joint clearances. Raising an arm rotates and slides the shoulder assembly; crouching articulates the waist and hip plates. A breastplate does not stretch across the torso to accommodate a requested pose.

This section owns the game-facing assembly and motion contract. Wounds owns injury consequences, and Build/Creation owns player authorship and fitting. HellspawnEngine's DARKFIRE_PROCEDURAL_CONTENT_DESIGN.md owns reusable fitting and equipment realization through DPC6; its Physics and controller contracts own physical execution.

Materials Determine How Equipment Moves¶

Real metal can flex elastically under ordinary loads. Rigid plate is the initial gameplay approximation, with a declared supported envelope. Consequential elastic flex requires an explicit material model. Permanent dents, buckling, cracks, punctures, and broken attachments are separate responses to load and material failure. They persist in equipment condition until a causal repair or replacement occurs. Pose-driven stretching must never stand in for either elastic flex or damage.

Rendering and Physical Authority¶

Many games blend armour vertices across several skeletal bones, which can stretch or twist apparent metal around joints. Rigid attachments and articulated pieces are already possible with conventional animation; avoiding that deformation does not depend on completing Darkfire's full physical controller. Darkfire's additional obligation is agreement among the displayed assembly, physical contacts, coverage, mass placement, and reachable movement.

Each rendered rigid plate uses a rigid transform without pose-driven scale or shear. Multiple plates can share a mesh using separate transform indices or full weight to each plate's own transform. Compatible pieces may be batched; separate plates do not inherently require separate draw calls. Actual draw count depends on materials, passes, and renderer capabilities and must be measured. A plate's transform comes from its resolved attachment or articulation, which need not coincide with a single anatomical bone.

Fixed pieces may use compound-body representations where equivalent; mobile pieces need the appropriate relative degrees of freedom. Mass and inertia must be counted once. Render LOD, batching, and physical simplification preserve the supported assembly's shape, coverage, attachment state, and history. Mail need not simulate every ring as a separate rigid body: a bounded effective model is acceptable when it preserves the stretch limits, drape, mass, and contact behaviour the game can test. Fine detail cannot depict protection or openings that contradict authoritative contact.

Fitting and Controller Cooperation¶

Procedural fitting derives plate dimensions, curvature, overlaps, gaps, pivots, strap lengths, padding allowance, and attachment locations from the body and armour pattern. It validates fit across arm raising, elbow bending, forearm rotation, crouching, turning, and weapon use. Shoulder, hip, neck, and wing clearances require their own proof cells. Fitting changes construction during manufacture or a real refit; it does not silently reshape equipped metal every frame. A changing body can outgrow its equipment.

The controller plans with the equipped body's mass distribution, inertia, contacts, and joint clearances. A poorly fitted plate can limit motion, shift within its attachments, collide, or fail under sufficient load. The best reachable attempt must remain responsive and attributable. The system cannot conceal an impossible pose by stretching plate, moving collision independently, or pushing pieces through anatomy. Well-fitted armour should retain the mobility its construction permits; rigidity is not an automatic blanket movement penalty.

Procedural owns construction and fit, the controller owns attempted movement, Physics owns contacts and loads, and rendering presents the resolved result. Constraint jitter and unintended plate-to-plate or plate-to-body penetration are defects to measure and correct. Broadly disabling relevant self-contact to obtain a pleasing pose is not a valid solution. Structural damage, separation, and repair update shared condition and derived geometry at safe publication boundaries rather than mutating topology during a solver substep.

Elbow-First Proof¶

The visual requirement is straightforward to isolate. Stable physical articulation across generated bodies is the harder engineering task. Neither is claimed as an implemented result here. Start with one articulated elbow assembly over an upper arm and forearm, including overlapping plates, attachments, and padding allowance. A prescribed motion fixture can test rigid rendering and fit before the full controller is ready; it does not prove physical control or contact stability.

For the physical fixture, bend, extend, rotate the forearm, and apply bounded impacts across fitted and deliberately poor-fit cases and several arm proportions. Declare numeric tolerances and the supported pose/load envelope before evaluating:

• Shape preservation: local plate dimensions and distances remain unchanged under ordinary motion; no scale or shear enters the plate transform.
• Articulation: hinges, sliding joints, overlaps, and attachments remain within construction limits throughout motion, including between sampled poses.
• Contact and coverage: weapons meet the displayed plates and can reach actual openings; penetration between plates and anatomy stays within declared contact tolerances.
• Load transfer: impacts propagate through plates, attachments, padding, and the body with consistent mass/inertia accounting and bounded numerical energy error.
• Control: equipped motion remains responsive and stable; poor fit produces an explainable restriction rather than jitter, clipping, or arbitrary input refusal.
• Persistence: changing render detail or saving and loading preserves fit, attachment identity, condition, and coverage. Add damage/repair round trips when those models are admitted.
• Cost: record frame cost, constraint/contact counts, and rendering cost on named hardware; one elbow does not establish a crowd budget.

Expand to a shoulder after the elbow passes, then waist/hip articulation and a complete suit across representative body proportions and equipment loads. Physical controller acceptance follows the existing bind and motor-stability gates. General metal deformation, every-ring mail simulation, and production crowd scale are separate proofs and are not prerequisites for demonstrating rigid plate movement.

Performance Expectations and Measurement¶

Rigid armour is a promising workload for Compute and Weaver, but their completion alone cannot establish a frame budget. A rigid plate needs one transform per vertex instead of a blend of several bone transforms; compatible plates can share batches. Actual rendering cost also includes geometry, materials, passes, visibility, and uploads. Fitting and clearance validation are principally manufacture/refit work. Ordinary movement updates resolved poses and contacts; it does not regenerate the suit's construction every frame.

Repeated equipment structures can expose SIMD work across characters and parallel work across independent groups. Weaver supplies valid specialized implementations; Compute selects among admitted execution plans using total cost, including scheduling, synchronization, transfers, and residency. Small encounters may favour the CPU. Larger batches may favour GPU execution when the complete pipeline pays for it. Connected contact dependencies remain real even when individual calculations become faster. Extra contacts, solver substeps, or controller search can consume the gain.

Measure the same body unarmoured, with the elbow assembly, and with a complete suit. Sweep character count, plate/joint count, independent versus interacting groups, body proportions, equipment loads, and contact-heavy motions, admitted representation/LOD states, cold versus reused residency, and shared-consumer count. Sweep or explicitly justify every other plan-selection input that could change the result before using a grid to select policy. Compare admitted scalar, SIMD, parallel, and GPU paths at matched contact and control quality. Record end-to-end frame times and tail latency, contact/constraint counts, controller work, allocation/memory, rendering, transfer/synchronization costs, and cold fitting separately from steady movement. State hardware, source revision, solver settings, tolerances, and workload, and retain raw results. Minimum-spec measurements must accompany development-machine results before publishing a gameplay performance claim.

The expected outcome is inexpensive rigid presentation and manageable physical articulation with carefully fitted assemblies. That remains a hypothesis until measured. Earlier body-only estimates do not include the new armour contacts or demonstrate a fully equipped crowd budget. General metal deformation and detailed mail add separate costs.

Balance and Stability¶

A character stays upright when their center of mass projects down within their base of support (the polygon formed by their feet on the ground). When the center of mass projects outside the base, the character falls: unless they step to widen the base or apply corrective torques.

The balance controller runs every physics tick:

1. Computes the body's center of mass from all segment positions and masses
2. Projects it down to the ground plane
3. Compares the projection to the base of support
4. Applies corrective muscle activations to maintain balance

This is what makes staggers, knockbacks, and the bind physically real:

• Stagger: An impact force displaces the center of mass outside the support base. The balance controller activates corrective muscles. The character stumbles: takes a step to widen the base. The stagger duration is how long it takes the balance controller to bring the center of mass back over the feet.
• Knockback: A larger impact force displaces the center of mass further. The character takes multiple steps. The feet scramble to catch up with the shifting center of mass.
• The bind: Both characters push against each other through their weapons. The forces propagate through the arms to the torso to the feet. The balance controller keeps both characters upright against the opposing forces. A stronger push shifts the opponent's center of mass (their balance controller compensates) their feet adjust.

Ground Contact¶

Feet are the interface between the character and the world. Foot segments have friction with the ground surface. Different surfaces have different friction coefficients: stone, mud, ice, wood.

Footwork emerges from ground contact. A sidestep is: the balance controller detects lateral intent. The motor control activates leg muscles. The foot pushes off the ground (Newton's third law: the ground pushes back). The body accelerates laterally. The other foot plants. The body decelerates. The sidestep distance is determined by muscle force and ground friction.

On ice, the friction is low. The push-off force exceeds friction. The foot slips. The sidestep doesn't work as intended. The character slides. The player feels the surface through the physics, not through a "slippery surface" debuff.

Traversal Force Integration¶

Traversal uses the same body and force state as combat. It does not switch the character to a kinematic travel object.

Ground speed remains a product of muscle or darkfire force, mass, traction, posture, slope, drag, and available stopping distance. Jump velocity inherits the body's current linear and angular momentum. At supernatural speed, the controller must manage foot placement and impulse so the body does not tear the surface, lose grip, or transfer dangerous force into nearby people and objects.

Flight adds distributed support and steering forces to the same articulated body. The controller must keep the body's centre of mass, wing or darkfire force application, angular momentum, drag, and intended trajectory compatible. Banking produces turns. Climbing and acceleration require energy. Hovering requires continuous correction. Stalls, impacts, damaged limbs or wings, loss of consciousness, and suppression can all return the body to ballistic motion under gravity.

Landing is a force-transfer problem. The body must shed horizontal and vertical velocity through air control, leg extension, surface friction, and deformation. A high-speed landing that cannot dissipate its energy becomes an impact, not a special animation.

Integration with Combat Systems¶

Footwork: Moving forward means the leg muscles are driving the body forward. Attacking during forward movement means the arm muscles are swinging the weapon while the legs continue driving. The weapon's kinetic energy includes the body's forward momentum: a thrust from a sprint hits harder because the body's mass was moving forward.

Momentum: The commitment curve is weaponMomentum > redirectThreshold × characterStrength. In body physics, characterStrength is the shoulder and torso muscles' MaxForce. weaponMomentum is the actual angular momentum of the weapon rigid body. The redirect threshold is whether the muscles can produce enough counter-torque to decelerate and re-accelerate the weapon.

Melee: The parry is arm muscles driving the weapon into the incoming weapon's path. The collision force transfers through the arm joints to the shoulder to the torso to the feet. A heavy impact stresses the arm joints, if the force exceeds what the arm muscles can stabilize, the guard collapses.

Racial differences: Angels are lighter, with longer limbs and faster muscle activation. Demons are heavier, with denser mass distribution and higher muscle MaxForce. Humans are balanced. Hybrids are mixed. The combat differences emerge from the physics of different bodies.

The Budget¶

The body model provides a workload to measure, not a frame-time calculation from segment count. Joint axes alone do not count all solver operations, contacts, limits, muscle constraints, or controller work. Kernel integration throughput cannot be multiplied by an arbitrary overhead factor to establish complete character cost. Solver frequency in hertz is not a count of substeps per rendered frame.

The earlier sub-half-millisecond projection for 100 characters is withdrawn as unproven. Use the equipment measurement contract and the engine's matched-quality rig receipts to establish complete body and armour budgets. Measure physics, control, rendering, and their dependencies together on supported hardware before promising population or frame-rate targets.

No Animation¶

There is no animation system. There are no authored clips. There are no blend trees. There are no state machines. There is a body obeying physics.

• "Idle animation" is the body standing under gravity with joints at rest angles
• "Attack animation" is muscles driving the weapon through an arc
• "Stagger animation" is the balance controller recovering from a force displacement
• "Recovery animation" is the weapon's momentum decelerating past the strike point while the body rebalances
• "Death animation" is the body going limp: muscles deactivate, joints go to zero stiffness, gravity takes over

Every fight is unique because every physics state is unique. Near-misses are real because the bodies are where the physics says they are. Staggers are real because the forces are real. The bind is real because both bodies are under real opposing forces.

If something looks wrong, the physics is wrong. Fix the joint limits. Fix the muscle force curves. Fix the balance controller gains. Tune the physics until a human body obeying physics looks like a human body. Because it is one.