← Rocket CabBuilding with Astra · Eric HubbardPublished September 27, 2026
Case study / Game development

Building Rocket Cab.

A browser pinball game built around a simple test: does the table play as convincingly as it looks?

The brief

One cabinet. Three balls. A rocket to launch.

The work

Refine collisions, controls and feedback through playtesting.

The result

A playable game—and a physics engine that agents can use, too.

Rocket Cab cabinet with ARM, IGN and REL targets above the rocket and two lower paddles
The playable cabinet. Complete ARM, IGN and REL to advance the rocket one stage.

Three targets. Four launch stages.

Rocket Cab started with a focused brief: one playable pinball table, with physics taking priority over appearance. The cabinet would be black, white and red, with a mechanical rocket rising on a steel post. A successful shot needed to feel as clear as the visual design.

  1. 01 · Ignition25,000
  2. 02 · Ascent50,000
  3. 03 · MECO100,000
  4. 04 · Liftoff250,000

Each completed target bank advances the sequence; after full liftoff, it repeats. Three balls and no game clock make keeping the ball in play important. Ramps, bumpers and return paths create opportunities to reach the targets again.

Play Rocket Cab ↗

Make the visible shot a playable shot.

The most useful feedback was specific: a ball hit an invisible obstruction near the TRANSFER entrance, or a sling kicked it from the wrong side. Those reports led back to collision geometry, targeted repairs and regression checks.

The objective was consistent contact, while preserving the table’s difficulty. Playtesting also exposed issues around ramp transitions, return-wire clearance and the gap between paddles. A convincing cabinet depended on these less visible details.

Controls needed the same attention. A phone must accept simultaneous paddle touches without browser gestures taking over; desktop inputs must release correctly when focus changes. Nudge feedback gained a visible cabinet movement and a mechanical sound because its effect was otherwise easy to miss.

Build, play, describe, verify.

Working with Astra was an iterative collaboration. I played the builds, described unexpected behavior and used screenshots to identify interface problems. Astra helped turn those observations into changes and checks. The useful unit of progress was a specific behavior we could try again.

Some revisions removed features. Modes were simplified, distracting effects were reduced, and a plunger change was reversed once a friendly score competition was underway. Preserving the conditions of play mattered more than adding another option.

Progression added planetary ball finishes, unlocks and saved collections. Every finish uses the same physics. The public leaderboard is separate from local progress and automated agent runs; training agents never submit scores.

A second use for the same engine.

Separating physics from rendering made it possible to run the game without drawing the cabinet. Agents could receive numerical game state, act in parallel and produce recordings that replay through the original engine.

That opened a different question: would rewards for scoring teach sustained pinball play, or something narrower? The next case study follows the training experiments and the behavior they revealed.

Development details & sources

The game includes a charged plunger, paddle catches, a pre-flip skill shot and nudging. Four nudges within three seconds trigger a hard abort and lose the ball. Ball finishes change presentation, not collision behavior.

Verification combined physics regression checks with browser checks of controls, layout and saved progress. Timing work addressed slow frames dropping simulation time; mobile work reduced rendering load while retaining game behavior.

Sources: the original Rocket Cab brief, the development conversation “Build playable Rocket Cab pinball,” repository history and the game guide. The cabinet image was captured locally on September 26, 2026. Private conversation transcripts are not included.