Physics Foundation¶

The Paradigm Break¶

Every action game ever made is a rhythm game wearing a costume.

The player presses dodge. The game sets a boolean: isInvincible = true for 13 frames. The enemy sword passes through the player's body. The game pretends it missed. The player feels skillful. The sword visibly went through their torso. Everyone agreed not to notice.

Parries work the same way. A timing window opens. If the player presses the button inside the window, the game plays a canned animation. The physics of two weapons meeting — the angle, the force, the edge alignment — is never calculated. It's a state machine transition triggered by a button press inside a frame window.

Hitboxes are approximations of bodies. Hurtboxes are approximations of weapons. The collision between two approximations during a frame window that grants temporary invincibility is three layers of fakery stacked on top of each other. The entire action RPG genre is built on this.

The industry standardized on this model not because it's good design but because real physics for fast-moving humanoid combat at 60 FPS was never viable. The collision detection between a sword swinging at combat speed and a body dodging at movement speed requires continuous collision detection, sub-frame stepping, actual mesh-level or convex-hull contact — and doing that for every weapon, every limb, every enemy, every frame was never affordable. So the industry accepted i-frames and hitbox approximations as permanent.

Project Darkfire does not accept it.

The Engine Makes It Possible¶

HellspawnEngine was built for this game. The combat system is the reason the engine exists.

• 3 billion entities with full physics at 60 FPS. The collision budget for humanoid combat is a rounding error in a system designed for billions.
• 30,000x scalar throughput. Auto-SIMD (36x per core via IL weaving) multiplied by linear scaling to 96 cores multiplied by data layout advantages. Every artificial software bottleneck eliminated.
• 95%+ memory bandwidth utilization. The engine hits the real hardware ceiling. Everything between the algorithm and the transistors has been removed.
• Custom physics engine designed for the prefetcher (contiguous data, linear access), SIMD (vectorized operations, FMA chains), and true parallelism (no lock contention, no false sharing, work distribution that scales to every core).

The abstraction was never a design choice. It was a concession. The concession is over.

What Real Physics Combat Means¶

Every Object Exists in Space¶

Weapons, bodies, projectiles, shields, arrows, spell effects — every combat-relevant object has a physical presence every frame. Not a hitbox that activates on button press. A real rigid body with position, orientation, velocity, mass, and material properties.

A sword exists between frames. It traces a continuous path through space. If that path intersects a body, contact occurs. If it doesn't, it misses. The determination is physics, not a collision check between two approximation volumes during an activation window.

Contact Is Calculated, Not Checked¶

When two objects meet in traditional games, the engine checks whether two simplified volumes overlap. Binary: overlap or no overlap.

In real physics, contact produces: - A contact point — where on each object the contact occurred - A contact normal — the angle of the surfaces at the point of contact - Impact force — determined by the relative velocity, mass, and material properties of both objects - Deflection — the resulting change in trajectory for both objects based on the contact

A sword hitting a shield at a shallow angle produces a different result than the same sword hitting the same shield at a steep angle. The deflection is different. The force transfer is different. The sound is different. The consequence is different. None of this is approximated. It's calculated.

Mass and Momentum Are Real¶

A greatsword swung in a wide arc by a sprinting character carries kinetic energy — real kinetic energy calculated from mass and velocity. The same greatsword held still in a guard absorbs impact based on the wielder's mass and stance.

A light weapon flicked from the wrist produces a fast, low-force cut. A heavy weapon driven by full-body rotation produces a slow, high-force cleave. The player feels the difference not because of animation speed but because of actual physics response — how the target reacts, how the weapon recovers, how the wielder's body is affected by the momentum.

A weapon doesn't have a "damage stat." It has mass, velocity, edge geometry, and material hardness. The damage is what happens when those properties meet a body.

Near-Misses Are Real¶

In traditional games, a near-miss is a scripted camera moment — the developer placed a slow-motion trigger at a specific point in a specific encounter. It happens once, identically, for every player.

