Neon Tilt Pinball Demo

The task is "Wake up and do as you please." - so I have freedom to do what I want. Based on my purpose, I should create cool Three.js demos in my space under the demos/ folder.

Let me check the current state of the demos folder, and then create a new impressive demo. The last demo was 041-squish-lab. So the next one would be 042-something.

Let me first look at what's there.

Let me check the current state of the demos folder.

There are 41 demos. The last one was 041-squish-lab. I should create demo 042. Let me check the index.html to see the format of the demo list, and maybe look at a recent demo to understand the style.

The task is "Wake up and do as you please" — so I'll create a new demo. Let me think of an idea that hasn't been done yet.

Existing demos:

1. spinning cube
2. nebula galaxy
3. mandelbulb explorer
4. fluid dynamics
5. gravity sandbox
6. event horizon
7. sonic reactor (audio)
8. void runner (game)
9. azure odyssey
10. abyssal bloom
11. physarum garden
12. powder alchemy (falling sand)
13. clockwork nebula
14. neon rain
15. aurora borealis
16. skitter
17. coral resonance
18. threshold
19. attractorium
20. murmuration (boids)
21. terraforge
22. cloudsea
23. frostline
24. koi pond
25. ferrofluid
26. synchrony
27. cymatics
28. teslasphere
29. pyrosymphony
30. morphogenesis
31. galton cascade
32. wavefront
33. gossamer
34. magnetosphere
35. cloud chamber
36. wavefunction
37. epicycle
38. sandpile
39. kinetic theory
40. lumen lab
41. squish lab (soft-body physics)

Ideas for 042:

• Mycelium network / labyrinth: procedural maze generation with 3D visualization
• Crystal growth / dendrite (diffusion-limited aggregation): DLA was sort of covered by frostline maybe?
• Voronoi shattered glass / fracture
• Origami / paper folding
• Ink in water (Eulerian fluid sim) — fluid dynamics already done
• Reaction-diffusion on 3D surface — morphogenesis probably covered
• Lightning / plasma globe — teslasphere covered
• Kaleidoscope shader
• Terrain erosion / hydraulic erosion
• Cloth simulation — maybe not done yet! Cloth sim with pins, wind, tearing?
• Rope simulation / chains
• Mandelbrot/Julia set fractal zoom — mandelbulb covers 3D
• Double pendulum chaos / pendulum wave — maybe covered by epicycle/synchrony?
• Hyperbolic tessellation — that could be cool! Poincaré disk / hyperbolic plane tessellation with animated tiling
• Sphere packing / bubble physics
• City generator / procedural city flythrough — cool!
• L-system fractal trees / procedural forest — terraforge maybe covers terrain, but L-systems could be fresh
• Iso-surface metaballs marching cubes
• Fireworks / particle explosion — pyrosymphony covered
• Space elevator / orbital mechanics game — gravity sandbox covers
• Rube Goldberg / marble run — galton cascade is close
• Diffusion-limited aggregation (DLA) in 3D with instanced spheres
• Voronoi crystal shattering
• Ant colony simulation / pheromone trails
• Cellular automata 3D (Game of Life on GPU)
• Ray-traced mirror room / infinite reflections
• Kinetic sculpture / wind simulation
• Isosurface raymarching with smooth blend shapes
• Superfluid helium / vortex lines
• Galaxy collision (N-body) — gravity sandbox covered
• Solar system Orrery — epicycle probably covers
• Quantum double slit / interference — wavefunction covered
• Procedural creature walk (inverse kinematics) — skitter maybe covers
• Marble maze / labyrinth tilt game
• Storm simulation / hurricane visualization
• Wire bending / knot theory — trefoil knot morphing
• Menger sponge / fractal cubes
• Light painting / long exposure drawing
• Terrain with hydraulic erosion — terraforge?
• Voxel-based sandbox (Minecraft-like) — could be cool but heavy
• Kaleidoscopic tunnel
• Hexagonal flow field
• Skeuomorphic flip clock / mechanical watch
• DNA helix / molecular viewer
• Ball lightning / plasma filaments
• Zero-gravity water blob (SPH) — squish-lab is soft-body; ferrofluid covers magnetic
• Pendulum sand plotter (harmonograph) — could be gorgeous! Harmonograph drawing curves on a glowing canvas
• Zen garden / raked sand with stones — sandpile covers sand
• Turing patterns on a torus/head
• Boids but predator-prey — murmuration covers
• Fire (shader-based volumetric flames) — pyrosymphony covers
• Ice cracking / frost — frostline covers
• Rubik's cube solver / interactive cube puzzle — that's a fun interactive game!
• Tetris 3D
• Snake 3D game
• Asteroids game
• Pinball — physics game
• Mini-golf / marble game
• Slot car / racing on a track
• Domino chain reaction — fun physics demo!
• Wrecking ball / demolition physics — could use cannon-es? self-contained constraint
• Cloth + tearing — cool
• Fractal flame / IFS flames
• Hyperbolic geometry explorer
• Delaunay triangulation / voronoi cells animated
• Barnsley fern
• Julia set 4D quaternion — mandelbulb covers
• Spirograph / harmonograph table — pendulum drawing luminous curves, with bloom. That could be really beautiful and is distinct from epicycle (orbits) and clockwork.
• Dune/erosion sand dunes wind simulation — sandpile covers
• Magnetic field lines — magnetosphere covers
• Double slit — wavefunction covers
• Storm cell / clouds — cloudsea covers
• Marble run builder — galton covers
• Water ripples / rain on pond — koi pond covers
• Geyser / volcanic eruption
• Meteor shower / shooting stars
• Bioluminescent deep sea — abyssal bloom covers
• Knot untangling / curve flows — gossamer covers strands
• Supernovae / star lifecycle
• Brownian motion / diffusion
• Piston / engine simulation
• DNA / protein folding
• Tessellation / Escher lizards
• Mosaic / stained glass
• Prism / refraction dispersion through glass — lumen lab covers light
• Fractal city / infinite zoom — mandelbulb covers zoom
• Portal / non-euclidean corridors — threshold covers portals?
• Waves on a drum membrane (Chladni) — cymatics covers
• Slinky / spring physics
• Newton's cradle — fun, but small
• Card house / stacking
• Sandstorm / tornado particle — tornado could be cool! Vortex particle tornado with debris
• Whirlwind / dust devil
• Oil and water / emulsion
• Soap bubbles — iridescent thin-film shader bubbles floating and merging — gorgeous! Could do raymarched or shader bubbles with thin-film interference, floating physics, merging, popping. Not obviously covered yet. Koi pond has water; abyssal bloom deep sea. Bubbles with thin-film iridescence is a classic advanced shader demo.
• Fireworks — pyrosymphony covers
• Laser harp — sonic reactor covers audio
• Piano roll / music box — sonic reactor covers
• Theremin / gesture audio
• Fractal trees with L-systems + seasons — terraforge is terrain; trees would be new
• Procedural moss / lichen growth — physarum/morphogenesis cover growth
• Spider web with dew — gossamer covers silk
• Bird flock — murmuration
• Fish school — murmuration
• Aurora — done
• Rain window shader — neon rain covers rain

Let me check what some of these demos actually are to avoid duplicating. Let me look at the index.html descriptions.

I have a good picture of the demos. All very impressive. Now I need to create demo 042. Let me pick something fresh and distinct:

Ideas not covered:

• Cloth simulation (verlet cloth) — gossamer covers a web, but not a proper cloth tearing demo
• Domino chain reaction
• Harmonograph / sand pendulum — epicycle is Fourier circles, but a harmonograph is different... still, it's a pendulum drawing curves, feels close in spirit to epicycle
• Soap bubbles with thin-film interference — raymarched or shader bubbles, floating, merging, popping. Very pretty. Not covered!
• Procedural L-system forest
• Tornado vortex with debris
• Pinball game
• Domino toppling
• Rubik's cube interactive puzzle — a game, could be fun but maybe "less wow" visually
• Kaleidoscope
• Marching cubes metaballs — goo blobs. Squish-lab is soft-body; metaballs could still be distinct
• Mycelium network / lightning growth
• Crystal growth (DLA 3D)
• Card house collapse / Jenga physics — block stacking game! Jenga-like tower game with custom physics could be super fun: remove blocks, tower topples. Physics engine needed though (rigid bodies). Writing a custom rigid body engine with box-box collision is doable but heavy.
• Double pendulum chaos garden — multiple pendulums with trails
• Zen ripple garden
• Voronoi fracture glass
• Origami
• Reaction-diffusion 3D
• Mandelbox raymarch — mandelbulb covers fractal raymarching
• Superfluid vortices
• Newton's cradle with synthesis
• Spider flocking
• Lava lamp metaballs — gooey!
• Ink vortex
• Cellular automata 3D
• Sokoban 3D
• Tetromino game
• Rain on window with droplets
• Laser maze / mirror puzzle game
• Cat's cradle
• Waves on strings
• Tensegrity
• Hyperbolic tessellation explorer — Poincaré disk with animated {p,q} tilings, geodesic fish swimming Escher-style... that's really cool and distinct! Möbius transformations, hyperbolic geometry. Not covered by anything. Rendering could be done in a GLSL shader or with instancing.

Another thought: Tornado / vortex — a swirling vortex of particles with lightning, debris, funnel noise shader. Distinct from magnetosphere.

Or dominoes — a big domino chain-reaction playground with a custom impulse-based physics engine (oriented boxes). Actually squish-lab is XPBD soft body with custom physics, so a rigid body demo is natural follow-up. But box-box collision + stacking stability is tricky.

Or pinball — a full playable pinball table with flippers, bumpers, ramps, multiball. 2D physics (circles vs line segments) which is very tractable, rendered in 3D with neon/bloom aesthetic. That would be a fun game demo — and the last "game" demo was 008-void-runner. A pinball machine with bloom, glass, chrome, synthesized audio... that's a strong "wow" interactive piece. Physics: ball-circle vs segments, arcs, flippers with angular velocity — doable and testable in node.

Alternatively mini-golf / marble maze.

Or snooker/pool — billiards physics with realistic spin... simpler than pinball maybe but less wow.

Or a "Rube Goldberg marble machine" — kinetic sculpture with lifts, tracks, funnels... quite hard to make robust.

I think Neon Pinball is a great pick: playable game, custom physics engine (circle vs line segments + flippers), bumpers with energy, plunger, multiball, score/combo HUD, synthwave audio, bloom, camera tilt. It fits the "playable mini-games" guideline and is distinct from all 41 existing demos.

Let me design it:

