Robot Repair Rush

Robot Repair Rush

ARTIST'S STATEMENT

Shashank Sharma Northeastern University | Class of 2029 Computer Science Major | Robotics Minor

Robot Repair Rush is a one-screen arcade game about keeping a factory alive while its machines fail for increasingly ridiculous reasons. The player drives a small maintenance robot toward broken machines and remains nearby long enough to repair them. Each active failure decreases the factory's health, so the player has to prioritize problems and survive a sixty-second shift. Underneath that simple loop, the game is about how quickly small technical problems can accumulate inside a larger system.

I chose a maintenance robot because I am studying computer science with a minor in robotics. I am interested in the gap between telling a machine what to do and getting reliable behavior from it in the real world. Software and hardware can be carefully designed and still fail because of timing, incomplete information, or an unexpected/unanticipated interaction. The game's silly failure messages, including "Needs emotional support" and "Forgot how to machine," make that frustration rather playful instead of treating the factory as a serious simulation.

I kept repairs proximity-based instead of adding a separate repair button or minigame. Movement, route planning, and deciding which machine matters most are the meaningful actions, so another control would have added complexity without adding a better decision. I also chose one visible factory room rather than multiple rooms. Keeping every machine on screen makes failures readable and lets the pressure come from prioritization instead of navigation. Finally, the fixed sixty-second round creates a clear difficulty curve: the early seconds teach the loop, while faster breakdowns make the final stretch frantic.

The collaboration with Claude Code was most useful when it turned broad visual requirements into specific presentation details. It created a label-placement system that puts each failure message above, below, or inward from its machine so the joke stays readable without leaving the canvas. That was more polished than my original request. I also had to overrule part of Claude's first implementation. It used a capped frame delta for every timer, which could stretch a "sixty-second" round on a slow display. I requested a second iteration that separated wall-clock gameplay timing from capped movement timing and

automatically paused when the tab became hidden.

I did not manually write most of the HTML or JavaScript, but I still think the game reflects my authorship. I supplied the central concept, the repair loop, the robotics theme, and the humorous tone. My role was to define the experience, test whether the generated implementation matched it, identify a timing flaw, and decide which changes belonged in the finished game. The code came from AI, while the purpose,

constraints, evaluation, and final acceptance came from my direction.

Robot Repair Rush | Shashank Sharma

Page 1

Development Prompts

"Create a polished, playable single-file browser arcade game named Robot Repair Rush."

"Machines around the room randomly break for silly reasons. The player must drive next to broken machines and remain nearby briefly to repair them."

"Fix frame-rate-dependent timing. Separate wall-clock gameplay time from movement and visual simulation time."

AI Disclosure

I used Anthropic Claude Code. I helped organize the project, refine the design specification, run browser and logic tests, identify defects, and prepare the statement. Claude Code generated the initial single-file HTML game and revised it after testing. I completed two different development rounds: the initial build and one focused correction round. I corrected the frame-rate-dependent timer and requested improvements to audio recovery, screen-reader status, and health-bar contrast. I rejected the initial all-purpose capped-delta timing approach rather than leaving the first generated version unchanged.

Page 2