In real physics, near-misses happen every fight. The blade passes an inch from the player's face because the player slipped at the right moment. The arrow flies past the shoulder because the player sidestepped. The sweep goes over the player's head because they ducked. Every near-miss is unique because it's a real spatial event — two objects that almost contacted and didn't.

The cinematic moments that make Souls games memorable happen naturally, every time, because the physics is real.

No Safety Nets¶

There are no i-frames. There are no hyperarmor frames. There are no parry windows. There are no invincibility states.

If a sword is swinging at the player's body and the player's body is in the path, contact occurs. The only way to avoid contact is to not be in the path — through footwork, through positioning, through reading the attack and creating the space.

This means every hit the player takes was avoidable through better positioning. And every hit the player avoids was avoided through genuine spatial intelligence. The feedback loop is honest: you got hit because you were in the wrong place. You avoided it because you were in the right place. The game never lied to you about either.

The Window, Not the Painting¶

Every existing combat system is a painting of combat. Some are masterful paintings — Sekiro's deflection system, DMC5's combo depth, Monster Hunter's weapon weight, Elden Ring's spatial design. Each represents the highest achievement of the abstraction-based model.

Project Darkfire is the window. Not a better painting. Not a higher resolution painting. A window. Real space. Real mass. Real contact. Real consequence.

The difference is categorical, not incremental. No amount of hitbox tuning, i-frame adjustment, or animation polish bridges the gap between "checking whether two volumes overlap during a frame window" and "calculating the physical result of two objects meeting in continuous space." They are different kinds of things.

What This Requires From the Player¶

The player doesn't learn a fake language. Every action game teaches its abstractions — i-frame timing, hitbox positioning, cancel windows, combo trees. The player isn't learning combat. They're learning the game's approximation of combat.

Project Darkfire's combat teaches actual spatial reasoning — distance, angle, momentum, timing rooted in real physics. The skill transfers. A player who gets good at this has better spatial intelligence, not better muscle memory for one game's input language.

The learning curve is different from traditional action games: - Early: The player mashes and gets hit. They learn that position matters more than buttons. - Mid: The player reads attacks and moves out of the way. They learn that footwork IS combat. - Late: The player reads the fight before it happens — body language, weapon position, weight distribution — and positions to exploit openings that haven't occurred yet. They learn that spatial intelligence has no ceiling.

This mirrors the game's progression perfectly. Early absorptions are messy and involuntary. Late absorptions are precise and chosen. The combat skill curve IS the narrative skill curve. The same learning — seeing clearly, acting with understanding — expressed through the controller.

Physics Parameters, Not Stat Tables¶

Traditional games balance combat through stats: weapon damage, armor rating, health pools, resistance percentages. These are abstractions that replace physics calculations with arithmetic.

Project Darkfire balances combat through physics parameters:

No stat is hidden behind a number. Every property is visible in the object — the player can see that a greatsword is longer and heavier than a dagger. The "stats" are the physics. The physics is the gameplay.

Relationship to the Design Philosophy¶

The fusion test demands that every design moment simultaneously reveals character, embodies theme, and operates as gameplay. Real physics combat passes this test inherently:

• Character: The player's spatial decisions — aggressive closing, cautious circling, precise angling — reveal who they are. The footwork IS the character.
• Theme: The cost of absorption is physical — closing to grapple range against a real weapon. The intimacy of understanding is the intimacy of proximity. The destruction is real contact.
• Gameplay: The physics is the gameplay. Distance, angle, momentum, timing — all real, all interactive, all skill-testing.

The traditional combat system separates these — narrative weight comes from cutscenes, theme comes from dialogue, gameplay comes from frame data. Project Darkfire's physics unifies them. One system. No seams.

The game is a mirror, not a judge. The combat mirror is the most honest one — the physics doesn't lie. The sword either hit you or it didn't. What you did is what happened. The mirror reflects exactly what you put in front of it.