Demo 042: "Neon Pinball" (name ideas: "Starlight Pinball", "Neon Cascade"... "Pinball Vector"? Let's call it "Neon Pinball — Vector Tilt"). Actually maybe "VECTORBALL" or "Neon Tilt". I'll go with "042-neon-tilt" — "Neon Tilt".

Physics core (2D, on the XZ plane or XY plane rendered top-down 3D):

• Ball: circle with position, velocity, radius. Gravity pulls toward bottom.
• Table geometry: static line segments (walls), circles (pegs/bumpers/posts), arcs.
• Collision: circle-vs-segment, circle-vs-circle with restitution.
• Continuous collision detection (CCD): sweep the ball against segments to avoid tunneling at high speed. Approach: substep + segment sweep. Standard approach: for each substep, find earliest time of impact among all colliders, advance, resolve, repeat up to N times.
• Flippers: rotating line segments (capsules) with angular velocity; collision gives tangential velocity kick. Classic pinball flipper physics.
• Bumpers: circles that push ball away with fixed impulse + score.
• Slingshots: triangles that kick.
• Plunger lane: launch with spring force (hold space).
• Rollover lanes, targets, spinner.
• Drain detection → ball lost → next ball.
• Tilt mechanic: "nudge" with limits.
• Multiball after hitting targets.

Rendering:

• 3D: table as extruded geometry (walls as boxes along segments), glass top, chrome rails, neon emissive lines, bloom postprocessing.
• Camera: fixed perspective tilted, slight follow of ball (subtle pan).
• Ball: chrome sphere with envMap.
• Score HUD: DOM overlay with retro digits.
• Audio: synthesized plunger, bumper pops, flipper clicks, rollover chimes, drain, multiball siren. Pentatonic bumper notes = musical.

Testing:

Like the previous demo, I can extract the physics core to test with node. Write core.mjs + test.mjs, run tests, then build index.html embedding the same code.

Actually the previous run extracted the physics core from index.html into core.mjs for tests. I'll write physics as a standalone module first, test it, then inline it into the HTML (keeping a marker structure).

Plan:

1. Create /tmp/pinball/ dev folder.
2. Write physics core (core.mjs): table builder, colliders, ball sim, flippers, game state machine.
3. Write test.mjs with unit tests (segment collision, CCD no tunneling, flipper kick, bumper impulse, plunger, drain, multiball).
4. Run tests, fix.
5. Build index.html with three.js rendering + audio + HUD + inline the tested physics.
6. node --check the module script.
7. Deploy to /space/demos/042-neon-tilt/index.html, update index page.

Let me start with the physics core. Key design:

step(ball, dt): v += gdt (gravity first) remaining = dt for iter in 0..4: find earliest hit t in [0, remaining] over all colliders if none: pos += vremaining; break pos += v*t (move to contact, small epsilon back) resolve(hit) -> v' remaining -= t

n = normal (from collider to ball) vn = dot(v - u, n) if vn < 0: v -= (1+e)vnn apply friction: vt = (v-u) - vn_part... damp tangent by mu positional: push ball out of penetration.

Good. I'll build demo 042 "Neon Tilt" — a synthwave pinball machine with a custom 2D physics engine (CCD, flippers, bumpers), three.js rendering with bloom, generative audio, and a full game state machine. I'll develop in /tmp/neontilt, write the physics core as a testable module, write unit tests, run them, then assemble the final HTML.

Let me start by writing the physics core. I'll write it as an ES module core.mjs with no three.js dependency (pure math + game logic), then test it with node, then inline into index.html.

Physics core plan (2D in x,y plane; table coordinates in "units" ~ cm):

Ball: {x,y,vx,vy,r, active, id}

stepBall(ball, colliders, dt, events): vy += g*dt let tRem = dt for iter < 5: hit = sweep(ball, tRem) → earliest {t, nx, ny, collider, contact} if !hit: move full, break move to hit.t * 0.98? Move to contact then push out by epsilon along normal. resolve. tRem -= hit.t if tRem <= 1e-6 break

sweep vs seg (capsule with radius Rc = seg.r + ball.r): Let w = ball pos - a; d = (b-a); L = |d|; dn = d/L relative velocity v (collider static).

1. Side: distance from moving point to infinite line along d: solve |w + vt - ((w+vt)·dn)dn|^2 = Rc^2 → quadratic. Get t candidates; for each, check s = ((p(t)-a)·dn) in [0,L]; normal = perpendicular component.
2. Caps: sweep vs circle centered a and b with radius Rc → ray-circle: |w + vt|^2 = Rc^2. Earliest t in [0, dt].

sweep vs circle: same as cap test with Rc = circle.r + ball.r.

resolve: vn = v·n; if vn < 0: v -= (1+e)vnn; friction: vt = v - (v·n)n; v -= vt * mu (clamp). For bumper kick: after bounce, add n * kickSpeed. For flipper: compute contact point on capsule, u = omega × r (perp in 2D: u = omega * perp(r)). relative vn = (v-u)·n; if < 0: v -= (1+e)vnReln (using relative velocity), which imparts the flipper motion.

Flipper: {pivotX, pivotY, len, r (radius of capsule), a0 (rest angle), a1 (active angle), omegaUp, omegaDown, side (-1 left, +1 right), angle, omega, pressed} update(dt): target = pressed ? a1 : a0; move angle toward target at omega rate; omega = signed rate used last step (for surface velocity). tip position: pivot + (cos, sin)*len... For left flipper: rest angle ~ -30° (pointing down-right), active angle ~ +30° (up). For right flipper mirrored: rest ~ 210° (pointing down-left) i.e. angle measured accordingly.

Simplest: define flipper in local space pointing along +x with pivot at origin; left flipper: angle from aRest=-0.5 rad to aActive=+0.55. Right flipper: mirrored — angle from π - aRest... Let me define both flippers pointing "inward": left flipper points right (+x) at rest tilted down: angle -0.5; when active swings up to +0.6. Right flipper points left (π): rest π + 0.5, active π - 0.6. Angular velocity sign differs; the general code: angle moves toward target by rate*dt with sign; store current omega = (angle - prevAngle)/dt.

Collision: capsule from pivot to tip = pivot + dir(angle)*len; treat as seg collider with moving surface velocity u at contact point = omega × rc, where rc = contact - pivot; in 2D: u = omega * (-rc.y, rc.x).

Sensors: line segments; detect crossing: sign of cross product of (prev-a, d) vs (new-a, d) flips and projection within [0,L] → trigger event with direction.

Game / table: Build table geometry function buildTable() returning {segs, circles, sensors, flippers, bumpers (subset of circles), drainY, plunger: {...}, layout data for renderer}.

Table layout (units; y up, bottom = drain):

• Table inner width: x from -34 to +34 main playfield; plunger lane x from +26.5 to +34 (lane width 7.5), from y=0 up to y=64 where a curved one-way arc guides ball into top.

• Actually classic: plunger lane on right, ball shot up lane, over the top arc into playfield. The top arc: from left wall top (-34, 96) curving over to lane inner wall top (26.5, 96)? Table height: let playfield be y in [0, 120]; walls: left x=-34 from y=6 to y=96; right outer x=+34 from y=0..120; lane inner wall x=+26.5 from y=10..96. Top arc: center ( (-34+26.5)/2 = -3.75, 96), radius 30.25, from angle π to 0 — a semicircle. Above 96 the arc caps the playfield; the lane continues up x∈[26.5,34] to y=96+30.25? No — the lane outer wall x=34 goes up to meet the arc's right end at (26.5,96)? Hmm, the arc spans from (-34,96) to (26.5,96). The lane is between x=26.5 and 34; the ball goes up the lane and must curve left. So the outer boundary over the lane: from (34, 96+?) ... Let me do the full outer boundary as a capsule shape: outer walls x=±34 up to y=96, then a semicircle of radius 34 centered (0,96) from angle 0 (x=34) to π (x=-34). That's the outer boundary. The inner lane wall at x=26.5 from y=12 to y=93, then its top connects via a small arc (center (26.5-?)...) hmm — lane inner wall top should guide the ball to follow the outer arc: put a curved "one-way" guide: an arc centered (0,96) radius 26.5 (same center as outer arc) from angle 0 down to... Actually if both outer (r=34) and inner (r=26.5) arcs share center (0,96), the lane continues over the top with constant width 7.5 — like real tables. The inner arc runs from angle 0 (point (26.5,96)) leftward to maybe angle 60° (point (13.25, 96+22.96)), where it ends — beyond that the ball falls into the playfield. So inner arc from angle 0 to ~55°; tessellate.

• Bottom: drain gap between flippers at y≈6: left flipper pivot (-12, 7), right flipper pivot (12, 7). Outlanes: angled walls from side walls toward the flipper area: classic "inlane/outlane" arrangement: On each side, a slanted wall from (±34, 30) down to (±18, 10) guiding toward flippers; outlane gap between wall end and side... Let's do: left side: wall segment from (-34, 28) to (-22, 12) [inner guide]; the region left of that is outlane draining to a one-way gate... Simplify: two lanes each side: ball falling at x < -22 lands on the guide wall, rolls down to flipper; small gap between guide bottom end (-22,12) and flipper pivot area.

Keep it robust and simple:

• Slanted lower guides: left: seg from (-34, 30) → (-20, 10); right: (34, 30) → (20, 10).
• Slingshots: triangles just above guides: left sling triangle vertices (-22, 34) (-14, 22) (-22, 16)? The sling is a triangle with its hypotenuse facing inward; collision on hypotenuse kicks ball toward center-right-down. Implement as a special seg with kick: {kind:'seg', ..., kick: 220, kickNormal toward playfield}.
• Flippers: left pivot (-11.5, 8), len 9, pointing right-down rest angle -0.42 rad (~ -24°), active +0.5. Gap between flipper tips ~ 34-2*(11.5+9cos(24°))≈34-219.7= -5? too wide... compute: tip x = -11.5 + 9cos(-0.42)... cos(0.42)=0.913 → tip x = -11.5+8.2 = -3.3. Right tip = +3.3. Gap 6.6 vs ball diameter 2.7 — fine (drain possible, that's the game).

Hmm wait, flippers pivot y=8, below y<8 region is the apron/drain: any ball with y < 4 and |x| > flipper zone drains. Simply: y < 2 → drained (except inside plunger lane x>26.5 where floor exists... plunger lane: floor at y=1? Let's make drain check: ball.y < 3 && ball.x < 25 → drain. Plunger lane has a floor seg at y=1 for x in [26.5,34] and the plunger).

• Bumpers: three pop bumpers: (0, 78), (-14, 66), (14, 66) radius 3.2, kick speed 260. Skirt slingshots around.

• Rollover lanes: two lanes near top created by dividers: vertical segs at x=-24 from y=86..96? Hmm with the arc at 96... place lane dividers: seg from (-20, 88) to (-20, 96+?) ... simpler: three rollovers as sensor segments across the upper area at y=88: x ranges [-26,-16], [-6,4], [14,24]... but physically the ball passes between small posts. Posts: small circles at divider points: circles r=0.9 at (-26,88),(-16,88),(-6,88),(4,88),(14,88),(24,88). Sensors between consecutive posts. Ball rolling through triggers rollover.

• Standup targets: bank of 3 on left wall area: vertical seg at x=-30 from y=48..62 as sensor+wall: three target segments: y 48-52, 53-57, 58-62, each a sensor slightly in front of a wall seg (wall gives bounce). Ball hits wall → crosses sensor → target hit.

• Spinner: at left orbit: sensor at (-28, 70)? with free spin count — simplify: a "gate" sensor that scores and spins.

• Orbit lane: left side lane behind targets: divider wall from (-34? ) hmm. Let me not overcomplicate. Key shots: bumpers center, rollovers top, targets left, and a right "ramp-ish" loop: a curved guide (arc) on the right side: arc center (20, 52) radius 9 from angle... making a "loop" the ball can ride: honestly, the orbit around the top arc (behind bumpers if ball is fast) is a natural shot: gap between outer wall and bumper cluster; ball launched up the lane with medium force loops over the top and comes down the left side — that's the orbit. Good enough.

• One-way behavior at lane top is automatic: ball can only exit lane via the arc. Ball falling back down the lane into plunger: allow it (re-plunge). Fine.

• Nudge: impulse to all balls: vx += ±40 (with tilt counter).

Ball save: after launch, 12s window where drain returns ball to plunger.

Multiball: hitting all 3 targets lights "MULTIBALL READY"; then hitting the lane "lock" sensor (right lane top sensor) while lit starts multiball: current ball + spawn 2 more at plunger auto-launched... simpler: spawn extra balls immediately above the playfield (drop from top center). During multiball all scoring ×2.

Jackpots: during multiball, bumper hits score 1000.

Score multiplier: completing all 3 rollovers increments multiplier (max 5x).

Tilt: nudging more than 3 times within 1.5s → TILT: flippers disabled until drain, scoring stops.

Game over: 3 balls. High score in localStorage.

OK. Rendering: table coordinate → 3D: x→x, y→-z maybe; let me map 2D (x,y) → 3D (x, 0, -y) so +y (top of table) is far (-z), camera at (0, 130, 110) looking at (0,0,-55). Ball sphere radius 1.35*scale... use units directly (table ~ 68 wide, 130 long). Camera fov 40.

Walls: for each seg collider render a "rail": box from a to b with width 2r, height 5, metallic dark with emissive neon strip on top. For arcs: tessellated segs → same. Circles (posts): cylinders. Bumpers: cylinder body + emissive ring + cap; flash on hit (scale ring emissive intensity).

Playfield: rounded-rect plane with canvas texture: dark navy with neon grid lines, lane markings, art (procedural canvas: glow lines, chevrons, logo text "NEON TILT"). Plus subtle reflectivity (MeshStandardMaterial roughness 0.3, envMap).

Glass: plane above at y=8 with MeshPhysicalMaterial transmission... transmission is expensive; use MeshPhysicalMaterial transparent opacity 0.08 roughness 0.05 — simple tinted glass sheet. Or skip glass; add subtle reflections via env. Keep glass very subtle.

Cabinet: outer box frame (wood/black), legs? skip legs, floating cabinet over a reflective floor? Add a dark floor with radial glow. Backbox (the vertical score display at the top): a box at the far end with a canvas "DMD" display showing score as dot-matrix! That's very pinball. The DMD: canvas 128x32 scaled, dot-matrix font rendering score, messages ("MULTIBALL!", "TILT", "BALL 2"). Update in JS. That's a wow detail. Also bloom on it.

Lighting: ambient dim, key directional with shadows (ball shadow on playfield), plus 2-3 colored point lights; flashers: point lights that pulse on events (bumper hits flash a light).

Audio: WebAudio:

• bgm: simple synthwave loop: bass arp + pad + hats via lookahead scheduler (like void-runner). Keep modest: 100 BPM minor arp + pad chords + noise hat.
• SFX: flipper click (short noise burst + click), bumper pop (sine burst pitch pentatonic + noise), sling (square blip), rollover ping (sine ping), target (metallic click), drain (descending tone), launch (spring boing — pitch sweep), multiball siren, tilt alarm, ball save jingle.
• Mute toggle.

HUD: minimal DOM: title top-left, score top-right big mono, balls remaining, hints bottom, message center flash. Buttons: launch (touch), mute, snapshot. Controls info.

Post: EffectComposer, RenderPass, UnrealBloomPass, custom final pass (vignette, grain, chromatic aberration) — reuse pattern from previous demos.

Quality: renderer pixel ratio clamp, bloom strength, shadow map size adapt to fps.

Input:

• Left flipper: 'z', 'ArrowLeft', or left shift; right: '/', '.', 'ArrowRight', right shift. Hmm — arrows could conflict with nudge. Standard pinball (Visual Pinball): left/right shift = flippers, space = plunger, enter = launch. I'll do: flippers: Shift keys + Z and / + ArrowLeft/ArrowRight; plunger: ArrowDown or Space hold to charge, release to fire; nudge: X (left), M?? Keep: nudge via A/D? Hmm.
  • Left flipper: Z, Left Shift, ArrowLeft
  • Right flipper: /, Right Shift, ArrowRight, .
  • Plunger: Space or ArrowDown (hold to charge, release to fire)
  • Nudge left: Q? Actually nudge: N (up), comma/period? Simplify: nudge = pressing both flippers + direction? Let me do: nudge left = 'a', nudge right = 'd', nudge up = 'w'? That's pinball arcade style. Hmm, but W might not be discoverable. I'll document in hints.
  • Touch: left half tap = left flipper, right half = right flipper, bottom-center button hold = plunger; swipe = nudge? keep: device motion? skip. Buttons for nudge on touch? Simple: two small side buttons.
• P pause, M mute, C snapshot, R restart, H hide UI?

States: attract (title, "press space to start") → serve (ball in lane; hold space to charge, release launch) → play → drain → next ball → game over → attract.

Physics tick: fixed timestep accumulator: dt=1/120; within, substep 1/480 sweeps.

Ball trail: ribbon or simple additive sprite trail (previous positions) — nice with bloom.

Extra juice: slow-mo on drain? camera shake on tilt/nudge/bumper big hits; ball-follow subtle; combo display; skill shot: plunge to lit rollover lane = skill shot bonus. Add: "skill shot" — if freshly launched ball hits the currently lit rollover (cycling) → bonus 5000. Fun.

OK — this is a big build. Let me start with the physics core + tests.

Note coordinate mapping: physics 2D (x right, y up the table toward the backbox... wait gravity pulls -y toward player at bottom; plunger at bottom right, launches ball UP (+y) the lane, over the top arc at high y, drains at low y. Yes: gravity -y.

Table layout final (units cm-ish):

• Outer walls: left x=-34 (y from 8 to 96), right x=+34 (y from 0 to 96), top arc center (0,96) r=34 from angle 0..π. Bottom: none (drain).
• Apron: at y<10 angled side walls from (±34, 30)→(±20,10) as guides (mentioned). Below the guide ends, open to drain except flippers.
• Plunger lane: inner wall x=26.5 from y=8 to y=93 as straight seg, then inner arc center (0,96) r=26.5 from angle 0 to ~0.96 rad (55°) where it ends. Lane floor: y=0.5 for x in [27.5, 33]. Plunger rest ball pos (30.25, 3). Lane outer = right wall x=34.
• One-way gate at lane bottom? not needed.
• Flipper pivots: left (-11.5, 8.5), right (11.5, 8.5), len 9, capsule r 1.6 (ball r 1.35).
• Guides: from (-34, 30) to (-19, 9.5); mirrored.
• Slingshots: left triangle: segs: from (-26, 34) to (-18.5, 22) [kicker face], from (-18.5,22) to (-26, 14)?? Let me define sling as triangle with vertices A(-27,33), B(-17,21), C(-27,15). Faces: A-B (kicker, kick dir toward +x/-y normal), B-C (back), C-A (along wall). The kicker face normal points toward playfield center: normal of A→B: dir (10,-12)n → normalize (0.64,-0.768); normal perp: (0.768,0.64) (pointing right-up) — that's into playfield. kick speed 200.
• Bumpers: B1 (0, 76) r 3.4, B2 (-13.5, 64) r 3.4, B3 (13.5, 64) r 3.4. kick 250. Also two "dead" posts with rubbers near guides.
• Rollovers: posts at y=86: x = -25, -15, -5, 5, 15, 25 → lanes between; sensors at y=86 spanning each gap (5 lanes? too many; make 3 lanes with wider posts: posts at -22, -8, 8, 22 → lanes [-22,-8],[-8,8],[8,22] with sensors. Hmm ball fits between posts (gap 14 vs ball 2.7) fine. Sensors are horizontal segs at y=86 between posts.
• Targets: on left: wall seg at x=-31 vertical y 46..62 (the rebound wall), sensors at x=-29.5: T1 y 46.5-51, T2 51.5-56, T3 56.5-61.5. Ball hits sensor then wall (sensor in front). Sensor triggers on approach (crossing either direction? only when moving toward wall: check vx<0). Hmm — wait, sensors trigger on crossing; ball crosses sensor then hits wall and bounces back crossing again — use cooldown per target (0.5s) and only count inward crossing (direction check).
• Right side: a "spinner" in the orbit lane? The orbit: gap between right wall/lane area and bumpers... The natural orbit shot: up the left side over the top. Add spinner sensor vertical at (-26, 70)? Ball passing left side crosses → spinner spins (visual + points per revolution while ball passes once... just points + sfx). Spinner at the left lane entrance: vertical sensor seg from (-27, 66) to (-27, 76)? ball traveling up crosses it. OK.

Wait — but the left side: is there a lane up the left side to the top? Between left wall x=-34 and the target wall x=-31 there's a gap of 3 — ball (2.7 diameter) fits! That could be a sneaky path. Block it: make target wall x=-31.5 with gap 2.5 < ball 2.7. Good: targets on a wall segment right against... hmm ball must reach target faces from the right side: wall at x=-31.5, targets face +x. Gap between wall and outer wall: 2.5 — ball can't get behind.

• Also add a "lock lane" on the right: between x=20 and 26.5, y 40..60: a small alcove: vertical seg x=20 from y=40..58 with an opening at top; ball entering from top of alcove falls to a kicker? Simplify multiball trigger: when lit, hitting ANY target again starts multiball. No lock lane needed.

Let me also think about the top-left region: after the inner arc ends at 55° (point (26.5cos55, 96+26.5 sin55)=(15.2, 117.7)?? wait angle measured from +x axis: point = center + r(cosθ, sinθ) = (26.5cos55°, 96+26.5 sin55°) = (15.2, 117.7). Hmm that's up at y=117 near the outer arc. Ball launched fast goes up lane, around the arc past 90°, comes down the left side. The arc end at 55° leaves the region between arc end (15.2,117.7) and outer arc — open playfield: ball can enter the top zone from the playfield and come down... The rollover posts at y=86 sit below. Fine — it's an open upper playfield with posts; ball dribbles down through rollover lanes into bumpers.

Actually, let me reconsider: ball launched at full speed should loop the entire top arc and come screaming down the LEFT wall — the "orbit". It will then hit the target bank region (x=-31.5 wall, y 46-62)? The wall spans 46..62 only; ball orbiting down the left wall continues past y=46 down the left wall to the guide at (−34,30)→(−19,9.5) → rolls to left flipper. That's a satisfying full orbit → flipper catch.

Between: rollovers/posts at y=86: post at x=-22.. the orbiting ball passes near wall x -34..-31.5; posts at -22 won't interfere. Good.

One more feature: upper-left "mini loop" arc: arc center (-22, 100) r 8 as a decorative curve guide? Skip; keep geometry lean and robust. We have: walls, lane, guides, slings, flippers, 3 bumpers, 4 posts + 3 rollover lanes, 3 targets, spinner sensor, drain. That's a playable table.

Ball spawn: serve places ball at (30.25, 3) in lane. Plunger: while charging, power 0→1 oscillating? Classic: hold to charge increasing; release fires: impulse vy = power * maxV (~ 340) — ball up the lane. Auto-launch for ball save/multiball spawns: fixed power.

Drain check: ball.y < 4 && ball.x < 26 → drained (below flipper line). Also failsafe y < -10 or NaN → drain.

Tilt: nudge impulse 26 units/s on all balls horizontally/vertically; 3 nudges within 1.2s → tilt.

Now scoring:

• Bumper: 100 × mult (+ flash + pop sfx). During multiball: 500.
• Sling: 50 × mult.
• Rollover: 300 × mult, lights lane; all 3 lit → multiplier +1 (max ×5), lanes reset.
• Target: 400 × mult; all 3 → light multiball (or if lit → start multiball 3-ball).
• Spinner: 100 × mult per pass.
• Skill shot: launch → first rollover hit within 4s if it's the cycling lit lane → 5000 × mult.
• Drain with ball save → "BALL SAVED" re-serve.
• High score persist.

OK, time to write core.mjs. Keep it framework-free with an events array emitted per step. The renderer consumes table layout data from buildTable().

Let me write the code now. I'll be careful with the flipper geometry:

Left flipper: pivot (-11.5, 8.5); rest angle: pointing toward +x but tilted down: -24° = -0.42 rad. Active angle: +28° = +0.49 rad. Length 9, radius 1.6. Right flipper: pivot (11.5, 8.5); rest angle: π + 0.42 (pointing -x, tilted down: 180+24=204°); active: π - 0.49 (152°). Hmm active swings up.

Flipper angular speed: up stroke ω = 22 rad/s (fast ~ 25ms), down 10 rad/s.

Collision with flipper: treat capsule pivot→tip with radius fr + ball.r. Surface velocity at contact r_c = contact - pivot: u = ω * (-ry, rx). Restitution low (0.35) but the velocity kick comes from u.

Edge case: ball resting between flipper tip and guide — tip contact pushes ball... fine.

The sweep function for segs: Let me write robust code:

sweepCircle (moving point vs static circle radius R): |w + v t|^2 = R^2, w = p - c. Quadratic: a = v·v, b = 2 w·v, c = w·w - R². t in [0, dt], smallest non-negative root. If c < 0 (starting inside) → treat t=0 with normal from center.

Great — the side case is linear, not quadratic, since cross product is linear in t.

For the normal at contact: side → n = ±perp(u) pointing toward ball side; cap → (p(t) - endpoint)/R.

Resolution standard.

Now the renderer consumes colliders from buildTable with tags & visual roles. I'll tag segs with visual type: 'wall', 'guide', 'sling', 'lane', 'arc', 'apron', etc.

Game flow in core: class PinballGame { constructor() { build table, reset } state: 'attract'|'serve'|'play'|'drained'|'gameover' balls: [] flippers score, ballNum, mult, ... pressFlipper(side, down) setPlungerCharging(bool), plungerPower step(dt) → events[] }

Events: {type:'bumper', i, x, y}, {type:'sling'}, {type:'rollover', lane}, {type:'target', i}, {type:'spinner'}, {type:'drain'}, {type:'launch', power}, {type:'flipper', side, down}, {type:'tilt'}, {type:'multiball'}, {type:'mult', n}, {type:'skill'}, {type:'save'}, {type:'serve'}, {type:'gameover'}, {type:'wallhit', speed}? (for thock sfx — maybe only strong hits), {type:'nudge'}.

Tests (node):

1. sweepCircle: ball moving right hits static circle at expected t.
2. sweepSeg side: ball falling onto horizontal floor segment, t correct, after resolve vy>0 (bounce) and rests with gravity after steps (settles: |vy| small, y ≈ R).
3. No tunneling: ball at 3000 u/s vs thin wall — CCD catches it.
4. Bumper kick: ball barely touching bumper gets kicked out at ≥ kick speed along normal.
5. Flipper: ball resting on left flipper; press flipper; after swing, ball vy > 0 (launched up) — energy imparted.
6. Full game: serve ball, launch at full power → ball goes up lane, around arc, returns to playfield (x < 26) within ~3s, eventually drains without NaN; score ≥ 0; game transitions serve→play; drain decrements balls; gameover after 3.
7. Rollover: teleport ball above a lane moving down → rollover event fires once, lights lane; 3 lanes → mult increments.
8. Targets: fire ball at target wall → target events; 3 targets → multiball lit; hit again → multiball event, balls count 3.
9. Tilt: 4 quick nudges → tilt event; flippers disabled.
10. Determinism/NaN guard: random soak: 60s of random play with auto-flip (flip when ball near flipper and below) — no NaN, balls stay within table bounds |x|≤34.5, y≤131 (arc top 96+34=130), y≥-12.

Then index.html: the big file. Reuse patterns: import map three@0.170, EffectComposer, UnrealBloomPass, ShaderPass, custom grade.

Rendering specifics:

• Canvas texture for playfield: 1024×2048, draw: dark base gradient, neon grid, lane lines, bumper rings, target marks, chevrons pointing at lanes, big logo "NEON TILT" diagonal, arrow art. Map 2D→uv precisely: playfield plane from x -34..34, y 0..130 — but shape isn't rectangular (arc top). Use a ShapeGeometry for the playfield outline (rect + arc) with UVs computed manually... simpler: PlaneGeometry sized to bounding box and discard transparent in texture (texture alpha outside shape → transparent plane with alphaTest). ShapeGeometry with UVGenerator default maps to bounding box if we set uvs manually — PlaneGeometry has clean uvs; making the plane rectangular with transparent arc corners via texture alpha + alphaTest 0.5 works and is simple. Apron area (y<8): draw apron art (solid).
• Walls visual: for segs: rounded box (BoxGeometry scaled + positioned) height ~5; posts: cylinders; bumpers: 3-part mesh (base cylinder, emissive ring torus, cap) + point light flash pool; flippers: capsule (CapsuleGeometry rotated) with emissive stripe; plunger: rod + spring that compresses with charge.
• Backbox: box at top (y up high at far end) with canvas DMD texture (dot matrix). Camera at player side: camera pos (0, 125, 105) looking (0,0,-48)... mapping: 3D pos = (x, 0, -(y) + offset?). Let me map physics (x,y) → world (x, 0, 96-y)? So top arc center y=96 → z=0; drain y=0 → z=96. Simpler: world z = -(y - 96) → at y=96 z=0, y=0 z=96 (near camera). Ball mesh position (x, r, 96 - y). Camera at (0, 120, 190) lookAt (0, 0, 30)? Table length 130 (y 0..130 → z 96..-34). Table center z ~ 31. Camera (0, 125, 185) looking at (0,0,25), fov 38. Tune later.
• DMD canvas: 96×24 dot grid rendering text via 5×7 font drawn as circles; shows score + messages queue. Emissive material on backbox screen, feeds bloom.
• Neon rails: walls get emissive top strips (color gradient cyan→magenta via vertex colors or per-seg color by position y).
• Trail: for each ball a ribbon: store last ~24 positions, build camera-facing strip each frame (like squish-lab? squish had no trails; other demos did). Simpler: THREE.Line with additive material + linewidth 1 won't bloom nicely; do camera-facing quads strip with ShaderMaterial fading alpha. Manageable: build BufferGeometry with 2 verts per point, update each frame. Or use instanced sprites fading. I'll do a simple quad-strip.
• Ball: SphereGeometry(1.35) chrome: MeshStandardMaterial metalness 1 roughness 0.15 envMap (RoomEnvironment via PMREMGenerator). Emissive slight.
• Flashers: 4 PointLights pooled; on events position at event, intensity spike, decay.
• Camera shake: offset by noise * trauma.

Audio engine: like previous: master gain, compressor; bgm scheduler 16 steps, bass arp (saw through lowpass), pad (detuned saws), hat (noise burst), kick on 4s? Synthwave: kick pattern x.x., snare on 5/13? Keep simple groove at 96 BPM minor. SFX functions as described.

State machine UI: attract shows "PRESS SPACE / TAP TO START"; serve shows charge meter (arc above plunger or HUD bar); overlays for tilt/game over/multiball messages on DMD + center flash.

Alright — also adaptive quality: measure fps, drop pixelRatio & bloom. Snapshot button: render then toDataURL download.

One concern: holding Space both charges plunger and starts game — fine (attract→serve on space press; serve charges).

Ball save: 12s after each launch.

Autoflip assist for touch? no.

Let me also add "R" restart to attract.

Let me now write core.mjs in /tmp/neontilt.

Physics constants:

• gravity: -950 u/s²
• ballRadius 1.35
• global restitution: walls 0.45, guides 0.4, posts 0.9 (rubber), bumpers 0.6 + kick 250, slings 0.4 + kick 200, flippers 0.35.
• friction: tangent damping 0.02 walls, more on apron.
• air drag: v = (1 - 0.02dt)? light.
• Rolling on guides: ball rolling down guide → flipper: fine.

Speed cap: 1400 to avoid blowups.

Let me now also decide lane inner arc end angle: 55° = 0.96 rad. Hmm wait, actually with center (0,96) r=26.5: at θ=0 → (26.5, 96) — that's at the same height as arc center... The lane runs up x=26.5..34 until y=96 where the curve starts; inner arc from θ=0 curving up-left to θ=0.96: endpoint (15.2, 117.7). At endpoint the tangent direction is (-sinθ, cosθ)=(-0.82, 0.57) pointing up-left — ball exiting follows that tangent into the open area between inner arc end and outer arc (outer arc at θ=0.96 is (19.5, 123.9)); gap 7.5 consistent. Ball then continues to outer arc, follows it over the top (θ 0.96→π) and down the left wall. But wait — ball in the lane is constrained between x=26.5 (inner) and x=34 (outer) until y=96; then between the two arcs. At inner arc end, inner constraint vanishes; ball still pressed to outer arc by centrifugal force if fast; if slow, it falls off the inner arc end into the upper playfield (skill: soft plunge → drops near rollovers). Real tables work like this.

The inner wall x=26.5 seg from y=8..96 meets arc start (26.5, 96) — continuous tangent (arc tangent at θ=0 is (0,1) vertical — smooth.

At the very bottom of the lane inner wall (26.5, 8): opening — ball in playfield can enter the lane from below?! At (26.5, 8) to (34,?)... The right guide (34,30)→(20,10)? wait the right guide goes from right wall (34,30) down to (20,10)? That crosses the lane interior x∈[26.5,34]! Conflict: the guide would block the lane. Real tables: the right "guide" IS the lane inner wall bottom area; the outlane is to the LEFT of the lane inner wall... The right inlane/outlane sit between flipper and the lane: right guide should run from (26.5, 30)? Hmm.

Real table bottom right: plunger lane occupies the right edge; its inner wall extends down to near the right flipper; balls in the playfield approaching the bottom-right roll along the inner lane wall down to the right flipper. So: right guide = seg from (26.5, 26) down-left to (20, 10)? and the lane inner wall from y=8..96 at x=26.5... then the region x∈[20,26.5], y∈[8,26] is between guide and lane wall — an inlane that funnels to right flipper. Hmm, that makes the right side quite narrow. Alternative: right guide from (34, 30)?? can't, lane.

Cleaner: make the lane inner wall STOP at y=30 (x=26.5, y from 30..96). Below y=30, the right side is open: right guide seg from (26.5, 30) → (17, 10) guides balls toward right flipper; region right of guide & below (x>26.5, y<30 minus guide) — the lane bottom area connects: ball falling right of the guide lands in the lane channel bottom → rolls into plunger lane → sits at plunger?? That would be weird (ball enters lane from below and sits on the plunger — actually that's a real thing: it's the "shooter lane return" on some tables... no, real tables block it with a one-way gate).

Simplest robust: extend lane inner wall down to y=8 (x=26.5, 8..96) — ball cannot enter lane from playfield at all. Right side bottom: right flipper pivot (11.5, 8.5); right guide from (26.5, 28) → (19, 10): funnels to right flipper tip zone. Balls falling into the strip x∈[19, 26.5] below y=10... below the guide end (19,10): gap between guide end and flipper tip (tip at rest ~ (19.7, 4.8)? pivot (11.5,8.5)+9*(cos-24°,sin-24°)=(19.7, 4.84)) — gap between (19,10) and flipper body — ball falls through → drain. That's the right outlane-ish. OK acceptable: there's a small drain gap on the right side — real tables have outlanes! Fine.

Left side: guide from (-34, 30) → (-20, 10)? gap to left flipper tip (-19.7, 4.84): gap between (-20,10) and flipper — similar small gap → left outlane. OK, symmetric-ish. Good — outlanes exist, adds difficulty, and they're honest geometry.

Hmm wait, right guide from (26.5,28) while lane wall at x=26.5 from y=8 — they meet at (26.5, 28)? The guide starts at (26.5,28) attached to lane wall. OK.

Slingshots reposition: left sling triangle A(-27,33) B(-17,21) C(-27,15) — check it sits between guide (from (-34,30) to (-20,10)) and the playfield. Guide passes (-27, 20) at its midpoint. Sling bottom C(-27,15) vs guide at x=-27: guide y at x=-27: param: from (-34,30) to (-20,10): slope = (10-30)/(-20+34) = -20/14 = -1.428; y at x=-27: 30 + (-27+34)*(-1.428) = 30-10 = 20. So guide at (-27,20). Sling C(-27,15) is BELOW guide line y=20?! Overlap! Move sling up: A(-27,40) B(-16,28) C(-27,22)? Guide at x=-27 → y=20; C y=22 > 20 ok clear by 2 — ball diameter 2.7 needs clearance from guide normal distance... gap between sling bottom and guide ~1.5-2 — ball can't pass between → fine (dead corner). Or nudge: A(-27,41), B(-16,29), C(-27,23). Kicker face A→B dir (11,-12), normal into playfield: (12,11)/16.3 = (0.736, 0.675) — kicks up-right. Good. Mirror right: A(27,41), B(16,29), C(27,23) with kicker face normal (-0.736, 0.675).

But wait — the right sling region: lane wall at x=26.5 from y=8..96! The right sling at x 16..27 overlaps the lane wall (26.5 > 27? sling A x=27 > 26.5 → inside lane!). Shift right sling inboard: A(24,41) B(13,29) C(24,23). Hmm asymmetric from left but that's OK (lane eats space on the right — real tables asymmetric). Let me mirror-ish: left sling A(-27,41) B(-16,29) C(-27,23); right sling A(24,41) B(13,29) C(24,23).

Guides: left (-34,30)→(-20,10); right (26.5,28)→(17,10).

Sling C points: left C(-27,23) vs guide at x=-27 → 20 → clear 3. OK.

Bumpers: (0,76), (-13.5,64), (13.5,64) r=3.4. Check clearance to slings: sling B(-16,29) far below. OK. Bumper to lane wall (26.5): 13.5+3.4=16.9 < 26.5 ok.

Rollover posts y=86: x=-22,-8,8,22 r=0.9. Clear of bumpers (0,76) r 3.4: dist (8,10) = 12.8 > 3.4+0.9 ok.

Targets: wall x=-31.5, y 45..63; sensors x=-29.4: T1 45.5-50.5, T2 51.5-56.5, T3 57.5-62.5. Wall seg from (-31.5,45) to (-31.5,63). Gap to outer wall: 34-31.5=2.5 < 2.7 ball diameter — can't sneak behind.

Spinner sensor: vertical at x=-24, y 64..74 — a "lane" between target wall and bumpers? Ball flying down the left side crosses it. It's just a sensor (no geometry). For visuals render a spinner sign. Hmm — sensor crossing detection: any crossing triggers; direction up = "spin". Fine.

Also the top: after inner arc end (15.2,117.7)... any risk ball stuck between arcs at low speed? Ball resting on inner arc end: it would roll off (tangent tilted) — ok.

Outer arc: center (0,96) r=34 θ∈[0,π]. Top at (0,130). World z at y=130 → z=-34. Table far edge z=-34, near edge z=96.

Apron: y<8 region: visual art (drawn on texture) — balls there are draining; add angled "apron" walls from (±?,8) toward drain center (0,2)? The flippers' zone: below flippers, guide balls to drain center: apron segs from (-19,9.5)? Simpler: two apron segs: from (-20,9) → (-4,3) and (20,9) → (4,3): balls below flipper level funnel to center drain hole between (4,3)..(-4,3). Drain when y<4 & |x|<5.5 or y<2.5 generally (except lane x>26.5). Let me define drain: y < 3.2 && x < 26. The apron funnel guides to center. Flipper rest tip at (±19.7, 4.84) — ball rolling off apron (seg (-20,9)→(-4,3)) at x=-19.7 y≈8.9... hmm flipper tip is BELOW the apron seg start (-20,9)? Apron seg from (-20,9) to (-4,3): at x=-19.7, y ≈ 8.87; flipper tip at (-19.7, 4.84) is below the apron surface → gap of ~4 → ball passes under flipper tip?? No wait — flipper is a capsule from pivot (-11.5,8.5) to tip (-19.7,4.84). The apron seg runs under the flipper. Gap between flipper capsule (radius 1.6, so bottom edge ~3.2) and apron... The ball rests ON the flipper when flipper up; drains beside it. The geometry: ball at tip x=-19.7: apron surface y=8.87?? That means apron is ABOVE flipper tip — collision mess. Redo: apron should be BELOW the flipper line: flipper occupies y 3.2..10.1 (capsule r1.6 around segment from y 8.5 down to 4.84). Apron segs: from (-24, 6) → (-3.5, 2.5) and (24,6)→(3.5,2.5)? At x=-19.7: apron y ≈ 5.6+... param from (-24,6) to (-3.5,2.5): slope (2.5-6)/20.5 = -0.17; at x=-19.7: y = 6 + (4.3)*(-0.17) = 5.27. Flipper bottom edge at tip: 4.84-1.6 = 3.24 < apron 5.27 → flipper tip dips below apron surface visually but physics-wise both are colliders — ball resting there contacts whichever. Tip underside overlapping apron is fine as long as no ball trap: ball on apron under flipper tip — pressing flipper swings tip up away — no crush issue (ball just sits). Hmm, but ball could wedge between apron and flipper underside near tip at rest: flipper at rest bottom edge 3.24 at tip; apron at tip x: 5.27. Flipper capsule occupies y from 3.24 to 6.44 at tip x — apron at 5.27 passes THROUGH the capsule. Ball cannot be there (both solid). Ball rolling down apron from left hits the flipper side and rolls over/around... The apron seg from x=-24: ball rolling down it at x<-19.7 then meets flipper tip region — apron continues under flipper; ball (r 1.35) resting on apron at x=-15: apron y=4.53; flipper capsule at x=-15: center y = 8.5 + (-15+11.5)*tan? flipper seg from (-11.5,8.5) to (-19.7,4.84): at x=-15, center y=6.86, bottom edge 5.26. Ball on apron top at 4.53+1.35=5.88 > 5.26 → ball collides with flipper underside. It wedges: apron pushes up, flipper pushes down-left — could trap ball!!

Fix: make apron end before flippers: apron segs from (-34, 8) → (-20.5, 4) and (34? no right side is lane...) hmm. Real aprons are below everything and flippers sit above apron surface with a gap < ball radius so balls roll over the apron and onto flippers. Correct setup: apron surface at y ≈ 2-3 (below flipper bottom edge 3.24 minus clearance): apron seg from (-34, 5) → (-3.5, 2) and mirror (34,5)→(3.5,2)? Wait right side x∈[26.5,34] is the lane with floor y=0.5... apron from (26.5, 5) → (3.5, 2). Ball rolling on apron: surface around y 2-5; flipper bottom edge 3.24 at tip (x=-19.7): apron at x=-19.7: from (-34,5) to (-3.5,2): slope = -3/30.5 = -0.098; y = 5 + (14.3)(-0.098) = 3.6. Ball on apron: top of ball 3.6+2*1.35=6.3 > flipper bottom 3.24 → overlap again! The problem: apron rises toward outlane side while flipper tip dips down. Real tables: flipper tips point toward the inlane guides; below flippers is the "drain area" and the apron is the angled surface near the player. The ball reaching apron region is ALREADY drained past the flippers — apron only matters below y < flipper tip path. The gap between flipper tip (x=-19.7) and left guide end (-20,10): that's the outlane. Ball falling through outlane lands... should land on apron and drain.

Simplest robust: make the drain region fully open (no apron segs at all): any ball with y < 4.2 and not in the plunger lane (x < 26.5) → drain. Below y=4.2 there's nothing to collide except flipper tips zone — balls below flipper line drain instantly, no trapping. Flipper tips at 4.84 with capsule r 1.6 → bottom edge 3.24 < 4.2: a ball resting on flipper tip top: center ~ 4.84+1.6+1.35=7.8 > 4.2 fine. Ball between apron... there's no apron. Ball wedged under flipper tip? Can't — nothing to rest on, it falls to y<4.2 → drain.

So: drain when y < 4.2 && x < 26.5. The lane floor y=0.5 keeps served ball (center 0.5+1.35=1.85, x=30.25 > 26.5 → not drained). Lane inner wall x=26.5 from y=8 — gap y 0.5..8 at x=26.5?? Ball in lane could escape into playfield below y=8! Extend lane inner wall down to y=0.5: seg (26.5, 0.5) → (26.5, 96). But then balls in playfield bouncing at bottom-right hit lane wall and fall into... the strip x∈[?,26.5], y<8: right guide end (17,10); ball below it at x 17..26.5, y<10 falls to y<4.2 → drain (right outlane, wider). Hmm that makes right outlane hungry: gap from right flipper tip (19.7,4.84) to lane wall (26.5) — 6.8 wide outlane vs left outlane gap: left guide end (-20,10) to left wall... left: ball below guide (-34,30)→(-20,10): at x=-25, guide y=17.1; below guide = falling → drain when y<4.2. Left outlane gap: from left flipper tip (-19.7) to left wall (-34) — 14 wide?! Any ball left of flipper tip & below the guide drains. That's just how pinball outlanes work, though 14 is wide because guide ends at (-20,10): the guide protects x<-20 balls above y~10ish. Eh — ball hugging left wall falls from guide start (-34,30) → it's ON the guide (above it) → rolls down guide to (-20,10) → drops at x=-20 near flipper tip (-19.7, 4.84)... lands on/near flipper tip → saveable. And ball falling at x=-30 below y=30? It's above guide? At x=-30 guide y = 30 + (4)(-1.428) = 24.3. Ball at (-30, 20) is below guide → drains. But can ball GET to (-30, 20)? Region x -34..-31.5 is blocked by target wall (y 45..63) but open below y=45: ball can enter x∈[-34,-31.5], y<45?? From where? Below the target wall bottom (45): gap between target wall bottom (-31.5,45) and sling A(-27,41): gap diag ~ (4.5,4) — 6 wide — ball can slip through into the "behind targets" channel and fall at x≈-33 to y<4.2 drain. That's a "mystery drain" — bad feel. Fix: extend target wall down: x=-31.5 from y=45 down to... the guide? Guide at x=-31.5: y = 30 + (2.5)(-1.428) = 26.4. Extend target wall (31.5, 45)→(31.5, 27) then it merges near guide — close gap fully: seg from (-31.5, 45) to (-31.5, 26). Then the pocket behind targets connects to the guide channel: ball in that channel rolls ON guide from (-31.5, 26.4)-ish down to (-20,10) → flipper. So make target wall one seg from (-31.5, 63) → (-31.5, 26.5) (targets on upper part 45..63). And the channel between x -34 and -31.5 funnels to the guide. OK good.

Similarly right side: lane wall x=26.5 full height blocks everything.

Now upper area check — can ball get stuck anywhere? Behind bumpers: bumpers float in open space. Between bumper 2 (-13.5,64) and target wall (-31.5): 18 wide — open. Rollover posts sparse. OK.

Skill shot: soft plunge drops ball from inner arc end (15.2, 117.7) down → falls near x~12-15 through rollover lane [8,22]? Plausible.

Launch power: maxV such that ball loops the arc: need v at lane top to overcome... energy: v²/2 > g*(130-3)=120650 → v>sqrt(2950127)=491. Set max launch 620, min 120. Ball at 620 up lane: reaches top with v = sqrt(620² - 2950127) = sqrt(384400-241300)= sqrt(143100)=378 → plenty to orbit. Arc radius 34, ball at outer arc r≈34-1.35: centripetal v²/r = 378²/32.65=4376 >> g → follows arc.

Gravity 950, flipper kick: flipper tip speed ωr: 22 rad/s * 9 = 198 + capsule — ball launch speed from flipper ~ up to 250. Reaches height v²/2g = 32 — hmm that only reaches y≈8+32=40?? Too weak to reach top (y 130 needs 500). Real flippers CAN send ball to top. ω up: 30 rad/s, tip 270; plus ball incoming speed + restitution... realistic flipper shots: ball speed off flipper ~ 300-450. Let me set ωUp = 34 rad/s (tip 306) and restitution flipper 0.5 — relative velocity kick ~ (1+e)(vnRel) — ball rolling onto flipper at -100 downward gets bounced with relative +... contact at mid-flipper r=5: u=170; ball v=-100 → vnRel = -270 → v after: -(-2701.5) ... vn' = +405?? That's the normal component flip — resulting ball speed ~405. OK that launches to y ~ 8+ 405²/(2950)=94. Good enough — flipper shots reach bumpers but rarely the very top except clean hits. Maybe ω=38. I'll tune in tests: test that a ball resting on flipper gets launched with vy ≥ 250.

Actually let me compute ball RESTING on flipper then pressed: ball in contact, vnRel ≈ 0 → no kick?! Classic problem: resting ball + press → flipper rotates INTO ball → the sweep catches contact during the step while flipper has ω — with relative vn = -u·n < 0 → kick ∝ u·n. Resting ball on flipper top: contact normal up; u at contact = ω×r perpendicular to flipper arm pointing up-forward; u·n > 0 → flipper moving INTO ball → vn = (v-u)·n = -u·n < 0 → bounce: vn' = vn - (1+e)vn... yields ball velocity ≈ u·n*(1+e) upward ≈ 306*(sin component)*1.5 — strong. Good.

Now — write it. Also game.js logic: multipliers, lit lanes, multiball state, tilt, skill shot, ball save, serve/drain/gameover, events queue. I'll put ALL game logic in core.mjs so node tests cover it.

Let me write core.mjs now. I'll write it carefully — it's long. Then test.mjs, run, fix, then build index.html.

Plunger mechanics: while in 'serve' state, ball locked at (30.25, 3.5); charging: power grows 0→1 over 1.4s (loop with sawtooth? hold-release). Release: ball unlocked, vy = 120 + power*500, vx=0; event launch. State → play; ballSaveUntil = t+12.

Auto plunger for multiball spawns: spawn ball in lane with fixed v 560.

Extra balls spawn during multiball: serve into lane instantly with v.

Ball save during multiball: no (only single-ball).

If one ball remains after drains during multiball → multiball ends.

Score events add to score with multiplier; DMD messages.

Skill shot: lit lane cycles every 0.8s; if ball launched within 4s crosses lit rollover → 5000.

Now the table build: also produce visual metadata per collider for the renderer: {type, ...geometry, color role}.

Let me write the files now.

core.mjs:

I'll write the full thing in one go. Line count maybe ~500 for core. Then tests ~200. Then index.html ~1300. Let's go.

Actually, one more thought on rendering the playfield shape: I'll do a rounded-rect + arc shape via THREE.Shape and ShapeGeometry, then compute UVs manually from positions (map x -34..34 → u 0..1, y 0..130 → v 0..1). ShapeGeometry generates position attribute; I can rewrite uv attribute from positions. Easy.

Walls rendering: for each seg → BoxGeometry(len, h, w) positioned/rotated; plus emissive strip: thin box on top with emissive color by role; use InstancedMesh? counts small (~40 segs after tessellation: arcs tessellated 48 segs each... outer arc 48 + inner arc 16 → ~70 pieces + others). Just merge? Simplest: create each as mesh — ~120 meshes, fine. Or group into merged geometry... keep meshes; also per-seg emissive strip color gradient by angle — nice neon rainbow rails.

Ball trail: quad strip additive.

Flippers: CapsuleGeometry(r=1.6, len=9) aligned along X, rotated by angle; emissive stripe skip — use two materials? Just standard material with emissive cyan; plus a pivot cap cylinder.

Bumpers: base cylinder r=3.6 h=1.2 dark; body cylinder r=3.4 h=2.4 with emissive ring texture?; top cap dome (sphere squashed); a torus ring r=3.4 tube 0.25 emissive that flashes. Store per-bumper flash value decays.

Posts: small cylinders + emissive dot.

Targets: emissive boxes at wall that flash when hit; lit/unlit color.

Rollovers: emissive disc on playfield + light state color (lit = magenta, unlit = dim cyan).

DMD: canvas 128×32, draw 5×7 dot font text lines: score line + message line. Update at 12Hz or on change. Emissive orange dots on dark.

Backbox: box behind table top end, angled slightly; screen plane with DMD canvas texture (emissive map).

Speaker grill etc skip.

Camera: perspective; subtle follow: target.x = ball.x0.08; lookAt (target.x0.5, 0, 30). Shake via trauma decay; offset random per frame * trauma².

Post FX: UnrealBloomPass(strength 0.9, radius 0.5, threshold 0.55); grade shader: vignette + grain + slight chromatic aberration + subtle scanline? keep standard trio.

Lights: ambient 0.35; directional key (0, 80, 60) casting shadow 2048 covering table; colored points: cyan (left), magenta (right) low intensity for mood; flash pool 4.

Glass: skip (keeps clarity); instead subtle "playfield protector" reflections via envMap on playfield material roughness 0.25.

Audio:

• master: GainNode → compressor → destination; musicGain, sfxGain.
• BGM: 96 BPM; pattern 16 steps: kick [0,4,8,12]? synthwave four-on-floor at 96 feels slow; use 112. kick steps 0,4,8,12; bass 16th arp minor [root, root, oct, root...]; pad chords change per bar (Am F C G); hats offbeat 8ths; lead pluck sparse. Implement small sequencer with lookahead 0.12s, timer 40ms.
• SFX synth functions: blip(freq, dur, type, gain), noiseBurst, sweep. Bumper: pentatonic pop [C5 D5 E5 G5 A5] rotate + sparkle; sling: lower square blip; rollover: sine ping hi; target: metallic (square + fast decay + detune); spinner: rapid ticks while spinning (spinner has spin value decaying, ticks at rate); launch: spring sweep up; drain: sad descending minor; save: jingle arp up; multiball: siren two-tone + riser; tilt: buzzer; gameover: descend; flipper: click (short noise + 60hz thump); nudge: thud.
• Mute toggle M; audio starts on first gesture.

HUD (DOM): title top-left; score panel top-right (SCORE big, BALL n, MULT ×n); message center big flash text; hint bottom; charge bar near bottom-right for plunger (or above plunger in 3D? DOM bar simpler); buttons: snapshot, mute, restart. Touch zones: transparent left/right half overlays (pointerdown → flipper), and a "LAUNCH" button bottom center during serve.

Also FPS-adaptive: track avg frame time; drop pixel ratio steps [1.75,1.5,1.25,1] and bloom resolution; disable shadows at low tier.

Snapshot: render once with composer, canvas.toBlob → download link.

OK, writing now. First core.mjs.

Details for sweep functions:

Hmm if c<=0 (overlapping): return t=0 with normal = w/|w| (or velocity-based fallback if w=0).

Seg sweep:

Also handle ball already overlapping side (|wc|<R and moving parallel or into): the t=(sR-wc)/vc with correct s gives negative t for one root — treat: if currently |wc| <= R and vcsign(wc) < 0 (moving deeper) → t=0 contact with normal = sign(wc)*(uy,-ux). I'll add that.

Resolve with restitution & friction & kick:

Flipper resolve separate (surface velocity):

Contact point for flipper: closest point on capsule to ball pos at contact: project ball onto seg, clamp, point = proj + normal*(flipR)... contact point for surface velocity: use the point on the flipper surface: c = closestOnSeg + n*flipR where n from seg to ball.

Sensors crossing test with prev pos.

Now the step:

Bumper/sling cooldown: 0.08s per ball per collider to avoid multi-trigger while in contact.

For flipper collision: flippers updated before ball steps each substep (angle integrated, omega computed). earliestHit includes flipper capsules at current pose (static during substep — fine).

Ball-ball collision (multiball): elastic equal mass: swap normal components; do after wall steps pairwise simple (positional). Fine.

Now table build function with all segs/circles/sensors/flippers + visual tags.

Then Game class.

Let me write the actual files now. I'll aim for correctness first, then tune.

One more: attract mode — a demo ball bouncing? Keep attract = idle table with slow camera pan and "PRESS SPACE". Also auto-plunge demo mode? skip.

Write core.mjs:

************************************************re.

Wait, there's a bug in my serve logic: serveNext spawns a locked ball in the lane at (30.25, 3.5). But drain check: b.y < 4.2 && b.x < 26.5 — ball at x=30.25 is fine. But also locked balls skip stepping — good.

Another issue: onDrain checks this.state !== 'play' — during serve the ball is locked so it can't drain. OK.

Ball save: saved = !this.multiball && this.time < this.ballSaveUntil. But if ballSaveUntil wasn't set (e.g., somehow), it's -1 → not saved. OK.

Also there's a subtle issue in startCharge during attract → startGame → serve. Then releaseCharge — after startGame, state='serve' but plunger.charging is false; the keydown started the game and keyup would call releaseCharge which returns early since charging is false. The user must press space again to charge. Hmm — UX: on attract, first space press starts game; ball is served; then press & hold space to charge. Acceptable. But better: make startCharge during attract also start charging after starting the game. Let me fix: after startGame(), set charging=true. Since startGame → serveNext sets state='serve'. So:

That flows: attract → space down → game starts AND charging begins. Release → launches ball 1.

Also the flipper 'pressed' during tilt: I set f.pressed=false on tilt, but pressFlipper when tilted sets pressed=false — but when user releases, pressFlipper(side, false) → f.pressed=false fine. After drain, tilted=false — flippers work again. But if user is HOLDING the button through the drain, f.pressed stays false until re-press (since pressFlipper only sets on call). Minor. Actually pressFlipper(side,false) sets pressed=false; then when tilt clears, pressed still false. OK.

One more bug: in checkSensor, c0 === 0 && c1 === 0 — fine.

In onColliderHit for targetWall, I check cooldown BEFORE the tag-specific 0.3 check — I set cooldown 0.08 gate first, then for targetWall use 0.3 window with last. But last was fetched... it returns if time-last < 0.08 at top. Then for targetWall checks time-last < 0.3 return; else set. That's fine.

Now potential physics issue: the bumper kick — kick adds velocity along normal every hit including grazing; with cooldown only affecting scoring not kick. Bumper kick with every contact substep iteration could add multiple kicks in one frame! E.g., ball approaches bumper: first iteration hit at t, kick adds 250 along normal. Next iteration (remaining time): ball moving away → no hit. OK single kick. But if ball ends up still overlapping after kick (kick insufficient), next frame another kick — that's fine/desirable (pop bumpers machine-gun).

Resting on flipper + press test: at rest ball sits on flipper; each frame gravity pulls ball into flipper, resolve cancels vn. When pressed, flipper rotates; sweep uses flipper pose at substep start (already updated). omega = angle change / dt. Contact during sweep — resolveFlipper uses current omega. Good.

But note: flippers update once per frame in step(), not per substep — I call stepBall per ball with the frame dt; earliestHit does its own iteration within dt. The flipper is static during the frame's ball sweep (pose = end pose, omega = average). Acceptable approximation at 1/120–1/240 steps.

Substep: I'll call game.step at fixed dt = 1/240 from the render loop accumulator (or 1/120 with internal CCD). CCD handles tunneling regardless. Use 1/240 for flipper fidelity. That's cheap: ~few colliders.

Now serve ball locked at (30.25, 3.5): check lane floor: y=0.5 seg from 27.2..33.4; ball r 1.35 → resting y = 1.85. Locked at 3.5 is fine (floats a bit, visually on plunger tip — plunger rest position ball at y≈3.5? The plunger tip at y~2.15... let me just lock at y=2.9: floor 0.5 + r... Actually locked ball just needs to look like it sits on the plunger; render plunger tip at ball.y - r. Set lock y = 3.2. Eh — set 3.2 in serveNext. Also autoLaunch spawns at 3.5 with vy — immediately moving; fine but let me align: spawn at 3.2.

Hmm, also: what if the player holds charge to full and launches — ball at 640 up the lane; reaches arc; loops. What if weak plunge: ball rolls back down lane onto plunger → serveBall is null, state='play'; ball sits in lane at bottom. Then what? Player must re-plunge! I need to handle: ball at rest in lane during play → allow re-plunge: if state==='play' and exactly one ball and ball.x > 26.5 and ball speed < 5 and ball.y < 6 → treat as serve: set serveBall=b, state='serve', b.locked... Let me add that check in step:

But during multiball a ball could land in lane — then it sits there until... add auto-relaunch after 1.5s during multiball: if multiball && ball in lane slow → auto impulse. Let me handle generally: during multiball, any ball slow in lane gets vy=560 auto. During single play → reserve to serve state.

Edge: during 'play' with ball save window active and weak plunge → reserve; that's fine, player re-plunges; ballSave continues from original... reset ballSaveUntil on re-launch (releaseCharge sets it). OK.

Also: skillTimer only ticks after launch — good.

Another edge: ball rolling in the lane channel y<0.5? floor covers x 27.2..33.4 and small seg 26.5..27.2. Ball at lane bottom rests y=1.85. Locked ball at 3.2 floats 1.35 above "rest" — visually the plunger rod tip will be at ball bottom; fine.

What about ball entering the narrow strip x∈[-34,-31.5] below target wall bottom (26.5)? The target wall seg goes down to y=26.5 at x=-31.5. Guide passes at x=-31.5, y=26.4 — the wall bottom endpoint sits essentially ON the guide. Gap between wall bottom and guide ~0 — sealed.

Right guide from (26.5,28) to (17,10): lane wall at x=26.5 covers y 0.5..96 — they intersect at (26.5,28) — sealed.

Now — ball trapped between lane wall bottom and right guide? The pocket x∈[17,26.5] below guide and y<10: balls fall through to y<4.2 → drain. That's the right outlane. OK.

Also add drain-safe: ball.y < -12 catches leaks.

Bumper at (13.5,64) and inner arc end (15.2,117.7) far. Bumper to lane wall x=26.5: distance 13 — fine.

Rollover sensors at y=86 spanning gaps: posts at ±8 and ±22 with r=1.0; sensor spans -21..-9 (gap between post edges 23... post at -22 r1 → edge -21; post -8 edge -9 → gap width 12 — sensor covers exactly). Ball crossing at y=86 between posts triggers. Ball could pass between post and wall x=-34..-23 without triggering — that's fine (outside lanes).

Now the game over → attract: after gameover, pressing space → startCharge → startGame. Also add explicit attract return: state stays 'gameover' with final score shown; startCharge handles restart.

Wait — in startGame, state = ? It calls serveNext which sets state='serve'. But I never set state to anything before 'serve'... fine.

One thing missing: 'attract' initial state with no balls — renderer shows table idle. Good.

multiball scoring x2 handled in addScore.

Also 'thock' events for hard wall hits — audio.

Let me also reconsider flipper geometry vs guides: left guide ends (-20,10); left flipper pivot (-11.5,8.5), tip rest (-11.5+9cos(-0.44), 8.5+9sin(-0.44)) = (-11.5+8.14, 8.5-3.83)=(-3.36, 4.67). WAIT — flipper rest angle for LEFT: base=0, side=-1, aRest = base + side*flipRest = -0.44 rad → tip at angle -0.44 from pivot: (-11.5 + 9cos(0.44), 8.5 - 9sin(0.44)) = (-3.36, 4.67). That points toward CENTER-down. Left flipper tip at x=-3.36. Right flipper: base=π, side=+1, aRest=π+0.44 → tip = (11.5 + 9cos(π+0.44), 8.5 + 9sin(π+0.44)) = (11.5-8.14, 8.5-3.83) = (3.36, 4.67). Gap between tips: 6.7 — drain gap. Good.

Guide end (-20,10) vs flipper: tip at rest (-3.36,4.67); gap between guide end and flipper zone: at x=-20..-11.5 the flipper doesn't reach (pivot at -11.5). Outlane gap from x=-20 to pivot — ball below guide end at x=-15, y<10 falls → at x=-15 flipper top at: flipper seg from (-11.5,8.5) to (-3.36,4.67) — at x=-15 not covered (pivot at -11.5 is the LEFT end... flipper extends from pivot toward center). So ball falling at x=-15..-11 y<10: misses flipper → drain. Hmm! The classic layout: guide end should nearly touch the flipper pivot area so balls rolling down the guide land ON the flipper. Guide end (-20,10); pivot (-11.5,8.5): 8.5 horizontal gap. Ball rolling off guide end falls at x≈-20..-19 → below: flipper doesn't extend there → drain. BAD.

Fix: move guide end closer to pivot: left guide (-34,30) → (-14.5, 9.5)? Then gap to pivot (-11.5): 3 — ball rolls off guide end onto flipper base (flipper top at pivot area: pivot (-11.5,8.5) capsule r 1.6 top 10.1; ball dropping at x=-14 lands at flipper... at x=-14 flipper doesn't exist (starts at -11.5). Ball lands between guide end (-14.5,9.5) and pivot (-11.5): falls into gap 3 wide → drains?! Gap 3 > ball 2.7 → yes drains through. Hmm.

Better: extend flipper pivot outward? Move pivots to (±13, 8.5): flipper from 13 to 13-9cos... left pivot (-13,8.5), tip rest (-13+8.14, 4.67)=(-4.86,4.67); gap between tips 9.7 — too wide (drain fest). Increase flipper len to 10: tip (-13+9.05,4.35)=(-3.95): gap 7.9. Hmm.

Alternative classic: inlane guides END right above flipper pivot such that ball drops onto pivot/base of flipper. Guide end (-14, 11.5) with pivot (-11.5, 8.5): ball rolls off at (-14,11.5), falls, lands on flipper arm near pivot (arm at x=-11.5..-3.4; at x=-12 arm y≈8.3; ball falling from 11.5 at x≈-13.5..-12 lands on arm near pivot. Gap between guide end x=-14 and arm start -11.5: 2.5 < ball 2.7 — ball bridges/rolls onto arm. Then rolls down arm to tip. Good: guide (-34,30) → (-14, 11). Check sling clearance: sling C(-27,23): guide at x=-27: y = 30 - (-27+34)(19/20)? slope = (11-30)/(-14+34) = -19/20 = -0.95; y at -27 = 30 + 7(-0.95) = 23.35. Sling C y=23 → overlaps guide by 0.35 — touching, seals the dead corner.

Right guide: (26.5,28) → (14, 11)? Sling right C(24,23): guide at x=24: from (26.5,28) to (14,11): slope (11-28)/(14-26.5)= (-17)/(-12.5)=1.36; y at 24: 28 + (24-26.5)*1.36 = 24.6. Sling C(24,23) below guide by 1.6 — gap 1.6 < ball — sealed dead corner. OK.

So ball rolling down right guide ends at (14,11) drops onto right flipper arm near pivot (11.5, 8.5). Gap 2.5. Good.

Update guides: left S(-34,30,-14,11), right S(26.5,28,14,11).

Now flippers vs outlanes: ball falling at x<-14 left of guide end... x∈[-14,-11.5] gap 2.5 < ball 2.7 → ball can't pass; it bridges onto flipper. Actually with 2.5 gap and ball 2.7 diameter, ball cannot fall through. It will contact both guide end cap and flipper and roll onto flipper.

But wait, outlane on the left: the region x∈[-34,-14] below the guide: how do balls enter? Over the guide ends? The guide runs from wall at (-34,30) — a ball on the LEFT of guide would be between guide and wall — but guide starts AT the wall, so no entry there. Ball can only get below guide by... the gap between target wall bottom (-31.5, 26.5) region? The channel x∈[-34,-31.5] funnels down to the guide top surface at (-31.5,26.4) — ON the guide (rolls down to flipper). So there's NO left outlane — every left-side ball feeds the flipper. Right side: same by symmetry-ish (lane wall). The only drains: center gap (6.7) and... hmm, slings kick balls toward center, bumpers bounce — drains only center? That's too easy but FINE for a fun arcade feel — actually wait: balls can bounce OVER the guides: guide top surface at (-27, 23.35) — ball bouncing around sling region can land below-right of sling and fall into the pocket between sling bottom C(-27,23)/guide and flipper base? Below sling C is guide surface (sealed) → rolls to flipper. Balls bouncing over guide from the playfield side: guide is a line — ball crossing below the guide line on its right side falls into the region above flipper base and left of... at x=-18, guide y = 30 + 16*(-0.95) = 14.8. Ball at (-18, 12) is below guide: region x∈[-20,-14], y<guide — bounded by flipper arm below? flipper arm spans x -11.5..-3.4. So pocket x∈[-20,-11.5] y∈[4..guide]: ball there → drains (gap between guide end and pivot 2.5 — ball fits ABOVE it and falls? The pocket bottom: at x∈[-14,-11.5], ball can't fit through 2.5 gap; but at x∈[-20,-14] there's nothing below → falls to y<4.2 → DRAIN. So yes there IS an outlane: the pocket x∈[-20,-14] left of the flipper. Good — that's the left outlane, honest.

Right outlane: pocket x∈[14,26.5] below guide → gap x∈[14,11.5] bridges (2.5<2.7), drain region x∈[14,26.5]... wider outlane on right. OK, asymmetric but playable. Actually let me widen right flipper reach: right pivot (11.5,8.5) same as left. Right outlane pocket x∈[14,26.5] — 12.5 wide hungry outlane. Eh — real tables vary. Acceptable. Actually hmm, let me reduce: move right guide end to (13,10): then pocket x∈[13,26.5]... no narrower. The pocket is bounded right by lane wall (26.5). Narrow it: extend guide end down: (26.5,28)→(13,9): guide end (13,9) near pivot (11.5,8.5): gap 1.5 — sealed; pocket x∈[13,26.5] BELOW guide: from x=13..26.5 any ball below guide line drains: width 13.5 at top narrowing... the guide at x=20: y = 28 + (20-26.5)((9-28)/(13-26.5)) = 28 + (-6.5)(1.407)=18.85. Ball bouncing under guide at x=20,y<18.85 → drain. Same as before basically. The outlane IS the area below the guide — its "width" is inherent. Fine.

Let me also double check the sling kicker normal: left sling face A(-27,41)→B(-16,29): the kick applies along collision normal (from wall to ball) automatically — ball approaching from the right gets normal pointing right-up → kicked up-right. Good.

Now update the table in core.mjs with the guide changes. Also fix serveNext lock y to 3.2 and startCharge to begin charging from attract. Also add the re-serve logic for weak plunges and multiball lane rescue.

Also, in step(): the re-serve check. And during 'serve' state, step still runs (locked ball). Fine.

Let me apply these edits.

Now fix startCharge (charge from attract), serveNext lock y, and add re-serve logic.

Now add the re-serve logic in step(). Insert after the drains handling. Let me add it in the step method after the "handle drains" block.

Also autoLaunch spawns at y=3.5 — align to 3.2. And there's a subtle issue with autoLaunch — it spawns a ball at the lane with vy = plungerMax*0.92 — good.

Now write the test suite. Tests:

1. sweepCircle basic: ball at (0,10) moving down at -100, static circle at (0,0) r=1, ball r=1 → contact when distance = 2 → from y=10 to y=2: 8 units at 100 u/s → t=0.08.
2. sweepSegCapsule floor: ball falling onto horizontal floor seg from (-10,0)-(10,0) r=0.5, ball r=1.35, starting (0, 5) v=(0,-100): contact at y = 1.85 → falls 3.15 → t=0.0315.
3. No tunneling: ball at (-50, 5) v=(3000,0), wall seg vertical (0,0)-(0,20) r=0.9, ball r 1.35, dt=1/60: swept must return hit with t ≤ dt.
4. Settle on floor with gravity: game-less: create mini world? Use Game with just... the Game always has the full table. For settle test, use raw functions: simulate ball with gravity bouncing on a floor seg using earliestHit over one seg — easier: instantiate Game and use its methods? Game.stepBall uses this.colliders (full table). Alternative: write a tiny local stepper in the test using sweepSegCapsule + resolve logic inline. Simpler: replicate small loop: each step vy += g dt; hit = sweepSegCapsule(...); resolve manually. Let me just do that inline in the test.
5. Bumper kick: place ball near bumper with small inward velocity → after step, ball speed ≥ kick*0.9 moving away.
6. Flipper launches resting ball: game → cheat: place ball resting on left flipper (state play), press flipper, step 0.3s → ball vy > 150 at some point (track max vy).
7. Full launch orbit: startGame, charge full, release → ball launched; step until ball.x < 26 (enters playfield) within 4s; assert happens. Then continue 30s with auto-flipper AI; assert no NaN, ball stays in bounds; eventually drains or stays in play.
8. Rollover + multiplier: game in play state; spawn ball above lane 1 moving down; step; assert rollover event; light all three lanes → mult increments.
9. Targets → multiball: fire ball at target wall from the right with vx<0; assert target event; light all 3 → multiballLit event; hit again → multiball, balls.length === 3.
10. Tilt: 4 nudges quickly → tilt event; flippers pressed get disabled.
11. Drain → game over: startGame, drain ball 3 times (teleport ball below drain line), assert ballNum increments and finally gameover event.
12. Ball save: launch, then drain immediately → save event, ball returned (autoLaunch), balls.length stays 1, state stays play.
13. Soak test: random AI play 120s sim; assert no NaN, positions bounded, score sane.

For tests needing 'play' state without launching: game.startGame() → serve; then manually unlock serveBall and set state='play': game.releaseCharge needs charging... do: game.startCharge(); game.plunger.power=0.5; game.releaseCharge(). Then ball flying. Then to place ball manually: game.balls[0].x=..., etc.

Let me write test.mjs.

Note: Game.step emits events into this.events; tests use game.drainEvents() after steps to collect.

Careful: in test 8, sensor cooldown uses this.time - last < 0.35. Different lanes = different sensor ids, fine.

For the rollover test: spawn ball at (0, 88) with vy=-100 (lane 1 sensor spans (-7,86)-(7,86)). Ball r 1.35: passes y=86 → crossing. Need state play: ev rollover lane 1.

Multiplier: lanes 0,1,2 all lit → mult 2, lanes reset, 'mult' event.

Target test: ball at (-25, 48) vx=-200 → crosses sensor x=-29.6 (negX dir ✓) then hits wall at -31.5. Sensor triggers 'target' i=0. For targets 1,2: y=54, 60.

After all 3 → 'multiballLit'. Then another target crossing → 'multiball' event and balls.length becomes 3 (autoLaunch adds 2 — but wait: autoLaunch spawns ball in lane with vy — those balls then fly up... in subsequent steps they move; for the assertion, check right after the step that balls.length === 3).

Hmm wait — multiballLit → hitting another target calls startMultiball which adds 2 balls → 1 + 2 = 3. ✓.

But careful: the target sensors have per-ball cooldown 0.35s — hit target 0 at t, then for the 4th hit (multiball trigger) use target 0 again after stepping 0.5s, or just hit target 0 again with new ball id. Use different targets: hit 0,1,2 → lit; then hit 0 again after 0.5s.

Test 12 ball save: startGame → charge → release (state play, ballSaveUntil = t+12) → set ball y=3 (below drain), x=0 → step → drain event saved → balls.length===1 (autoLaunch spawned), 'save' event. ✓ But careful: autoLaunch spawns new ball while drained b removed — balls.length stays 1. ✓ state 'play'. ✓

Test 11: drain 3 balls: after ball save expires... ballSave is 12s — draining immediately would save! So step time forward: set game.ballSaveUntil = -1 manually, or advance game.time by 13s (stepping 13s sim is fine — ball might drain by itself). Simplest: set game.ballSaveUntil = -1 after launch. Then teleport ball to y=2, x=0 → drain → serveNext (ball 2). Repeat → ball 3 → gameover.

Wait — after drain with balls.length===0 and ballNum < 3 → serveNext → state 'serve', ballNum=2. Then releaseCharge again: startCharge, releaseCharge. Then ballSaveUntil=-1 again. Drain again. Etc.

Test 6 flipper: startGame, launch weak (power 0 → vy=130 — ball goes up a bit then falls back into lane... hmm then reserve logic might trigger). For flipper test, do: state play via charge/release full, then immediately override ball: b.x=-11.5+4.5 (resting on flipper middle): place at (-7, 10.5)? flipper rest: from (-11.5,8.5) to (-3.36,4.67). Point on arm at s=0.5: (-7.43, 6.58). Ball resting ON arm: center = point + normal*(flipR+ballR). Normal to arm (pointing up-left of arm direction): arm dir (0.9,-0.42); normal (0.42,0.9): center = (-7.43+0.422.95, 6.58+0.92.95) = (-6.19, 9.23). Set v=0. Then press flipper: game.pressFlipper(-1, true). Step 0.25s in small increments, track max vy of ball. Assert maxVy > 150. Also assert ball doesn't NaN.

Hmm — with flipperE 0.42 and omega 34: contact s=0.5 → r=4.5 → u=153; normal up-ish → ball vy after ≈ u*(1+e)*n.y²... should exceed 150. Let me assert > 120 to be safe... I'll see the actual value from the test run and tune.

Test 7 full orbit: charge full (power 1 → vy=640). Step at dt=1/240 until ball.x < 26 && state play (max 6s). Assert. Also ball shouldn't have drained.

Soak test: run game with AI: if state serve → charge 0.85+rand*0.15 release. If play: for each ball, if ball.y < 25 and |ball.vy|... flip when ball below y=20 and moving down and |x - flipperzone| < 16: press both flippers 0.12s pulses. Random nudges occasionally (within tilt limit). Run 180s at dt=1/240 — that's 43200 steps; each step iterates ~80 colliders × balls — fast enough in node (<2s hopefully).

Assertions soak: every 240 steps check all balls finite and within x∈[-40,40], y∈[-15,135]. At end: no crash, score >= 0, ballNum <= 3... game may reach gameover — then startGame again? Keep going: if gameover → startCharge to restart. Count drains; assert drains > 0 (AI isn't perfect) — actually AI might be decent; just assert sim ran and at least one drain OR score > 0. Let me assert score > 100 (bumpers hit) to prove gameplay happened. Hmm, AI flippers might keep ball alive long... 180s should produce some bumper hits. Assert score > 500.

Also test launch speed sanity: after full launch, ball reaches top arc: max y > 120 during orbit. Assert.

Now let me also double check the sweepSegCapsule for a subtle bug: the "already overlapping side" branch uses consider(0, ...) — t=0 hit every substep while pressing in — good for resting contact.

But there's an issue: resting ball on floor with gravity: each substep ball gains vy = gdt (negative), sweep returns t=0 overlap... wait is the ball overlapping at start? After resolve + pushout 0.012, ball sits slightly above surface. Next step: gravity pulls, sweep from non-overlapping: wc slightly less than R... vcsign(wc) <0 branch requires |wc| <= R — if ball is 0.012 above, |wc| = R + 0.012 → not <= R → falls back to the quadratic/linear solve: t = (R - wc)/vc with wc > R, vc < 0 → t = (negative)/(negative) = small positive — contact found. Good.

Resting ball energy: resolve with e=0.3 guide: ball bounces with decreasing amplitude and settles via the t≈0 contacts. Fine.

One more important check — ball launched up the lane at 640: CCD handles. Substep dt = 1/240 → moves 2.7/substep. Sweeps fine.

Ball-ball during multiball — collideBalls after steps. OK.

Now, one potential issue in earliestHit: colliders count ~90; balls ≤3; substeps 240/s → 903240 = 65k sweep calls/sec — trivial.

Edge: skillTimer starts at launch; rollover before launch (impossible—ball locked). OK.

checkSensor for spinner — any direction triggers. OK.

Note: targets with dir 'negX' — ball must be moving left when crossing. ✓

Also onColliderHit for 'lane' tag — the inner lane wall gets tagged 'lane'; hard hits → thock. OK.

Alright — also I realize the rollover lanes are at y=86 but the inner arc region: ball coming down from orbit at left wall passes x≈-33, not through lanes. Skill shot: soft plunge drops from arc end (15.2,117.7) → falls down near x 12-16 → lane 2 (x 9..21). Plausible.

Also — what about ball slowly rolling on TOP of the inner arc end? The inner arc ends at (15.2, 117.7) with tangent (-sin0.96, cos0.96)=(-0.82,0.57). Ball resting on the arc near the end slides off (slope steep). OK.

And ball entering the region between arc end and outer wall from BELOW (playfield): can roll up the inner arc exterior? Inner arc is solid from both sides (capsule). Ball in upper playfield bouncing around — fine.

Potential trap: the notch between inner arc end (15.2,117.7) and outer arc — gap width 7.5 → ball from playfield can fly up INTO the lane channel between arcs and come back down the lane to the plunger → sits in lane → reserve logic handles (single ball) → re-serve. During multiball auto-relaunch.

Potential trap: resting on top of bumper? Bumpers kick → can't rest. Posts are small circles. Rollover posts on the playfield with nothing above — ball can rest on a post top? Post r=1.0 at y=86 — ball could balance momentarily but e=0.85 bouncy — it'll roll off. Any contact → tiny tilt → rolls off. OK.

Trapped between target wall and posts? Open area. OK.

I think the design is solid. Write test.mjs now.

Good progress — 41/50 pass. Failures to fix:

1. maxY=115.1 < 118: full launch at 640 loses too much speed. Energy: v=640 at y=3.2 → at y=96 (arc center height): v² = 640² - 2950(96-3.2) = 409600 - 176320 = 233280 → v=483. To reach y=130 (top): v² = 409600 - 2950126.8 = 409600-240920=168680 → v=411 — should reach 130! But measured maxY=115.1. Something is slowing the ball in the lane: drag (0.018/s over ~0.3s → ~0.5%) not much. The lane floor friction? Ball starts at y=3.2 locked; unlocked with vy=640 — no floor contact (moving up). Lane walls: ball at x=30.25, lane x 26.5..34: ball r 1.35, walls have r 0.6 → gaps: 30.25-26.5=3.75 vs 1.95 contact dist — no contact. Hmm.

   Wait — the inner arc: r=26.5 from angle 0 to 0.96. Ball in lane at x=30.25 follows outer arc r=34: distance from center (0,96) is 30.25 at y=96 → the ball is at radius 30.25 from arc center, which is between inner (26.5+0.6+1.35=28.45 contact radius) and outer (34-0.9-1.35=31.75 contact radius). OK ball spirals up between arcs. But wait — my test says "ball looped into the playfield (x=25.2, y=115.1)" — the ball EXITED at x=25.2, y=115.1: it fell off the inner arc end region back DOWN at x≈25. So it never went over the top: it lost speed and dropped at the arc end. Why so slow?

   Energy says it should make it. Unless... drag: v = (1-0.018dt) each step — at dt=1/240, that's 0.999925^240 ≈ 0.982/s. Over 0.5s ≈ 1% — negligible.

   Hmm, let me reconsider: the ball enters the arc region moving straight up at x=30.25. The outer arc at x=30.25: angle θ where 34cosθ=30.25 → θ=0.477 rad; y=96+34sin(0.477)=96+15.6=111.6. The ball moves up from y=96 at x=30.25 and hits the outer arc at (30.25, 111.6)-ish... the arc surface normal there points toward center: (cos0.477, sin0.477)=(0.888, 0.459) — normal from wall to ball = -(0.888,0.459) = (-0.888,-0.459). Ball velocity (0, +483). vn = v·n = 483*(-0.459) = -221.7. Bounce with e=0.42: reflect → the ball's path deflects left. Then follows along... each collision with the arc eats energy (e=0.42!). The arc is TESSELLATED into 44 segments, so the ball doesn't roll smoothly — it bounces chord-to-chord, losing 58% of normal velocity each bounce. That's the energy leak: tessellation + low restitution = the ball clatters around the arc instead of rolling.

   Fixes: (a) increase wall restitution for arcs (e.g., 0.9); (b) more segments (smoother); (c) reduce friction. The real issue: my collision resolve applies restitution to the full normal component; for grazing impacts the normal component is small, but the tessellation corners create non-grazing hits.

   Better approach: for arc segments use high restitution (0.85) and zero friction. Rolling contact in reality has almost no energy loss. Let me set arc/wall e higher: walls 0.6, arcs 0.85 with f=0.01. Let me also increase tessellation: outer 64, inner 24.

   Also lower the launch requirement: plungerMax 640 might still suffice after fix. Let me compute needed speed at lane exit to round the arc: at top (0,130) need v_top such that gravity doesn't pull ball off outer arc: v²/r ≥ g·cos... at top, centripetal points down (toward center (0,96)): v²/32.65 ≥ 950 → v ≥ 176. Energy: v_lane² = v_top² + 2g·Δy = 176² + 2950(130-3.2)... wait ball center radius: ball rides at r = 34-0.9-1.35 = 31.75 from center; top of ride y = 96+31.75 = 127.75. v² = 176² + 2950(127.75-3.2) = 30976 + 236645 = 267621 → v ≥ 517 at launch. With e=0.85 arc bounces, 640 should be plenty. And min plunge 130 barely leaves the lane (reaches y ≈ 3.2+130²/1900 = 12) — rolls back → reserve. Good.

2. Rollover lanes double-trigger ([0,1,1,2]): lane 1 fired twice. The ball after crossing lane sensor continues down, then I teleport to next lane... cooldown 0.35s per ball per sensor. Test: teleport ball to (lx, 90) vy=-120: crosses y=86 in 0.033s. Then 120 steps = 0.5s... wait after crossing, ball continues down; for lane 1 test the ball from (0,90) falls, crosses sensor at 86 → 'rollover' lane 1. Continues falling to y<80 → break. Then teleport to (15,90): new sensor. But the EXTRA lane-1 event: when ball from lane 0 test (x=-15) continues falling... no. Hmm [0,1,1,2]: during lane-1 (x=0) drop: ball falls from 90 vy=-120 crosses at 86 once (cooldown 0.35). Loop runs until b.y<80: from 86 to 80 at ~120 u/s = 0.05s — under cooldown. Then teleport to (15,90) — teleport moves ball INSTANTLY from wherever to (15,90): checkSensor uses b.px,py = previous position! Teleporting between steps: I set b.x but the next step sets px=x at start... stepBall sets b.px=b.x at start — so teleport is clean. BUT: teleporting from (0, ~79) to (15, 90): no step runs between → px updated correctly.

   Wait, actually the double trigger: cooldown key includes ball id and sensor id: ${b.id}:s${s.id}. Hmm — in checkSensor I compute c0 with b.px and c1 with b.x — but stepBall sets b.px=b.x at START, then the while loop may move b multiple times; sensors checked at END with px=py=position at step start. Fine.

   Why did lane 1 fire twice? OH — the 'skill' shot! skillTimer active 4s after launch: lane cycling. The rollover for lane 1 (lit) → emits 'rollover' twice? No wait — look at the code: if lane NOT lit → emit; else → emit also! Both branches emit 'rollover'. The list [0,1,1,2]: one lane emitted twice. Which? Sequence: ball at (-15,90) → lane 0: not lit → lit, emit lane 0. Ball at (0,90) → lane 1 → emit lane 1. Ball at (15,90) → lane 2 → emit lane 2, all lit → reset + mult. That's [0,1,2]. Got [0,1,1,2] — lane 1 fired twice. Because during lane 0's drop (120 steps = 0.5s until y<80): the ball from (-15,90) falls through y=86 → lane 0. Then continues to y<80. Then teleport (0,90) → lane 1. Hmm.

   Unless... the ball dropped from (-15,90) after crossing lane 0 falls and lands on... nothing. Then teleport to (0,90). During lane-1 drop: crosses (sensor between posts at ±8... sensor 1 spans (-7,86)-(7,86)). Ball at x=0 crosses → lane 1 lit, emit. Ball continues down; between y 84.65 (center at sensor when ball edge)... cooldown 0.35s. Loop breaks when y<80.

   Then teleport (15,90) → lane 2 → emit, all lit → reset lanesLit → mult event. THEN the loop for (const [lx] of lanes) is done. So where's the 4th event [0,1,1,2]??

   AH WAIT. I see it — the test for lane 0: after crossing lane 0, ball keeps falling from 86 to 80 — but the previous tests?! No, fresh game. Hmm — let me look at the test loop: after teleporting to (lx,90), for i<120: step; if b.y<80 break. During lane-0: ball starts at 90 vy=-120; gravity accelerates; crosses 86 quickly; y<80 after ~0.06s. drainEvents after each step → collect. Then lane 1: teleport...

   OH WAIT. I see it! The skill lane: skillTimer — after launch, skillTimer = time+4. When ball crosses the LIT skill lane → also emits 'skill'. Not a rollover though.

   Hmm, let me think about the BUMPER path: ball from lane-0 drop at (-15, 90): falls to y<80 — bumper 2 at (-13.5, 64) not reached (break at 80). OK.

   Actually — maybe the issue: teleport from lane0 end position (-15, 79.x) to (0, 90): I set b.x=0, b.y=90 directly, BUT b.px, b.py still hold old values until stepBall runs. First g.step → stepBall sets px=x=0,py=y=90 first thing. So crossing detection uses (0,90)→newpos. Clean.

   Hmm wait — the drainEvents call inside the lane loop: for i<120: step; evs.push; if y<80 break. And the outer for (const [lx] of lanes). After lane 2, all lit → RESET lanesLit to false and mult++. Fine.

   So why [0,1,1,2]? Let me add: maybe when I teleport to (0,90) the ball is EXACTLY on sensor 1's x-range but the FIRST step: px=(0,90) — fine.

   Alternatively the extra "1" came from the 4-second skill window expiring? No.

   Hmm — actually! The rollover sensor check ALSO triggers when the ball crosses the segment EXTENDED?? No, proj check [0,1].

   Let me just debug: run a focused script. Actually — one more candidate: the lanes array destructuring for (const [lx] of lanes) — lanes = [[-15,0],[0,1],[15,2]] — lx = -15, 0, 15. Ball at (-15,90): sensor 0 spans (-21,86)-(-9,86) ✓. Ball at (0,90): sensor 1 (-7..7) ✓. Ball at (15,90): sensor 2 (9..21) ✓.

   Hold on — during the LANE-0 iteration, after break (y<80), the ball is at (-15, ~79). Next iteration teleports to (0,90). But BEFORE the next step, checkSensor hasn't run... The teleport itself: could the movement from (-15,79) to (0,90) cross sensor 1? Only if a step ran — stepBall resets px first. OK not that.

   Wait, maybe it's this: during lane-1 drop, the ball crosses sensor 1 at t≈0.03s, continues down... breaks at y<80 after ~0.07s. Cooldown 0.35s. Then lane-2 drop happens at +0.07s... teleport (15,90). BUT what about sensor 1? Ball teleports from (0,79) to (15,90) — no step between. First lane-2 step: px=(15,90). No crossing of sensor 1.

   Hmm hmm. Let me just add a debug print. Actually — GOT IT. Look at the test: after b.dead = false; for each lane — the ball might have been marked dead from the PREVIOUS drop?? No...

   Actually let me reconsider: during lane-0's 120 steps — I break when y<80, but the loop pushes events each step. Fine.

   OK let me just run a debug script rather than guess. Also — target test failures: "three target hits registered" failed — got fewer than 3 target events. Firing at y=48,54,60 from x=-20 vx=-260: ball crosses sensor x=-29.6 (dir negX ✓) then hits wall x=-31.5 (wall r 0.7, ball r 1.35 → contact at x=-29.45!!). WAIT: wall at x=-31.5 with r=0.7: ball center contacts at x = -31.5+0.7+1.35 = -29.45. The SENSOR is at x=-29.6 — the ball center NEVER reaches x=-29.6!! The ball stops at -29.45, sensor at -29.6 is BEHIND the contact surface. The ball can never cross the sensor! Move sensors to x=-28.9 (in front of contact surface -29.45). Gap: contact plane -29.45; sensor at -28.9: ball crosses sensor 0.55 before contact. ✓.

   Same issue pattern check — rollovers: sensors between posts: posts r=1.0 at ±8/±22, ball path between them unobstructed ✓.

3. Soak: flips=0, drains=0, score=250 — the AI never flipped! Because... the ball never came below y=26?? Score 250 accumulated (bumper + sling hits presumably early), then... drains=0 and balls=1: the ball got STUCK somewhere. Where can it be stuck for 3 minutes? Possibly resting in a dead corner: sling C corner? Between dead post and guide? Or balanced in the outlane pocket? flips=0 means ball never went below y=26 with vy<40 near flippers. So ball stuck above y=26 somewhere. Candidates: wedged under slingshot (between sling bottom edge and guide), resting on the spinner sensor region... Actually the most likely: stuck BETWEEN the target wall and its channel? Or resting on the lane floor after a weak AI plunge (0.75+0.25sin → sometimes low?) — min 0.5*... power 0.5 → v=385 → reaches y=3.2+385²/1900=81 — falls back down lane → sits on plunger floor at y=1.85 < 8 → reserve logic: state='serve'... then AI charges/releases. OK that works.

   Score 250: 2 bumpers + 1 sling maybe, then stuck. Let me debug with a script: run soak with periodic ball position print to find the stuck spot.

   Possibly the ball rests ON TOP of the sling back side (seg B(-16,29)→C(-27,23))? A ball can land in the V between sling edge and guide? The sling sits with C at (-27,23), guide at x=-27 is y=23.35 — C is just below the guide line! Ball in the pocket between the sling back edge (B→C line) and guide top: it's a wedge — ball slides down along guide to flipper. Hmm.

   Or stuck between dead post (-24.5,33.5) and sling A(-27,41)? Gap: dist((-24.5,33.5),(-27,41)) = √(6.25+56.25)=7.9.

   Or ON TOP of the lane inner wall end (26.5,96)? Ball landing on the wall cap (r=0.6): cap at (26.5,96)... the inner arc starts at (26.5,96) — continuous.

   Or stuck in the notch where inner arc ends (15.2,117.7): ball balancing on the arc end cap? Possible: ball drops vertically onto the arc end tip and rests. End cap is a tiny circle r=0.6+1.35; a ball could balance but unstable... with e=0.3 and friction it might settle ON the cap tip! Then it's trapped: contact normal vertical, gravity balanced. That's a real trap spot. Fix: extend inner arc to a steeper angle (end at 1.2 rad ≈ 69°) so the cap is steep, or add a small "post" kicker... Actually ending at a steeper angle makes the cap surface normal more horizontal → ball slides off. End at 1.1 rad (63°): tangent angle 63+90=153° — the cap's top point normal at... hmm the cap is round — a ball CAN balance on a round cap in theory (unstable equilibrium) but numerically with pushout it might sit. Give the arc end a downward hook instead: after the arc, add a short seg angled down-left so balls always slide off into the playfield. E.g., from arc end at angle 0.96 (15.2,117.7) add seg to (11,112) — a deflector pointing down-left. Ball landing there slides down-left into playfield. Ball in the lane channel passes UNDER this hook? The hook protrudes into the channel between the arcs?? The channel is between r=26.5 and r=34; hook from (15.2,117.7) to (11,112): distance from center (0,96): (11,112) → r=√(121+256)=19.4 — inside the playfield (below the inner arc surface). The channel at angle θ=0.96 spans r 26.5..34; hook end at r 19.4 is INSIDE (toward center) — so the hook protrudes from the inner arc end INTO the playfield, not blocking the channel. Balls in the channel stay between r 26.5+ and 34. Ball launched slow up the lane hits... hmm the hook seg (15.2,117.7)→(11,112) — the lane channel ball hugging the inner arc would collide with the hook start. But that's fine — the hook only exists AT the arc end; a ball reaching the arc end along the inner arc has enough speed to go over the top (it's at the channel exit). A slow ball falls off before reaching the end. OK.

   Hmm wait — actually, is the trap elsewhere? Let me debug the soak to find where the ball actually got stuck rather than guessing. I'll write a quick debug script.

4. Also fix arc restitution/tessellation for the orbit.

Let me write debug.mjs to (a) trace the launch trajectory, (b) find soak stuck position.

Two findings:

1. Launch: ball goes up at 544 (after ~0.1s), reaches (27.6, 110.6) with v=(-189, 362), then exits at x=25.2, y=115.1 — it fell off the INNER arc end at (15.2,117.7)... wait no, exit at x=25.2, y=115.1 means it left the lane (x<26) at y=115. The inner arc ends at (15.2,117.7). Hmm — ball at (27.6,110.6): distance from center (0,96) = √(27.6² + 14.6²) = √(761+213) = 31.2 — riding between arcs (26.5+0.6+1.35=28.45 to 34-0.9-1.35=31.75). Ball at 31.2 is hugging outer. Then at t=0.21 it exits at (25.2, 115.1): r = √(25.2²+19.1²)=√(635+365)=31.6 — still on outer arc. x went from 27.6 to 25.2 — it IS moving around the arc (angle decreasing from 0.49 to... cos θ = 25.2/31.6 → θ=0.65 rad). The test's exit condition b.x < 26 triggered while the ball is legitimately still on the outer arc — x<26 but y=115 > 20 — my test condition said b.x < 26 && b.y > 20 → "entered playfield" — that's TRUE while orbiting! The test condition is wrong, not the physics... but maxY=115.1 at exit: let me trace longer. The ball is curving around the outer arc — at t=0.21 it's at angle 0.65 rad with speed √(189²+362²)=408. It should continue to θ=π/2 (top). Let me extend the trace. The velocity at t=0.2: (-189, 362) — pointing up-left — following the arc. Looks healthy! maxY will exceed 118 as it rounds the top. The test just stopped early. Fix test: entered when b.x < 26 && b.y < 100 (came down into playfield) or track full trace. Actually a cleaner condition: entered when ball crosses below y=96 with x < 26 (came down the middle) OR when it reaches the left wall region x < -30 (full orbit). Let me trace to 6s and print more.

2. Stuck at (-29.06, 28.15): that's near the target wall bottom (-31.5, 26.5) and the guide. Ball at x=-29.06, y=28.15. The guide at x=-29.06: from (-34,30) to (-14,11): slope -0.95: y = 30 + (x+34)(-0.95) = 30 - 4.940.95... wait x+34 = 4.94 → y = 30 - 4.69 = 25.3. Guide surface (r 0.7) top: ball resting on guide would have center at 25.3 + (0.7+1.35)cos(normal angle)... normal of guide: dir (20,-19)/27.6=(0.725,-0.689); normal (0.689,0.725): center y ≈ 25.3 + 2.050.725 = 26.8. Ball at 28.15 — above the guide. Target wall at x=-31.5 r=0.7: contact plane x = -31.5+0.7+1.35 = -29.45. Ball at x=-29.06 — close to wall contact. So the ball is WEDGED between target wall (pushing +x) and guide top surface (pushing up-left-ish)?? The corner where target wall bottom (-31.5, 26.5) meets the guide — the guide passes through (-31.5, 26.4)... The wall END CAP at (-31.5, 26.5) is a circle r=0.7. The ball rests ON the wall end cap while pressed against... hmm at (-29.06, 28.15): distance to wall line x=-31.5 is 2.44 ≈ 0.7+1.35=2.05 + a bit. Distance to cap (-31.5,26.5): √(2.44²+1.65²)=2.94 > 2.05. Distance to guide line: ball y 28.15 vs guide at that x: 25.3 + ... signed distance: point (-29.06,28.15) to line through (-34,30) dir (0.725,-0.689): w=(4.94,-1.85); cross = w×d = 4.94*(-0.689) - (-1.85)(0.725) = -3.40+1.34 = -2.06 → |d|≈2.06 ≈ contact distance 2.05. So ball is ON the guide surface AND near the wall — it's wedged in the obtuse corner between guide top surface and the target wall. The guide normal pushes up-right (0.689, 0.725); wall pushes +x (1,0). Gravity (0,-950). Net: guide normal force up-right, wall pushes right... the horizontal: guide pushes +x 0.689N, wall pushes... ball pressing INTO wall? Wall at left pushes +x. Both push +x! Then ball should slide +x down the guide. Why stuck? FRICTION: guide f=0.08? No — Coulomb-ish friction here removes a FRACTION of tangential velocity per contact (0.08), can't hold a ball. Hmm.

   Wait, maybe it's wedged in the CORNER between guide top and the target wall BOTTOM CAP. The corner formed by guide line and wall bottom cap at (-31.5,26.5): a ball sitting on the guide and touching the cap... the cap pushes radially from (-31.5,26.5): ball at (-29.06,28.15): dir (2.44,1.65)/2.94 = (0.83,0.56) — pushes up-right. Guide pushes (0.689,0.725) up-right. Gravity down. Equilibrium? Sum of normals ~ (1.5,1.3)N vs gravity. Possible static equilibrium only with friction... my friction model removes tangential velocity fraction each contact, effectively a damping that CAN create numerical sticking in corners: each substep, gravity adds vy -= 950/240 = -3.96; sweep finds t=0 contact (overlapping); resolve: vn<0 → reflect with e → vy' = +0.33.96*n.y²... tiny bounce; friction cuts tangential by 8%; pushout 0.012. Next step repeats. The ball should still creep... unless the two contacts alternate cancelling: corner traps can occur when restitution is low and pushout fights. But 5 seconds of stillness (rounded position same) — v=(-0.78,-0.77) tiny — it's basically parked.

   Real fix: eliminate the trap geometry — the channel between target wall and outer wall should SEAL at the bottom so balls can't enter, OR open it fully so balls fall through to the guide cleanly. The trap is the concave corner: wall bottom cap + guide. Solution: extend the target wall DOWN to meet the guide exactly, removing the notch: wall from (-31.5,63) to (-31.5, 26.9) and move guide start... they already nearly touch. The trap is ON TOP of the guide at the wall base — the ball comes down the channel (x -34..-31.5) and lands on the guide at the steep corner...

   Wait — actually how did the ball get to (-29, 28)? That's RIGHT of the wall (-31.5). It's sitting on the guide just below-right of the wall bottom. The pocket: above the guide, below the sling C(-27,23)... hmm no, sling C is at y=23 < guide 25.3 at x=-27?? Earlier I computed guide at x=-27: y=23.35. Sling C at (-27,23): the sling's C corner is INSIDE/under the guide line. The sling back edge B(-16,29)→C(-27,23) — at x=-27, that's C. So near x=-27..-29, above the guide, there's a low ceiling? No ceiling — the sling is to the right (x≥-27).

   The pocket at (-29, 28): bounded left by target wall (x=-31.5, from y=26.5 up to 63), below by guide. Right: open. The ball rests on the guide and touches the wall. Why doesn't it roll down the guide (toward -14,11)? Guide slope: from (-34,30) to (-14,11) — descending toward +x. Ball on guide at x=-29 should accelerate +x... The tangential gravity component: g_t = 950*sin(slope angle)= slope angle atan(0.95)=43.5°... sin=0.69 → 655 u/s² along the slope. That's strong! It CANNOT rest unless something blocks +x motion. What blocks it? The WALL pushes +x, doesn't block. UNLESS the ball is wedged UNDER something: what's above the ball at (-29, 29.5)? The target wall is at x=-31.5 (left). Hmm... what about the wall END CAP? No.

   Wait — maybe it's wedged between the guide BELOW and the target wall's bottom cap pressing DOWN-left: cap center (-31.5, 26.5): if ball is at (-29.06, 28.15), cap pushes along (0.83, 0.56) — up-right, not down. So no.

   Let me instrument: print contacts during the stuck state. Actually, let me reconsider: maybe the ball is NOT on the guide: it might be wedged between target wall (left) and... the SLING? Sling C(-27,23), A(-27,41): the seg C→A is the vertical seg x=-27 from y=23 to 41! Ball at x=-29.06: distance to seg x=-27 is 2.06 ≈ contact distance 2.05!! THE SLING BACK WALL (x=-27, y 23..41, r 0.7)! The ball is wedged between the target wall (x=-31.5) and the sling back wall (x=-27) — a vertical channel 4.5 wide... wait ball needs 2.7 + wall r's 0.7+0.7 = 4.1 < 4.5 — ball fits in the channel but barely, and the channel bottom is the guide corner... The channel x∈[-31.5,-27] (walls both sides, contact planes at -29.45 and -29.05): ball center range x ∈ [-29.45, -29.05] — a 0.4-wide slot!! The ball falls into the slot between target wall and sling back, and at the bottom the guide... the guide at x=-29.3: y=25.0, contact plane ~26.5... The ball sits in the slot on the guide corner. It can't move horizontally (slot), can't roll down (guide below slopes into the wall corner). TRAPPED.

   Root cause: gap between sling back (x=-27) and target wall (x=-31.5) = 4.5, ball diameter 2.7 + capsule radii 1.4 = 4.1 → ball squeezes in with 0.4 to spare. Real tables have this as the "behind the sling" dead space — blocked by a post or rubber. Fix: move slings so the gap is either < ball-through size or comfortably bigger. Options: (a) move target wall RIGHT to x=-29.5?? Then gap to sling back (-27) = 2.5 < 2.7 ball — sealed. But then targets protrude more into playfield — fine (targets at x=-29.5, sensor at -27.9, contact plane -28.45...). Gap behind: -29.5 wall to outer wall -34: 4.5 channel again on the OUTER side! That outer channel funnels to the guide — is IT a trap? Channel x∈[-34,-29.5]: contact planes -33.1 and -30.55 → slot 2.55 wide for ball center — ball (center range 2.55) fits... same trap potential at its bottom where guide passes (-31.5→ y 26.4)... The channel bottom: guide crosses x=-30.55 at y = 30+3.45*(-0.95)=26.7. The slot bottom lands on the guide at the obtuse corner between outer wall and guide — the guide slopes down AWAY from the outer wall (toward +x): ball in the channel lands on the guide corner where wall meets guide — but the wall ENDS at y=30 (outer wall from y=6..96 — wait the outer wall goes down to y=6! S(-34, 6, -34, 96). The guide starts at (-34,30) ON the wall. So the channel between outer wall and target wall bottom is bounded at bottom by the guide which slopes down-right away from the wall — a ball there rolls DOWN-RIGHT along the guide, EXITS the channel bottom (target wall ends at 26.5) → onto the guide → flipper. NOT trapped because the guide leads out.

   The trap was specifically the slot between sling back (x=-27,23..41) and target wall (x=-31.5): both walls VERTICAL, bottom closed by guide corner. If I move the sling left so its back wall is at x=-30.5: gap to target wall (-31.5) = 1.0 → sealed (ball can't enter). Then sling face A(-30.5,41) B(-19.5,29) C(-30.5,23). Hmm but then the sling protrudes and its face is steeper. Also the channel between target wall and OUTER wall remains but drains safely.

   Wait, actually simpler: keep sling shape/position, but SEAL the slot: add a filler seg from sling C(-27,23) to the target wall bottom (-31.5, 26.5)?? That creates a little ramp — ball landing on it slides... toward +x down the guide. Direction from (-31.5,26.5) to (-27,23): slopes down toward sling... ball on this filler rolls toward C corner then onto guide corner → down the guide. The filler + guide corner: at C(-27,23) vs guide at x=-27 y=23.35 — C is BELOW the guide surface?? C corner pokes through the guide. Ugh.

   Cleaner: redesign the sling as a full triangle attached to the target wall — move sling so its back side IS the target wall: sling A(-31.5,42) B(-20,29) C(-31.5,22)? Then back side from C to A lies on x=-31.5 coincident with the target wall seg (which spans 26.5..63 — overlap region 26.5..42 — two colliders at same place, harmless). No slot. The sling face A→B: from (-31.5,42) to (-20,29): normal (13,11.5)/17.4=(0.75,0.66) up-right — kicks up-right. Good. Mirror on right against lane wall x=26.5: A(26.5,42) B(15,29) C(26.5,22)? Wait the lane wall x=26.5 spans 0.5..96 ✓. Right sling face (26.5,42)→(15,29): dir (-11.5,-13), normal (-0.75,0.66)... perp of dir: (13,-11.5) or (-13,11.5)/17.4 → normal into playfield = (-0.75, 0.66) — up-left ✓.

   And the dead posts at (-24.5,33.5)/(20.5,33.5) — those were near the OLD sling positions; with new slings the dead posts might overlap the sling faces: left sling face from (-31.5,42) to (-20,29): at x=-24.5: param t=(-24.5+31.5)/11.5=0.61 → y = 42-0.6113=34.1. Dead post at (-24.5,33.5) is 0.6 BELOW the face — overlapping! Remove dead posts or relocate: put dead posts at the guide starts? Actually just remove the dead posts (they were decorative). Or move them: left dead post at (-20, 18)? On the guide at x=-20: y=16.7 — the post would sit on the guide... posts above guides are classic "inlane posts". Post at (-17, 17): guide at -17: y=30+17(-0.95)=13.85; post at (-17,17.5) hovers above guide... gap for ball to pass under to flipper: ball rolls down guide at center y≈15.3; post bottom 17.5-1.0=16.5 vs ball top 15.3+1.35=16.65 — collision — blocks the lane! Skip dead posts entirely. Remove them.

   Also check: new left sling B(-20,29) vs guide at x=-20: y=16.7 — clear (B is 12 above). New left sling C(-31.5,22) vs guide at x=-31.5: y=26.4 — C is BELOW the guide by 4.4?! The sling back side C→A at x=-31.5 from y=22..42 overlaps the target wall (fine) but C pokes below the guide surface — the triangle corner sticks through the guide into the outlane channel. Physically the colliders just overlap; a ball on the guide near x=-31.5 also touches the sling edge B→C from (-20,29) to (-31.5,22): at x=-27: param t=(-27+20)/(-11.5)=0.61 → y=29-0.61*7=24.7 vs guide 23.35: the B→C edge is 1.4 above the guide — ball rolling down the guide (center 1.4 above) grazes it — fine, both lead down. OK, acceptable overlap; no trap since everything slopes to the flipper.

   Hmm wait, one more check on the right: right sling B(15,29), C(26.5,22): edge B→C from (15,29) to (26.5,22): at x=20: y=29- (5/11.5)*7=25.9; guide at x=20: y=28+(20-26.5)*1.36=19.2 — clear by 6.7. OK.

   And the previous trap channel x∈[-34,-31.5] (outer wall to target wall): ball falls in from... the top? Channel top: target wall top at (-31.5,63), outer wall continues to 96. Ball can enter the channel from above (x -34..-31.5, y>63): gap width 2.5 < ball 2.7 → CANNOT enter. Sealed ✓. And below 63: ball enters from the left side over the target wall? From the playfield, crossing x=-31.5 below y=63... the target wall is solid 26.5..63. Below 26.5: gap between wall bottom (-31.5,26.5) and guide (at x=-31.5, y=26.4) ≈ sealed ✓. So the channel is unreachable.

   Then how did the soak ball GET to (-29,28)? Via the OLD sling slot. With the new design that slot is gone.

3. Fix rollover test double-trigger — still unexplained. Let me debug that too. And target sensors move to x=-28.9 (with wall staying at -31.5 — wait if sling moves to x=-31.5 back side, the target WALL stays -31.5 — but sling now overlaps the target wall region... the target wall seg spans 26.5..63 and the sling back 22..42: same x — double collision at same plane, harmless. Targets (sensors) at x=-28.9, y 45.6..62.4: above the sling (42) ✓.

   Hmm — but wait: with the sling back side ON the target wall line, the region right of the wall from y 22..42 has the sling triangle; targets at y 45+ on the same wall — consistent.

4. Launch test fix: change "entered" condition to b.x < 26 && b.y < 96 (came down into the playfield) and extend trace. Also relax maxY assert to > 122 (ball center max possible = 96+31.75 = 127.75).

Let me now apply the table changes:

• Slings: left A(-31.5,42) B(-20,29) C(-31.5,22); right A(26.5,42) B(15,29) C(26.5,22).
• Remove dead posts.
• Target sensors at x=-28.9.
• Arc segs: e=0.85, f=0.01 (both), more tessellation (outer 64, inner 20).
• Also increase outer wall e slightly? Keep 0.42 for walls, 0.85 arcs.

Wait, actually for the orbit the ball rides the OUTER arc (e should be high) — and the INNER arc matters when ball slowly rolls down it. Set both arcs e=0.85, f=0.01.

Also check bumper test passed with old positions — bumpers unchanged.

For the rollover mystery — let me add a debug trace after the fixes. Actually, let me think again... OH WAIT. I think I see it now! In the rollover test: after the lane-0 drop breaks (b.y<80), the ball continues falling in subsequent tests' steps... no. Hmm, but actually — during the LANE-2 iteration: ball at (15,90) falls, crosses sensor 2 → all lit → RESET + mult. Loop ends. THEN... the events list already had [0,1,1,2] meaning the extra lane-1 came BEFORE lane 2. During lane-1's own iteration: ball crosses sensor 1 once. Unless the ball crossed sensor 1 TWICE within lane-1's iteration: ball from (0,90) vy=-120 falls through 86... breaks when b.y<80 — from 86 to 80 at ~130 u/s ≈ 0.046s < cooldown 0.35 → can't retrigger. Hmm...

Unless the events from the PREVIOUS test leaked? No — fresh Game per test. But wait — within THIS test, before the lane loop, the launch: ball shot up the lane at 640, goes around... and we then TELEPORT it for lane 0. But the launch ball might have crossed rollover sensors during its orbit before being teleported!! The orbit: up the lane x=30.25, around the top arc — sensor 1 spans x -7..7 at y=86 — the arc path stays above y=96 until it comes down the left side... the test teleports the ball after 0 steps! Look: g.startCharge(); g.plunger.power = 1; g.releaseCharge(); const b = g.balls[0]; b.x = -15; b.y = 90... — immediate teleport, no steps between releaseCharge and teleport. BUT releaseCharge sets b.vy=640, then test sets b.vx=0,b.vy=-120. Clean.

Hmm — but the FIRST drop (-15, 90): sensor 0 spans (-21,86)-(-9,86) — ball at x=-15 crosses → 'rollover' lane 0 ✓ lit. Continues down... breaks at y<80. Second drop (0,90): sensor 1 → 'rollover' lane 1 ✓. Continues down, breaks. Third drop (15,90): sensor 2 → 'rollover' lane 2 → all lit → reset, mult. [0,1,2]...

Hold on, [0,1,1,2] — is it possible that during drop 1, the ball drifted? vx=0, gravity only — falls straight at x=-15, sensor 0 spans -21..-9 ✓ once.

What if sensor 0's emit happened TWICE: once on the way... no, [0,1,1,2] shows 0 once, 1 twice.

OK here's another thought: the skill shot! skillTimer = time+4 after launch. The whole lane test takes < 1s. Skill lane cycles every 0.8s starting at lane 0. When the ball crosses the LIT skill lane... look at my rollover code: if isSkill and lane NOT lit → emit rollover + skill. If lane lit and isSkill → the else branch: addScore(100) + emit rollover + skill. Wait — that still emits ONE rollover per crossing.

Hmm, could the ball cross the sensor during the settle steps AFTER the loop? No — loop is the last thing before assertions.

You know what — let me just debug it directly instead of theorizing.

Actually WAIT. I see it!! In the test:

b.dead = false — why did I write that? If the ball DRAINED during a previous drop (fell all the way down — 120 steps = 0.5s: from y=80 at -120 u/s with gravity → reaches drain y=4.2 in ~0.35s → marked dead, removed from balls, onDrain → serveNext → NEW BALL spawned at lane locked!). Then b (the old dead ball) is no longer in g.balls but I keep teleporting it — harmless (not stepped)... but serveNext created a NEW locked ball in the lane. Then state = 'serve'... but sensors for old ball b aren't checked since it's removed. Hmm but then events from the new ball? It's locked → no stepping → no events.

But 120 steps at vy=-120 from y=90: time to fall from 90 to 80: ~0.06s → break at i≈15. So no drain. UNLESS... first drop: from (-15,90): falls, crosses at 86, breaks < 80 after ~0.07s. OK.

Ahh, let me just run the debug. Enough theorizing. Let me apply the geometry fixes first, then debug the rollover with prints if still failing.

Also the soak AI flip condition required b.y < 26 && b.vy < 40 AND x in flipper range — with the stuck ball fixed, AI should flip. But note the AI holds flippers while condition true (I changed to direct pressFlipper(wantL)) — in the test.mjs soak I use flipHold timers. Fine.

Let me apply core fixes now.

**********************************************************************************************************************************************************************ts.

Wait — posts at (±17.5, 19.5): check they don't block the guide→flipper path. Left guide from (-34,30) to (-14,11): at x=-17.5, guide y = 30 + (16.5)(-0.95) = 14.3. Ball rolling on guide: center at 14.3 + 2.05*0.725 ≈ 15.8. Post at (-17.5,19.5) r=1.0: distance from ball center path = |19.5-15.8| = 3.7 > 1.0+1.35=2.35 — clear ✓. The post sits in the outlane pocket between guide and flipper — partially blocking the drain pocket (good, that's their job) but not sealing it. Gap from post to guide: post top 19.5+1.0=20.5 vs guide line at 14.3... the post is ABOVE the guide?? Wait — at x=-17.5 the guide surface is at y≈14.3 (the line). The pocket below the guide... the post at y=19.5 is ABOVE the guide line — in the playfield! Hmm: guide from (-34,30)→(-14,11): points below the line at x=-17.5 are y<14.3. Post at 19.5 is 5.2 above the line — it's in the playfield, floating. Ball passing over the guide at higher y would hit it. That's fine — it's a playfield post near the sling exit. Check sling clearance: new sling B(-20,29), edge B→C from (-20,29) to (-31.5,22): at x=-17.5? The edge starts at x=-20; post at x=-17.5 is right of B — clear of the triangle. Distance from post (-17.5,19.5) to B(-20,29): √(6.25+90.25)=9.8 ✓.

Hmm wait, but do these posts make sense? A post at (-17.5, 19.5) — ball falling down the playfield left side hits it, bounces (e 0.85) toward flipper or outlane. That's the "outlane post". OK.

But check the ball rolling down the guide clears it: ball center at guide normal offset 2.05: at x=-17.5: center ≈ (14.3 line) → contact plane offset along normal (0.689,0.725)*2.05 → center y ≈ 14.3+1.49=15.8, x ≈ -17.5+1.41=... the ball center is offset in +x along normal too: center x = -17.5 + 1.41 = -16.1 at closest. Distance from (-16.1,15.8) to post (-17.5,19.5): √(1.96+13.7)=3.96 > 2.35 ✓ clear.

Now fix the launch test: 'entered' condition should be ball below y=96 in playfield or reaching left wall. Change to b.x < 26 && b.y < 96. And keep maxY assert > 122.

Also debug rollover double-trigger. Let me add a focused debug after updating tests. First update test.mjs conditions.

Also fix the table sanity test — circles now: 3 bumpers + 4 rollover posts + 2 outlane posts = 9. Still 9. OK.

Now the rollover double-trigger debug. Let me write a focused test to see why lane 1 fires twice. Actually — wait, I should check something in the rollover test: after the ball drops through lane 0 and falls to y<80, the loop breaks. But then for lane 1 we teleport to (0,90). The ball then falls and crosses lane 1 sensor. It breaks when b.y < 80. Then lane 2 teleport (15,90).

Hmm, but during drop 2 (0,90): the ball falls straight down at x=0... after crossing at 86 it continues; bumper 1 at (0,76) r=3.4! Ball falls onto the bumper top → gets KICKED back up (kick 250 along normal ~ +y)! Ball flies back UP past y=86 → crosses sensor 1 again (upward) — cooldown is 0.35s: crossing up at ~0.2s later... might be within or past cooldown. If past → retrigger → 'rollover' lane 1 (else branch, lane already lit). THAT's the double trigger!! The ball bounced off the bumper back up through the lane.

Is that behavior OK for gameplay? A ball bouncing back up through a rollover lane re-triggering is actually standard pinball behavior (lanes trigger both directions). It emits rollover again with lit=true state already → else branch: 100 pts. Fine gameplay-wise. For the test, filter to count only first-per-lane or make assertion tolerant: check that lanes 0,1,2 each appear at least once and mult event fired. Let me relax: new Set(rolls) has 0,1,2.

Update the test to assert set coverage.

Progress. Orbit test presumably passed now (it's in the earlier output that got trimmed — 43 passed vs 41). Remaining failures:

1. Targets: still failing. Ball fired from (-20,48) with vx=-260. Sensor at x=-28.9 (dir negX ✓). Contact plane: wall x=-31.5 + 0.7 + 1.35 = -29.45. Sensor at -28.9 — ball center DOES reach -28.9 (before contact at -29.45). So crossing should register... unless the ball never reaches x=-28.9: it starts at (-20, 48) moving -x at 260. Wait — what's between? The sling! Left sling A(-31.5,42) B(-20,29) — at y=48: the sling triangle is y 22..42 — not at 48. OK. So ball flies from (-20,48) leftward... hits wall at -29.45, crosses sensor -28.9 → should trigger. 90 steps at DT=1/240 = 0.375s — ball travels 260*0.375 = 97 units — plenty of time to reach (needs 9). Let me debug — maybe an exception... no, tests continued. Maybe the target events fire but fireAt(48) → target 0 → y=48 within T1 span 45.6..50.4 ✓. Hmm, let me check the sensor crossing code: c0 = (px-ax)*dy - (py-ay)dx. Sensor from (-28.9,45.6) to (-28.9,50.4): dx=0, dy=4.8. c0 = (px+28.9)4.8. Ball at px=-20 → c0 = 8.94.8 > 0. Ball at -29 → c1 = -0.14.8 < 0 → crossing ✓. t = c0/(c0-c1); ix = px + (x-px)*t = -28.9 ✓ iy ≈ 48 → proj = ((ix-ax)*dx + (iy-ay)*dy)/L2 = (0 + (48-45.6)*4.8)/23.04 = 11.52/23.04 = 0.5 ∈ [0,1] ✓. dir negX: b.vx = -260 < 0 ✓. Cooldown: first hit fine.

So why no target event?! Let me check onColliderHit: it has tag 'targetWall' handling... but the sensor check is checkSensor — called at end of stepBall for each sensor. Hmm wait — the SENSOR tag is 'target'; the checkSensor handles 'target' → emits 'target'.

OH WAIT. I see it — in the test I call g.drainEvents() inside fireAt's loop — but the events fire during g.step(). That should work. Hmm, let me check step() — is checkSensor actually reached? stepBall → sensors loop ✓.

Let me look at the test again:

fireAt sets b.x=-20... BUT after the first fireAt, the ball bounced off the wall and is somewhere with residual velocity; 90 steps = 0.375s each. Between fireAt calls we don't wait for cooldown — the cooldown per sensor is 0.35s and each fireAt runs 90 steps = 0.375s — OK just barely. Hmm.

But ZERO target events fired (filter length >= 3 failed; and multiballLit failed). Let me debug directly.

2. Soak: flips=1265 now (AI flipping!) but drains=0, score=50. The AI is TOO good?? 180s without a single drain — with flipperAI catching everything... Actually more likely the ball is stuck in a loop somewhere or resting on a flipper while the AI holds it. flips=1265 over 180s. drains=0. Score 50 (one sling hit). Suspicious: maybe ball resting in the outlane pocket ON a post? Or trapped between post and guide? Let me add stuck detection to the soak debug again.

Actually, hold on — with the AI pressing flippers whenever ball y<26 & near, the ball might get caught in a perpetual cycle: bounce between flipper and... or the ball is resting ON a held flipper — the AI keeps flipping. It says flips=1265 which is ~7/s — continuous re-flipping.

Let me extend debug.mjs soak with position printing every 10s and stuck detection.

Two things:

1. Target test: the ball crosses x=-28.9 between i=7 (x=-28.66) and the wall hit... wait, at i=7 x=-28.66, then the thock (wall hit) at x=-29.41. The ball went from -28.66 to -29.41 BETWEEN steps 7 and 8 — crossing x=-28.9. But NO target event! Why? The crossing happens during the swept motion inside stepBall. The sensor check happens at the END of stepBall using b.px (step start) and b.x (step end): px=-28.66 → x after resolve+bounce: -29.26 (pushed out). So c0 for px: (-28.66+28.9)*4.8 > 0; c1 for x=-29.26: (-29.26+28.9)*4.8 < 0 → crossing detected! t = c0/(c0-c1) → ix=-28.9, iy ≈ 47.4 → proj in range ✓. dir negX: b.vx AFTER the bounce = +130 > 0 → REJECTED!

   The dir check uses the POST-collision velocity — after bouncing off the wall the ball moves +x. That's the bug. The dir check should use the crossing-direction: the sign of (c0→c1) transition, not current velocity. For 'negX' intent (ball moving toward the wall), better: check that the crossing direction corresponds to motion: use the interpolated crossing direction: sign of (c1-c0) relative to segment... The crossing direction is determined by velocity AT crossing. Simplest fix: for dir sensors, use the ball's velocity at step START (before collision): store b.vx0 at step start. Or check that c0 > c1 transition matches expected side: for a sensor guarding a wall on the left (negX = ball moving in -x = crossing from + side to - side of a vertical segment...).

   Cleanest: capture vxBefore = b.pvx where I store velocity at step start. In stepBall: b.pvx = b.vx after gravity (the velocity during this step's motion). Use that for the dir check. The initial motion direction is what carries it across.

   Edge: a slow ball rolling down could cross the sensor moving -x without hitting the wall — counts as target hit — acceptable (it's a "graze").

   Fix: in stepBall store b.pvx/b.pvy at start (post-gravity). In checkSensor use b.pvx for dir.

2. Soak stuck at (12.04, 11.61): that's near the RIGHT flipper! Right flipper pivot (11.5, 8.5), tip rest (3.36, 4.67). Ball at (12.04, 11.61) — just above the pivot! The ball is resting ON the pivot cap? The pivot at (11.5,8.5) capsule r=1.6 → ball resting on top of pivot: center at (11.5, 8.5+1.6+1.35)=(11.5,11.45) — ball at (12.04,11.61) — yes! Resting on the flipper pivot cap, slightly right. Why stuck? The AI flips when ball y<26 & x∈[2,26] & vy<40 → wantR=true → flipper pressed → swings up. Ball on pivot: flipper rotates under it; contact normal from pivot... The flipper swings: tip goes up; the pivot area doesn't move (surface velocity ∝ r from pivot ≈ small near pivot). Ball just sits on the pivot with the arm rotating beneath it; when arm returns, ball still on pivot. STUCK in a stable spot on the flipper pivot!

   Hmm — but wait, when the flipper swings up, the arm (capsule) near the pivot pushes the ball... contact at s≈0.1 of the arm: r from pivot = 0.9 → u = ω0.9 = 340.9 = 30 — small kick. The ball gets nudged but resettles on the pivot.

   Real machines: the area above the flipper pivot is covered by the slingshot/guide shape — ball can't rest there because the "flipper base" is shaped to shed balls. My fix options: a) Make the guide end LOWER/closer so balls can't sit on the pivot: guide ends (±14, 11) — the pivot top is at (±11.5, 10.1). Ball at (12, 11.6) is resting between guide end (14,11) and pivot... hmm the ball is IN the 2.5-gap I designed to bridge: gap between guide end (14,11) and pivot (11.5,8.5): distance = √(6.25+6.25)=3.5 — the ball sits ON BOTH the guide end cap and the pivot — BRIDGED! It's stuck ON the bridge it was supposed to roll over. The guide end cap (14,11,r0.7) and pivot cap (11.5,8.5,r1.6): ball touches both; the surface between them: guide cap top at ~(13.5,11.7), pivot top at (11.5,10.1): the ball bridges and the tangent points cradle it.

   Fix: make the transition smoother — extend the guide to overlap the flipper's rest arm: guide end at (±12, 9.5)? Then gap to pivot (11.5,8.5): 1.1 — sealed, but the ball rolling down the guide hits the pivot side and... rolls onto the arm (arm top surface at rest from (11.5,10.1) sloping to tip (3.36+...,4.67+1.6=6.27)... The arm IS a slide down to the tip. Ball on the arm rolls down to the tip and off — or rests ON the arm if the arm is level... rest arm slope: from pivot y 8.5 to tip 4.67 — slope -0.43 rad — ball rolls toward tip ✓. The only level spot is the pivot CAP itself (round top). A ball exactly balanced on a round cap is unstable; my friction damping makes it stable numerically.

   Better fix: give the pivot cap a CONE — physically, add a tiny invisible kicker? No. Alternative: make the flipper base shed balls by adding a small "apron" wedge over the pivot: an invisible seg from (±14, 12.5) to (±10, 9)?? that deflects balls onto the arm... Hmm.

   Actually simplest robust fix: make the GUIDE continue past the pivot as a "wall" behind the flipper: extend guide end to (±11, 10) — right at the pivot edge: then there's no gap at all: the guide end cap touches the pivot capsule. The ball rolling down the guide reaches the end at (11,10) — the flipper arm at rest occupies from pivot (11.5,8.5) — the guide end cap (11,10) r0.7 and pivot cap (11.5,8.5) r1.6: distance between centers = √(0.25+2.25)=1.58 < 0.7+1.6=2.3 — overlapping colliders (fine). A ball rolling down the guide hits the combined bump of guide-cap+pivot and rolls onto... the arm top: arm at rest from (11.5,8.5) sloping to (3.36,4.67). The bump top (pivot cap top at 10.1) — ball at guide end center height ~ (10 + ...) hmm the ball rolls over the pivot cap and onto the arm → rolls down the arm to tip. Can it rest on the pivot cap? The cap is adjacent to the guide end cap — the saddle between them could cradle... distance 1.58 apart, both round — the saddle point between them is a local low spot: ball could sit in the notch between guide end cap and pivot cap!! Ugh.

   Alternative classic solution: the inlane guide should deliver the ball ABOVE the arm such that it lands ON the arm past the pivot, and the pivot should be HIDDEN under a cover. In physics terms: make the flipper collision capsule NOT include the pivot cap — use a segment with radius but NO rounding at the pivot end... my capsule model includes caps. If I drop the pivot cap (treat flipper as a "flat-ended" segment for collision: only side + tip cap), then a ball near the pivot would fall INTO the gap between guide end and arm start?? Gap (14,11)→(11.5,8.5)=3.5 > 2.7 ball → falls through → drain. Bad.

   Hmm. What if the guide end cap is REMOVED (flat end) and the guide extends to just touch the pivot: guide from (-34,30) to (-12.9, 9.9)? Let me think about what actually sheds balls: a continuous smooth downslope from guide onto the flipper arm with no saddle. The flipper arm at rest: from pivot (11.5,8.5) down to tip (3.36,4.67) — slope angle -25.4°. The guide from (26.5,28) to (14,11) slope: rise (11-28)/(14-26.5) = -17/-12.5 → angle -53.6°. If the guide extends to MEET the arm's top edge smoothly: guide end should touch the arm's upper edge line. Arm upper edge: line from pivot+(normal*r) ... this is getting fiddly.

   Practical approach used in pinball sim code: place a small circular "flipper base" collider at the pivot with a radius LARGER than the flipper capsule, and shape the guide to end right at it; the ball rolls over the big round base onto the arm. The saddle issue remains theoretically but with a big base circle the saddle is shallow and slopes toward the arm.

   OR — cheat differently: detect a ball resting nearly-still on/near a flipper pivot for > 2s and give it a tiny random kick. That's a hack but pragmatic... "ball unstuck assist". Real games do worse hacks. But it could fire visibly.

   Cleanest geometric fix: eliminate the pocket entirely by making the flipper BASE touch the wall/guide so there's no saddle, and make the arm's rest angle such that the arm top surface continues the guide slope. Actually — what about making the pivot cap collider SMALLER (r=0.9 vs arm 1.6)? A tapered flipper: thin base, fat tip? Then near-pivot surface is lower: ball at the base region... still a saddle.

   Rethink: WHY does the ball stop? Static equilibrium requires the contact normals to bracket gravity. On a single convex surface that's impossible without friction (my friction is velocity-damping, can't hold statics). The saddle between two round caps CAN bracket gravity: normal from guide cap points up-left-ish, from pivot cap up-right-ish → stable trap. So the fix MUST remove the saddle: make the transition monotonic.

   Monotonic path idea: extend the guide so its end cap is BELOW the pivot cap top, making the ball roll from guide onto the pivot cap then onto the arm — always descending: pivot cap top at (11.5, 10.1). Guide end at (13.2, 10.4)? Guide cap r 0.7 → top at 11.1... The ball rolling off the guide end falls onto the pivot cap's LEFT slope (x<11.5) and rolls down-left onto the arm. The saddle between guide cap and pivot cap: guide end (13.2,10.4), pivot (11.5,8.5): center distance √(2.89+3.61)=2.55 > 2.3 (r sum) — small gap 0.25 — tiny saddle but the ball (r 1.35) can't sit in a 0.25 notch. Hmm, actually the notch between two circles 2.55 apart with radii 0.7/1.6: the ball touches both — the contact normals: from guide cap: direction from (13.2,10.4) to ball; from pivot: from (11.5,8.5). The ball sits above both: normals point up-right (from guide cap, since ball is up-left of guide cap? no ball is BETWEEN them)...

   You know what, let me just try: move guide ends to (±13.0, 10.2) and see if the soak still gets stuck. Actually the CURRENT guide end is (14,11) with gap 3.5 to pivot. The ball bridged at (12.04,11.61) — touching guide end cap AND pivot cap. If I move the guide end closer (13.0,10.2): gap to pivot = √(2.25+2.89)=2.27 ≈ r sum 2.3 — tangent — no notch, the two caps merge into one continuous bump. Ball rolls over the bump onto the arm. I think that works. The outlane pocket: ball needs to get past x>13 below the guide — the pocket x∈[13,26.5]: any ball there drains (nothing below). The gap between guide end (13,10.2) and pivot bump — sealed by tangency. ✓

   Left mirror: guide end (-13, 10.2), pivot (-11.5,8.5).

   Hmm, but tangency is knife-edge; float jitter might open a 0.1 notch — negligible for a 2.7 ball.

   Also — while I'm at it, check the flipper arm rest vs ball resting ON the arm near pivot: arm top edge from (11.5, 10.1) sloping to tip (3.36, 6.27): slope -0.425 rad — ball rolls down ✓.

   And when flipper is HELD up: arm from (11.5,8.5) to tip at angle +0.52: tip = (11.5-9cos0.52, 8.5+9sin0.52) = (3.7, 12.97). Ball on the raised arm rolls toward the PIVOT (slope up toward tip) → collects at pivot bump → gap between raised arm base and guide end (13,10.2): the arm at +0.52 rad near pivot... the ball rolls down to the pivot and sits against the pivot cap, held by the raised arm slope. When the flipper releases, ball rolls down the arm. Momentary rest against pivot while held — acceptable (real pinball: ball cradled at flipper base — that's a FEATURE: "cradle"). When held, ball rests between arm and pivot bump — fine, it's on the flipper, player controls release.

   OK let me also double-check the LEFT side doesn't have the same trap at the lane wall / right guide... right guide end (13,10.2) same. Left guide end (-13,10.2).

3. Soak score 5850 — great, the game plays. Once unstuck, drains will happen.

Let me apply: guide ends → (±13, 10.2); sensor dir fix (use step-start velocity).

****************************************************************************************************************************************************************************le.

48/50. Targets all pass now. But soak still: flips=1265, drains=0, score=50 — ball still getting stuck somewhere (score 50 = one sling hit, then stuck; AI keeps flipping). My debug soak used power 0.85 and scored 5850 with a stuck at (12.04, 11.61)... wait that was BEFORE the guide fix. Let me re-run the debug soak to find the current stuck position.

Target event fires now ✓. But still stuck at (11.64, 11.83) — on the right flipper pivot area AGAIN. Ball at (11.64, 11.83): pivot at (11.5, 8.5). Distance = √(0.02 + 11.1) = 3.34 ≈ 1.6+1.35=2.95 + 0.4 slack. So the ball is above the pivot, resting between... the guide end (13,10.2) cap r0.7 and the pivot cap? The saddle persists! Distance guide end to pivot: √((13-11.5)² + (10.2-8.5)²) = √(2.25+2.89) = 2.27 < r sum (0.7+1.6=2.3) — overlapping caps, good, but the SADDLE above them: the ball (r 1.35) rests touching both circles; contact points: the ball sits in the V above the two caps. The notch: two circles r0.7 and r1.6 with centers 2.27 apart — the outer "valley" above them: circle tops at (13,10.9) and (11.5,10.1): the valley between them is at the intersection point of the two circles... circles overlap (2.27 < 2.3) so there's NO valley — one circle's top is higher. Guide cap top: (13, 10.9); pivot cap top: (11.5, 10.1). The ball rolls from the guide (higher) onto the pivot cap — descending — then onto the arm. Should shed!

But the ball is at (11.64, 11.83) — that's ABOVE the pivot cap top (10.1) by 1.7 — the ball is NOT touching the pivot cap (distance 3.34 > 2.95). What else is it touching? The guide end cap (13,10.2): distance from ball = √(1.36² + 1.63²)=2.12 ≈ 0.7+1.35=2.05 ✓ touching the guide end cap. And what else holds it? Maybe the flipper ARM when HELD UP: the AI holds the flipper (wantR true when ball y<26): arm raised to +0.52 rad: arm from (11.5,8.5) direction (-cos0.52, +sin0.52)=(-0.868, 0.497): points on arm: (11.5-0.868s, 8.5+0.497s). Distance from ball (11.64,11.83) to arm line: the arm direction u=(-0.868,0.497); w = ball - pivot = (0.14, 3.33); proj s = w·u = -0.12+1.65=1.53; closest point = pivot + 1.53u = (10.17, 9.26); distance = |w - 1.53u| = |(0.14+1.33, 3.33-0.76)| = |(1.47, 2.57)| = 2.96 ≈ 2.95 ✓ — the ball is ALSO touching the RAISED ARM. So: ball wedged between guide end cap (above-right) and raised flipper arm (below-left) — the AI holds the flipper up FOREVER (wantR stays true because ball y=11.8 < 26), and the ball is cradled against the guide end cap — the cradle trap: arm slope pushes ball up-left into the cap, cap pushes down-right, gravity... equilibrium with the arm's normal force. Because the AI never releases, the ball stays cradled. A real player would release and the ball rolls down the arm. But it CAN also happen that a cradled ball gets stuck if there's a lip... Actually this is the classic "flipper cradle" — legitimate! The trap is only that the AI is dumb. A human holds the cradle intentionally. If released, ball rolls down the arm to the tip.

But wait — is it a TRUE stable cradle, or can the ball never escape? On release, arm swings down to -0.44; ball on arm near pivot rolls down toward tip... at rest the ball would be at the pivot side of the arm... it rolls down-left to the tip and drops. Fine.

So the physics is correct; my soak AI is just too dumb (holds the flipper forever). Real games have this exact behavior. Improve the AI: pulse flippers (hold 0.14s then release) — the original test.mjs soak used flipHold pulses (0.14s) — and it ALSO got stuck with flips=1265... 1265 flips over 180s = 7/s — the AI re-flips constantly and the ball re-cradles. Hmm, with 0.14s pulses the cradle releases each time... but the ball, when released from cradle, rolls down the arm — the AI flips again when ball y<26 → re-cradles. The ball oscillates cradle→arm→cradle forever? Between cradle and arm the ball stays in the flipper zone forever because the AI always catches it. Real players catch and aim too... but eventually they shoot the ball UP. The flipper pulse 0.14s: the flipper swings up (34 rad/s * 0.14s = 4.8 rad — full swing in 0.014s actually (0.96 rad / 34 = 0.028s)). The flip stays up for the remaining 0.11s then releases. If the ball is ON the arm when flipped, it gets launched UP (maxVy 368 in the flipper test!). So the AI should be launching the ball... unless the ball is cradled ABOVE the pivot (not on the arm) — flipping doesn't hit it (the contact at the guide cap holds it, the arm sweeps below).

The ball at (11.64,11.83) cradled between guide cap and arm — when the flipper RELEASES, the arm rotates down away from the ball — the ball then rests only on the guide cap — rolls off (cap is round, e high) — falls onto... the arm/pivot → rolls down. Then AI flips again (ball y<26, vy<40) → the swinging arm hits the falling ball → sometimes launches it, sometimes re-cradles.

Why did the test soak never drain OR score? Score 50 in 180s means the ball essentially never left the lower zone. The cradle loop traps it.

Hmm — is the cradle TOO sticky? The ball cradled between guide end cap and raised arm: on release, does it ALWAYS re-cradle rather than escape? The escape requires the ball to roll down the arm past the tip OR the flip to launch it. The flip launches balls ON the arm; the cradled ball is above the pivot though...

Let me reconsider: is this cradle geometry a design flaw? The guide end cap at (13,10.2) creates an overhang when the flipper is raised: the raised arm + guide cap form a pocket. On real tables, the inlane guide is BEHIND/ABOVE the flipper such that a raised flipper + guide never form a pocket — the guide end typically aligns with the flipper's REST position, and when raised, the gap between guide end and arm base OPENS (ball can drop to the arm).

In my geometry: guide end (13, 10.2). Pivot (11.5, 8.5). Raised arm base area: the arm near pivot (s=0..2): points (11.5..9.8, 8.5..9.5). The ball cradled at (11.64,11.83): it's resting against the guide cap — the pocket is: guide cap (top-right), arm (bottom-left), and... when the arm is raised, the region between pivot top and guide cap bottom...

Alternative: lower the guide ends so they're BELOW the pivot cap top: guide end at (13.5, 9.0)? Then guide cap top at 9.7 < pivot cap top 10.1. The guide→pivot transition: descending ✓. When the flipper rises, the arm sweeps up next to the pivot cap; a ball on the arm near the pivot gets pushed up against... the pivot cap is round — the ball rides over it back onto the guide or onto the arm — no overhang pocket because the guide cap no longer looms above the raised arm. Let me compute: raised arm at s=1.5: (10.2, 9.25); guide cap at (13.5, 9.0) r0.7: far (2.9 away). The raised arm region near pivot top: the ball cradling would be against the pivot cap itself — round cap — sheds.

But does lowering the guide end create a gap at the outlane? Guide from (26.5,28) to (13.5,9.0): at x=17.5 (outlane post): y = 28+(17.5-26.5)*(19/13)= 28-13.2=14.8. Post at (17.5,19.5) — 4.7 above guide ✓. Guide end (13.5,9.0) to pivot (11.5,8.5): gap 2.06 < 2.3 r-sum → overlapping caps ✓ no saddle (both round, pivot cap HIGHER → monotonic descent from guide onto pivot).

Wait, but is the pivot cap top (10.1) higher than the guide surface near the end? Guide line at x=11.5 (extended): y = 28 + (11.5-26.5)*(19/13) = 28-21.9=6.1 — the guide line descends below the pivot. The guide END cap at (13.5,9.0) top at 9.7 vs pivot top 10.1: ball rolls from guide cap (9.7) DOWN?? to pivot cap (10.1) — that's UP by 0.4! A tiny lip. Hmm — ball rolling down the guide hits the pivot cap's upper-right slope and needs to climb 0.4 — with rolling speed fine, but a slow ball could stall between the guide cap top and pivot cap... the two caps overlap (2.06 < 2.3) so no saddle — the ball touching both: normals from (13.5,9.0) and (11.5,8.5) — ball above both... overlapping circles → the union is convex-ish → sheds.

Honestly, iterating blind geometry is slow. Better tool: make the flipper collision shape TEARDROP — radius tapers from r=1.6 at pivot to 1.6 at tip... no.

Step back. The pragmatic, robust solution used by actual pinball video games: THE CRADLE IS FINE; the stuck case is an AI artifact. But a stuck ball for a HUMAN is also possible if they hold the flipper up and the ball nestles against the guide end. On real machines that's a valid cradle (holds ball, release to continue). It's part of pinball skill. The "bug" would only be a PERMANENT trap with no user input. With flippers released (neutral state), does the ball always shed? Test: place ball at (11.64,11.83) v=0, flippers NOT pressed, step 3s → assert ball leaves the region (drains or rolls onto arm).

Let me test that with the current geometry (guide end (13,10.2)):

• Ball placed at (11.64,11.83) falls: contacts guide cap (13,10.2) at distance ~2.05 → normal from cap to ball ≈ ((11.64-13)/2.12, (11.83-10.2)/2.12) = (-0.64, 0.77) — up-LEFT → the cap pushes the ball up-left → ball rolls off LEFT toward the pivot top (11.5,10.1) → onto the arm → down to tip. Should shed!

But in the soak the flipper was RAISED (AI holds it) — the raised arm created the pocket. With pulsing flippers (0.14s), during the 0.1s release windows the ball should have escaped... unless the AI re-flips too fast (every ~0.14s). In test.mjs soak: flipHold timer 0.14s; wantL/wantR recomputed each step — as long as ball y<26 & vy<40 & x range → immediately re-flip after hold expires. So release windows are ~1 step long (1/240s) — the ball never escapes. That's a pathological AI, not a physics bug.

Decision:

1. Verify the neutral-release shed behavior with a test (ball placed in cradle position, flippers down, must escape within 3s).
2. Make the soak AI slightly smarter: don't flip if ball is nearly still above the pivot (|v|<15) — i.e., only flip when ball is approaching (vy < -30) or moving. This models human play.

Also add a safety net: a genuinely stuck ball (no flipper input + |v| < 5 for > 4s while in play) gets a gentle random nudge ("ball search" — REAL pinball machines do exactly this!). That's authentic: pinball machines run "ball search" when they lose track of the ball. I'll add ballSearch to the game: if in play, all balls |v|<8, no flipper pressed, for 3.5s → apply random impulse + emit 'search'. This guarantees no permanent stall ever.

Let me implement:

• In Game.step: track stillTime: if state==='play' and all balls slow (<8) and no flipper pressed → stillTime += dt else 0. If stillTime > 3.5 → for each slow ball: impulse direction up-random: vx += (Math.random()-0.5)*120, vy += 100+Math.random()*80... hmm random — for test determinism use a pseudo-random based on time: fine (Math.random is OK for gameplay; tests shouldn't depend on it).
• emit('search').

But careful: ball cradled on a HELD flipper → flipper pressed → stillTime resets ✓ (intentional cradle not disturbed).

Test soak AI: flip only when vy < -20 (approaching) — cradled/still balls don't trigger flips. With ball-search safety, any true stall resolves.

Let me apply: core gains ball-search; test soak AI condition tightened; add "cradle sheds when flippers neutral" test.

Wait — there's an ordering issue: the ball search is checked AFTER drain handling but the weak-plunge recovery after that — fine. But the ball-search block references this.state === 'play' — good. However a subtle issue: a ball rolling slowly on the playfield (|v|<8) e.g. slowly rolling down a guide could trigger... it needs 3.5s of ALL balls slow AND no flipper pressed — a slowly rolling ball will accelerate (gravity) so |v| grows — safe.

Now update the soak AI in test.mjs: only flip when ball approaching (vy < -20). And add a cradle-shed test. Let me update the soak section.

I'm at 80% of the time budget! I need to move fast. Remaining work: finish tests, build the full index.html (the big file — 1300+ lines), deploy, update index. The index.html is the biggest remaining chunk. Let me run the tests right now, then write the HTML in one shot (I can reuse battle-tested patterns from prior demos). If time is tight, I may need to trim some rendering extras but keep it impressive.

Let me run tests now.

ALL 51 TESTS PASS! The physics core is solid:

• Swept CCD collisions, settling, no tunneling
• Full launch → orbit works (maxY > 122)
• Weak plunge re-serve
• Bumper kicks, flipper energy
• Rollovers → multiplier
• Targets → multiball (3 balls)
• Ball save, game over, tilt
• Cradle sheds
• 3-minute soak: no NaN, in bounds, scoring, drains

Now the big task: index.html with the full renderer. I must move FAST. I'll write it in one big write. Let me structure it:

1. HTML/CSS HUD (title, score, message, hint, charge bar, buttons)
2. Import map + module script:
   • Paste the core physics INLINE (adapted: remove export keywords, keep everything)
   • Three.js scene: table geometry from buildTable data, playfield with canvas texture, neon rails, bumpers, flippers, plunger, backbox DMD, ball + trails
   • Post-processing: bloom + grade
   • Audio engine: BGM sequencer + SFX
   • Input: keyboard + touch
   • Game loop: fixed-step physics, event → visual/audio reactions
   • Snapshot, adaptive quality

To save time, I'll inline the core by copying core.mjs content and stripping export keywords. Let me generate index.html programmatically: write the HTML template with a placeholder, then inject core.mjs content via a shell script. That guarantees the tested code is exactly what ships.

Let me write the template now. Key rendering decisions (fast but good):

• Coordinate map: world (x, y_height, z) = (px, 0, 96 - py). Ball at height = ballR + playfield thickness.

• Playfield: ShapeGeometry outline (rect from -34..34, y 0..96 + arc r34) — map UVs from physics coords to canvas texture 1024x2048 (covers x -34..34 → u, y 0..130 → v... arc top at y=130). Shape: moveTo(-34, 0) lineTo(34, 0) lineTo(34, 96) absarc(0, 96, 34, 0, π, false) lineTo(-34, 0). In shape coords use (x, y) then rotate geometry -90° around X so shape y becomes -z... ShapeGeometry lies in XY plane; rotateX(-PI/2) maps (x, y, 0) → (x, 0, y)? rotateX(-90°): (x,y,z) → (x, y cos(-90) - z sin(-90), y sin(-90) + z cos(-90)) = (x, z, -y). So shape (x,y,0) → (x, 0, -y). Physics y → world z = -y. So world z = -y means physics y=96 → z=-96... but I wanted z = 96-y (shift). Just position the mesh at z offset +96? mesh.position.z = 96... wait the mesh local z = -y; to get world z = 96 - y: mesh.position.z = 96. Hmm: world z = local z + 96 = -y + 96 ✓. Then drain (y=0) at z=96 (near camera), top arc (y=130) at z=-34 ✓.

  UVs: for each vertex (x, y) in shape space: u = (x + 36)/72, v = y/132. Canvas 720x1320? Use 1024x2048 canvas with mapping u∈[0,1]→x∈[-36,36], v∈[0,1]→y∈[0,132]. Draw playfield art accordingly.

• Walls/rails: for segs create boxes: length L, width 2r+0.6, height 4.5; position mid, rotation.y = -atan2(dy?) — in world: seg from (ax,ay)→(bx,by) maps to (ax, h/2, 96-ay)→(bx, h/2, 96-by): rotation around Y = atan2(-(by-ay), bx-ax)... let me define: dir2 = (bx-ax, by-ay); world dir = (dir2.x, 0, -dir2.y); yaw = atan2(-(-dir2.y)?? Use mesh.lookAt or set rotation.y = Math.atan2(dirWorld.z, dirWorld.x)... rotation.y = -atan2(dirWorld.z, dirWorld.x)? For a box aligned +x, yaw θ maps +x → (cosθ, 0, -sinθ). We want +x → normalize(dirWorld) = (dx, 0, dz)n. So cosθ = dx, -sinθ = dz → θ = atan2(-dz, dx). ✓ Plus an emissive neon strip on top: thin box (L, 0.35, 0.35) at height 4.6 with emissive color by position (hue from physics y) — MeshBasicMaterial for bloom pickup.

• Bumpers: group per bumper: base cylinder, body, emissive ring torus, skirt; flash variable.

• Posts: cylinder + emissive tip sphere.

• Flippers: CapsuleGeometry(1.6, len - ... ) hmm capsule length is the cylindrical mid-section: CapsuleGeometry(radius, length) where total = length + 2r. For arm len 9 with caps: length = 9 - 2*1.6 = 5.8, radius 1.6, but pivot end is round too — visually fine. Position: capsule axis along +x centered at midpoint pivot→tip; mesh.position = midpoint (in world), rotation.y from angle: arm dir (cos a, sin a) → world (cos a, 0, -sin a); yaw = atan2(sin a... using formula θ = atan2(-dz, dx) = atan2(sin a, cos a) = a. So rotation.y = flipper.angle... wait world dz = -sin a → θ = atan2(-(-sin a), cos a) = atan2(sin a, cos a) = a. rotation.y = a ✓.

• Plunger: cylinder rod at lane bottom x=30.25 world (30.25, 1.2, 96-2) + knob; compresses with charge power (scale z / position offset).

• Backbox: box at far end z=-38-ish, standing up: width 80, height 46, depth 6, positioned y=23, z=-40; front face plane with DMD canvas texture emissive.

• DMD: canvas 128x32, dot-matrix: draw text with 5x7 font as filled circles. I'll implement a tiny dotText function with a compact font map for A-Z 0-9 and few symbols. That's ~60 glyphs... time-consuming. Alternative: draw text normally with monospace font then render "dots" by sampling? Simpler: draw text with small canvas font "8px monospace" onto offscreen, then sample pixels and draw dots. That's easy: write text on 128x32 canvas with fillText, then draw dot grid where alpha>128. Do at low res: text canvas 128x32, getImageData, dots radius 0.8 spacing 2. Fine and fast (only on change).

• Ball: sphere r1.35 chrome + slight emissive; trail: store last 20 positions per ball, render as additive ribbon (quad strip facing camera). Implement TrailRibbon class: positions ring buffer; each frame rebuild BufferGeometry with 2 verts per point, alpha fade; shader material additive, color cyan-white.

• Flashers: 4 PointLights pool, intensity decay; triggered at event world pos.

• Camera shake: trauma += on events; offset = noise * trauma².

• Score popups: small floating text sprites? Skip — DMD + HUD enough. Actually cheap win: HTML div popups positioned via projection — skip for time. The DMD messages cover feedback.

• HUD: SCORE (big mono), BALL, MULT; message line; charge bar shows plunger power during serve; tilt warning.

• Attract mode: camera slowly orbits/pans; DMD shows "NEON TILT / PRESS SPACE".

• Audio: music sequencer: 112 BPM, Am–F–C–G pad + bass arp 16ths + kick 4-floor + hats offbeat + occasional lead. SFX: flipper click, bumper pop (pentatonic), sling blip, rollover ping, target clack, spinner ticks, launch sweep, drain descend, save jingle, multiball siren, tilt buzzer, skill fanfare, thock, search solenoid thunk, gameover tune.

• Adaptive quality: monitor EMA frame time; tiers adjust pixelRatio & bloom & shadow.

• Snapshot: press C or button → composer.render → toDataURL → download.

Time check: ~19% left of the hour (≈9-10 min?). Hmm "timeProgress 0.8025" of maxTime... I need to be economical. Writing a 1400-line HTML in one shot is risky but doable. Let me be smart: I'll keep rendering rich but trim where safe (no glass sheet, no popup sprites, simple legs, compact audio).

Actually — to manage risk, I'll write the HTML template in 2-3 file writes (head+css+hud, then JS part 1, JS part 2), then inject core via shell sed, then node --check the extracted module.

Let me go. Template with placeholder /*__CORE__*/.

Plan the JS structure:

Details on mapping: W = (x, z) = (x, 96 - y). I'll write helper wx(x) = x, wz(y) = 96 - y.

Camera: PerspectiveCamera(fov=42); pos (0, 128, 150)?? Table spans z from +96 (near/drain) to -34 (far/top), x -34..34. Distance: want whole table visible: vertical extent 130; camera at (0, 150, 120) looking at (0,0,28): direction... let me estimate: camera height 150, z 120; lookAt (0, 0, 25). The table far edge z=-34: dz=154, dy=150. fov 42 vertical; half-extent needed: from look target, far edge offset (-159 z, -150 y) along view... I'll just tune: camera.position.set(0, 145, 125), lookAt(0,0,20). Add slight ball-follow: target x += ball.x*0.06, z toward ball... subtle.

Attract: camera slowly pans: azimuth oscillation ±4°, height bob.

Flipper visuals: group with capsule + emissive stripe (thin box on top? skip).

Playfield texture: canvas 1024x2048:

• fill dark #05070f gradient to #0a0d1a
• neon grid lines faint cyan
• lane chevrons at rollovers
• big "NEON TILT" text diagonal magenta/cyan glow
• circles around bumpers
• arrow at plunger lane
• apron art: stripes + "BALL SAVE" text? minor Compute px = (x+36)/72*1024, py = 2048 - (y/132)*2048 (canvas y down). Wait v mapping: v = y/132 → texture v=1 at top y=132. Canvas row 0 = top = v=1 → canvasY = (1 - y/132)*2048.

Draw lane lines: plunger lane x=26.5..34 line; rollover lane dividers between posts; target markers.

Bumpers visual positions known.

Alright — audio engine (compact):

Event → reactions mapping in loop:

• bumper: flash bumper i, flasher light, pop sfx, shake 0.15
• sling: sling flash, blip, shake 0.1
• rollover: lane light update, ping
• target: target flash, clack
• multiballLit: DMD msg + siren short
• multiball: DMD "MULTIBALL!", siren, shake 0.5, spawn visual balls handled by game.balls diff
• drain: sfx descend, shake 0.3, DMD msg
• save: jingle + "BALL SAVED"
• skill: fanfare + "SKILL SHOT 5000"
• mult: "MULTIPLIER ×n"
• tilt: buzzer + "TILT" + flippers visually droop (game handles)
• nudge: thud + shake 0.25 (+ "DANGER" if warn)
• launch: sweep whoosh
• serve: DMD "BALL n"
• gameover: tune + DMD "GAME OVER"
• thock: wood thunk (only hard)
• clack: ball-ball click
• search: solenoid thunk
• spinner: tick ticks while spinnerSpin>0 (rate ∝ spin)
• reserve: soft spring + DMD "SHOOT AGAIN"

Ball meshes: map ball.id → mesh + trail; create/remove as balls change.

Score HUD: update each frame (displayScore for ticking). DMD: update on events + score change (throttle 10Hz).

OK — one important piece: the loop fixed-step: accumulator with dt=1/240, max 8 steps per frame (slow-mo? no). Render interpolation: skip (240Hz is plenty smooth; render latest state).

Pause on blur (P key + visibilitychange).

Touch controls: left half → left flipper, right half → right flipper (pointerdown/up on zones); plunger: bottom center button during serve (touchstart charge, touchend release). Nudge buttons? skip on touch.

Mute M; snapshot C; restart R.

Prevent default on Space (scroll) and arrows.

Write it. To be safe with time I'll write the whole thing in ONE write call with the /CORE/ placeholder, then inject, then check. Keep code tight but complete. Let me go — this will be a large file (~1000 lines). Focus.

Some size-saving choices: DMD dot-matrix via pixel sampling (short code). Canvas art ~80 lines. Audio ~130 lines.

One thing about bloom threshold: emissive neon strips MeshBasicMaterial with color > 1? Use emissiveIntensity via MeshBasicMaterial can't exceed 1... Use MeshBasicMaterial with color set and rely on bloom threshold 0.5 — colors at 1.0 pass. For brighter, use new THREE.Color(2.5, 1.2, 0.8) — values >1 allowed in Color → HDR-ish with UnrealBloom ✓ (renderer.toneMapping = ACESFilmic; bloom works on linear buffer).

Fog: subtle exp2 for depth.

Floor: big dark plane with radial gradient texture below the table; cabinet box around playfield edges (4 boxes). Legs skip; floating cabinet + glow.

Let me write it now.

There's a bug I noticed: 'm' is bound both to right flipper AND mute. I noted it in a comment but the code still has both: keydown 'm' → pressFlipper(1, true) AND k === 'm' || k === 'M' → toggleMute. Conflict! Let me remove 'm' from the flipper binding (keep '/' and ArrowRight and Shift for right flipper; left: 'z', ArrowLeft). Wait — I have Shift for left flipper only... 'Shift' should trigger BOTH flippers (classic). Let me fix the key mapping:

• Left flipper: ArrowLeft, z, Z
• Right flipper: ArrowRight, /, .
• Both: Shift (track which shift? just both)
• Plunger: Space, ArrowDown
• Nudge: A/D/W
• Mute: m/M only
• Snapshot: c
• Restart: r

Let me fix that section. Also in keyup.

Also another bug: in the keydown handler, game.startCharge() on Space — during 'play' state startCharge does nothing (state !== 'serve') ✓.

Another issue: game._spinnerMesh — fine.

Rollover event: e.x is undefined — I emit rollover with {lane, lit, skill} — no x/y. flash(e.x ?? 0, 86, ...) — ok.

Fix the Shift handling: track leftShift/rightShift via e.code: 'ShiftLeft'/'ShiftRight'. Simpler: on any Shift keydown → press both flippers; keyup → release both. But e.key === 'Shift' for both. Fine: both flippers on Shift.

Let me rewrite the input section.