The feel test

A timing game is made of milliseconds. If the version you ship feels even a little worse than the one you designed, nothing built on top of it will fix that.

Prototype first

Renzy started as a single HTML file I could tune in a browser: the spawn rules, the timing windows, the armored enemies, the whiff lockout, the speed curve, plus a panel of sliders and a way to export every run as data. I iterated it to version 23 and handed it to testers, reading what the numbers said, before treating it as the standard the real game would be judged against.

Then gray boxes

The first Unity build had no art at all. Circles and rectangles. The job was to port the prototype exactly: touch input read the instant a finger lands, with no gesture recognizers and no tap delay, enemies on a game clock that pauses properly, and no memory allocated while a run is going, so the frame rate never hiccups in the middle of a strike.

The test

On 3 August I put the Unity build and the prototype on the same iPhone 16 Pro and played them back to back without looking at which was which. My verdict, written down at the time: it felt exactly like the prototype. That was the gate. I had decided in advance that if the Unity version felt worse, I would stop and fix input latency and frame pacing before writing anything else.

A small hurdle on the way

Getting a build onto an iPhone needs a recent Mac and Xcode, and the Mac I own is too old to run the current one. That first device build was done on a borrowed Mac. It is a boring detail, and also a reminder that the unglamorous parts of shipping a mobile game are real work.