ThreeDream - FPS arena

builtin 8 bots policy — batch — 0 fps

W A S D: move
mouse: look
left button: fire
shift: sprint
R: reload
esc: release mouse

Every bot you are shooting at is being driven by the policy this repo trained, at 60 fixed steps a second. Nothing on this page is scripted.

Match over

—

Loading policy…

Round

objective: —
time left: —
kills: —
deaths: —
shots / hits: —
accuracy: —
bots alive: —

Not built yet.

Policy

task: —
network: —
parameters: —
file size: —
load time: —
episodes: —
trained backend: —
seed: —
greedy success: —
greedy mean gap: —
inference mode: —

The artifact is text on purpose: it is diffable, it round-trips bit-exactly to the Float32Array the trainer held, and it is read once. README.md tabulates what that costs at four network sizes against the per-step forward pass.

Batch

rows / step: —
chunks: —
ms / batch: —
µs / row: —
buffer capacity: —
regrows: —

Simulation

steps / frames: —
steps per frame: —
ms / step: —
ms / frame: —
fixed dt: —
bodies: —
wall contacts: —
catching up: —
digest: —

Render

three.js backend: —
device shared: —
draw calls: —
triangles: —
bot meshes: —
meshes per bot: —
shadows: —
pixel ratio: —
three.js: —

—

Assets

character: —
weapon: —
file: —
engine parse: —
meshes / verts: —
joints / clips: —
height → scale: —

—

Log

The arena you see is the array of body descriptors the session handed to the physics backend, and a bot is its own two hit spheres at their real radii, so what the raycast saw is what you are looking at. FpsView reads the session once per frame and writes nothing back, which is why ?steps=600 runs the same match with no renderer in the process and produces the same digest as tests/fps_session.test.ts asserts in bare Node.