noomiclone

noomiclone is a browser physics game built on a single piece of apparatus and four keys. A ragdoll gymnast hangs from a high bar, arches to build a swing, tucks to change rotation, and lets go at the moment that carries the body toward the next grip. The build runs as one Unity WebGL scene, so there is no map screen, no mode select and no route to choose before the first press. That is the whole reason the game rewards a shortest-route mindset: the problem never changes, only your inputs do.

Nothing on screen counts seconds. The readout at the top counts regrabs, starting at 0 on the opening hang and climbing each time the athlete finds the bar again. A run is scored by how far you get, while the thing you actually control is how few corrections each catch costs. Read the counter as distance, and treat the timing it never scores as the part you have to keep yourself.

The cost of a missed catch is not distance, because the counter does not go backwards. The cost is a reset plus the seconds it takes to rebuild the same swing, and each reset returns you to a bar that has not moved. Three corrections account for most of that waste, and they are easy to tell apart once you know which one you made.

Of the three, an early release is the cheapest to read. You undershoot, the body drops short of the grip, and the gap is visible in the air. A late release is the expensive one, because the flight looks almost right for half a second before the athlete sails past the bar. The third, holding the arch too long, reads as a good swing that arrives at the wrong part of the rotation.

No clock appears anywhere in the interface, so a timed run is something you bring to the game rather than something it hands you. The only readout counts catches: it sits at 0 on the opening hang and moves when the athlete finds the bar again. A long attempt and a clean attempt can therefore finish on the same figure, which is fine for distance and useless for a route.

That gap is the practical case for timing yourself. Count the keys spent on one catch rather than the catches in a session: four presses is tidy, six means a correction, eight means the release was decided before the swing was read. A personal best built on 40 regrabs and a run of 12 can carry the same counter value, which is why I would not treat the top of the screen as a speed scoreboard.

R is the closest thing this build has to fast travel. It drops you at the opening hang without a menu, a loading bar or a confirmation, so the distance between two attempts is one key press. In a game that shuffled scenes between attempts, a reset would hand you a different problem and the practice would not compound. Here it hands you the same one, and that is what turns a session of misses into a route you can repeat.

My reading is that the browser build behaves like a practice tool more than a campaign. One scene and an instant reset are the two properties a route planner would ask for, and this build has both, whether or not that was the intent behind shipping a single scene.

Most attempts fail for one of three reasons, and trying to fix all three at once hides which one you hit. Start with the release, because it is the only press that cannot be undone and the only one that leaves a readable trace: a short flight and a long one look nothing alike in the air. Hold the arch until the body passes under the bar, then let go on the way up rather than at the top.

The tuck is the second thing to learn and it is a smaller lever than it looks. It changes rotation speed, which buys or costs a fraction of a turn at the catch. Treat it as trim rather than as a save, and the timing of the release stops drifting between attempts.

One habit pays off early: keep the fixed bar in view instead of the swinging body. The bar is the only reference in the scene that does not move with the pendulum, so it is the one object that tells you where the release point actually is.