How the physics work

What TESTBOX simulates, and how we know it's right. Nothing here is animated or faked. It's real physics, tested against real fights.

The simulation Spinning weapons Collision shapes Drivetrain Damage Structural damage Checking it Determinism

The simulation

Every bot is a set of rigid bodies built from its CAD: chassis, wheels on axles, and a weapon on its own bearing, each with real mass and inertia.

The world steps 2,500 times a second, so a weapon hit plays out over several steps instead of skipping through. It's built on MuJoCo, an open-source physics engine made for robotics research.

2,500 Hzphysics steps
60 Hzcontrols and screen
Built from its own parts, with each part's mass and material taken from the CAD.

Spinning weapons

Spin up a weapon and you've built a gyroscope. Turn a drum or vertical spinner hard and it rolls onto one wheel. Knock a horizontal spinner off level and it fights back.

None of that is scripted. The weapon is its own spinning body with inertia measured from the CAD, so gyroscopic precession comes straight out of the equations of motion.

The weapon is its own spinning body, with its inertia taken from the CAD.

Collision shapes that keep every tooth

Bite comes from a tooth's rake angle. Physics engines collide convex shapes, and wrapping a toothed weapon in one convex shell fills the gap behind each tooth, which flattens the rake and kills the bite.

The importer splits the weapon at the root of every tooth, so each face keeps its real rake angle, and then checks the result against the CAD. On this three-tooth disc, one shell keeps 30% of the bite and the split version keeps all of it.

One convex shellSplit at each tooth
Left: a three-tooth weapon outline wrapped in one convex shell that fills the gaps behind the teeth. Right: the same outline split into three convex pieces that keep each tooth's gap.
The importer's output for a three-tooth disc. Black is the CAD outline and the colored areas are the collision pieces.

Drivetrain and air

Wheels are driven by motor torque, tires flex and slip, and weight shifts as you turn and brake. Weapons lose speed to air drag fitted to their own shape.

The game runs exactly the same physics as our test tools, so what we measure is what you drive.

Wheels, axles and the weapon are each their own body.

Damage today

Damage is the energy your weapon actually puts into the other bot. Wall hits, floor hits and glancing blows don't count, but clean, solid hits do.

Only energy delivered through the weapon counts.

Structural damage In progress

Next up: parts that bend and break. At import, each part gets a finite-element analysis from its real shape and material, which gives how stiff it is and how much load it can take before it yields.

A prototype already does this for single parts, like the UHMW leg below.

Finite-element results for a UHMW leg: deformation under bending in two directions and under torsion, colored by stress.
Prototype FEA on one part, bending two ways and twisting, colored by stress. Brighter is closer to yield.

Checking it against real fights

We built a computer-vision tracker that follows bots through overhead video of real fights. That gives real trajectories to hold the sim against: acceleration, turning, recovery, and what happens after a hit.

Every physics change is measured against those, and against controlled tests, before it ships.

Real footage → tracked positions → compared with the sim

Side-by-side comparisons with real fights will go here once we have permission to show the footage.

Determinism

The same inputs give the same fight, bit for bit, on Mac and Windows. That's what keeps online play fair and replays exact, and it lets a disputed result be settled by re-running it.

How online play uses this

Same inputs, same fight

Every match ends with both machines holding an identical fingerprint of the fight state. If they don't match, the match is flagged.

Questions about the physics?

If something about how your bot behaves looks wrong, we want to hear about it.

Join the Discord