Case study
GTA RP Minigame Recreation
The button-mash ATM robbery from NoPixel, rebuilt from Twitch clips
Without real numbers from NoPixel, you can't make a perfect copy. So I measured it from streamer clips, tested it on my own hands, and let the community fill in the rest.
- 626 runs from 249 players overnight
- 4 hours from start to launch
Overview
I enjoy a very niche form of entertainment: GTA RP on NoPixel 5.0, a custom Grand Theft Auto V server where people role-play as characters and most of them livestream it. The server is full of little minigames and puzzles, called hacks. One of them is a plain button masher, and it's more interesting than it sounds — I watched a streamer named Blau fail it and wanted to try it myself. NoPixel 5.0 isn't open to most people, so I spent a few hours with Claude recreating the hack as closely as we could, put it on itch.io, and posted it to the NoPixel subreddit for the community to play.
The problem
I have no numbers from the people who built the original. No press value, no push-back rate, no checkpoint thresholds. Everything I could learn about how the hack behaves had to come from watching other people play it on stream, which is a recording of the output, not the rules that produced it.
Building a button masher takes an afternoon. But how do we make it feel like the real game?
Role
A solo project built over about a day. I broke down the hack's mechanics from streamer clips, worked with Claude to measure and calibrate the difficulty, and set up a way to keep tuning it with data from the community. The split that made it work: Claude did the frame-by-frame analysis and wrote the code, and I brought the things it couldn't — knowing the game, knowing when a result looked wrong, and being the test subject.
Approach
Design
The UI stays close to the real one, which was less work than it sounds: NoPixel's font is Barlow, a Google Font, and the hack itself is a ring, a key cap, and three checkpoint dashes. Getting those proportions right matters more than any effect — it's the thing people recognise from stream.
After each run, the game compares it to the streamer runs we studied.
Engineering
Watched the ring
I pulled clips of seven attempts — five clears and two fails — and had Claude track how full the ring was in every frame. The pattern came out clearly. Each press adds a small chunk, the ring slides back constantly, and the slide-back gets stronger both as the ring fills and with each checkpoint passed.
That chart settles what failing actually is. Neither fail was slow: both reached the last ring quickly, then sat at 70–90% of it for more than a minute and a half while the timer ran out. I hypothesized that to beat the last checkpoint, the player must reach a specific speed.
Listened to the keyboards
Knowing how fast the ring moved wasn't enough on its own — I needed to know how fast the person was pressing to move it that much. So Claude detected keyboard clicks in the stream audio, starting from the loud stretches I'd flagged, and matched them against the ring's speed at the same moment. The first model it produced had streamers holding 12–15 presses a second for over a minute. I can get about 9 presses per second.
Tested it on myself
Rather than argue with the model, I became the control group. I tested out the game and recorded audio of my own keyboard while playing it. Lining the two up explained everything: my keyboard makes two clicks per press, one on the way down and one on the way back up, about 51 ms apart. My speed test had 87 presses in it, and the detector heard 177 clicks. The streamers' audio had the same double-click signature, which meant the first estimate of their speed was roughly twice the real number.
Key decisions & tradeoffs
- Model the push-back, not a timer
- A “press X times in Y seconds” rule would have been far easier to build and to tune, but it can't produce the stall the two fails show — under a timer you either make it or you're late, and nobody sits at 85% for ninety seconds. The catch is that video alone can't separate push-back that grows with fill from each press being worth less as the ring fills. Both fit the curves. I went with the one that matches the push-back you can see on screen.
- Share with the Reddit community
- I launched on itch.io and posted it to the NoPixel subreddit. The fanbase is dedicated enough that I was fairly confident of finding people who'd try it.
- Check for cheating
- The server replays each submitted run under the official settings, so faked times and 200-press-per-second autoclickers bounce off.
Outcome
The game is launched, and the Reddit post was successful!
The post brought in 626 verified runs from 249 players overnight, 339 of them in a single two-hour burst, and they are still coming in. 90% of those runs cleared, and 84% of players cleared on their first try — the same range as the streamers, where 5 of 7 passed. That is the shape I wanted: most people get through it, and the last ring is where it turns frustrating.
The server caught 60 autoclicker runs on top of those, none of them in the count above. The one that slipped under the speed limit gets fixed in v1.1. The real gap is the feedback I most wanted: only 40 “how did it compare” ratings from people who've played the actual hack, most of them on mouse or phone rather than a keyboard. I want considerably more of those before I touch the difficulty for v2.
Reflection
I'm happy with how this turned out, and mostly with how fast it went. It showed me how much is possible in a day when the work is split along the right seam: Claude does the heavy analysis and writes the code, and I bring what it can't — knowing the game, noticing when an output looks wrong, and being the test subject when the only way to settle a disagreement is to record my own hands.
The best part was watching the Google Sheet fill up as people from the community played it.