BE AWESOME
Settings
Games
📅 March 15, 2026 · ⏱️ 4 min read

Geometric Drafters, Formerly Perfect Shape

Scoring a freehand drawing against an ideal shape, and the rename that's still visible in the asset folder if you know where to look.

This post is about Geometric Drafters, Formerly Perfect Shape
Play Geometric Drafters →

This one's called Geometric Drafters today, but every image asset for it used to live in a folder named perfect_shape, because that's what I called it for most of the time I was actually building it. I renamed the game before launch and didn't bother renaming the folder until a later cleanup pass caught up with it. I seem to be developing a habit of doing this.

Scoring a drawing is not scoring an answer

The pitch is simple: you're shown a target shape — a circle, a star, some polygon — and you draw it freehand, and the game scores how close your line is to the ideal version. What that actually means in code is sampling your drawn path as a series of points and comparing it against a mathematically perfect version of the same shape at the same size and position, then turning that deviation into a number. The tricky part isn't the math, it's deciding what "close" should even mean for very different shapes. A slightly wobbly straight line and a slightly wobbly circle don't feel like the same size of mistake to a human eye, even if the raw pixel deviation is identical, so the scoring had to be tuned per-shape-type rather than with one universal formula.

Speed versus precision, and why both had to matter

Both how fast you draw and how accurate the result is feed into your score, and getting that balance wrong breaks the game in two different directions. Weight speed too heavily and the optimal play becomes scribbling something vaguely shape-adjacent as fast as possible, which isn't drawing, it's flailing. Weight accuracy too heavily and there's no reason not to take fifteen careful seconds per shape, which turns a game that's supposed to feel like a quick reflex test into something closer to a geometry exam. I landed on accuracy mattering more overall, with speed acting as a tiebreaker and a bonus rather than a primary score driver — close but rushed should usually beat far-off but careful, but perfect and fast should always beat perfect and slow.

Why every round has to be a genuinely fresh attempt

There's no way to trace over a faint guide line or snap to a grid — every shape is drawn completely freehand, with nothing on screen but the target to reference from memory of what a circle or a pentagon actually looks like. That was a deliberate constraint, not a missing feature. The moment you give someone a guide to trace, you're testing hand-eye coordination at following a line, which is a different and much less interesting skill than reproducing a shape from a mental model of it. It also means the game works identically well with a mouse or a finger, since neither input method gets an assist the other doesn't have.

Where the current scoring formula still shows its seams

The thing I'm least confident about right now is how proportions get scored on stars and other polygons. Right now the formula leans heavily on angle accuracy — did your points land at roughly the right angles around the center — without weighting overall size and proportion quite as strongly. That means it's technically possible to draw a star with correct angles but the wrong overall size relative to the target and still score higher than I think it should. I know this because I tested it deliberately, drawing a tiny, cramped version of a target star just to see what the number would say, and the number was more forgiving than my own eye was.

I haven't fixed it yet because I don't have a formula I'm confident is actually better rather than just different, and I'd rather ship an imperfect scoring curve I understand than a "better" one I picked because it felt more sophisticated. Proportion weighting is the kind of thing where it's easy to overcorrect and end up punishing shapes that are genuinely close, just at a slightly different scale than the reference. For now it stays as a known rough edge rather than a rushed fix.

Comparing two lines is harder than comparing two points

The technical piece underneath all of this is resampling. Your drawn path and the ideal shape's path almost never have the same number of points — a fast mouse drag records far fewer coordinates per second than a slow, careful one, and comparing two paths point-by-point when they have different lengths doesn't work at all. Both paths get resampled to an even number of points along their length before any distance comparison happens, so a rushed ten-point scribble and a careful two-hundred-point trace of the same shape end up compared on equal footing instead of the slower one automatically "winning" just by generating more raw data.

Touch input made this slightly worse before it got better. A finger drag on a phone samples points less frequently than a mouse move event does on desktop, so without resampling, touch-drawn shapes were scoring differently than mouse-drawn ones for reasons that had nothing to do with actual drawing skill — purely an artifact of how often each input method reports its position. Normalizing both to the same point count before scoring fixed that quietly, and it's the kind of bug that never would've shown up in a demo I ran on my own desktop; I only found it once I started testing on my phone specifically because I didn't trust that it would behave the same.

Rotation and orientation, or the lack of it

One thing I decided against on purpose: the comparison doesn't rotate your drawing to find its best-fit orientation against the target. If the target star is upright and you draw a recognizably correct star tilted ten degrees off, that tilt counts against you instead of being silently corrected for. It would be more forgiving to let the scoring search for the best rotation and grade against that instead, and for a while I thought that was obviously the friendlier choice. I backed off it because it would let someone "solve" every shape the same lazy way — draw something roughly star-shaped in whatever orientation is most comfortable and let the algorithm rotate it into alignment for you — which quietly removes the part of the task that's actually about spatial accuracy. Matching the orientation you were shown is part of the drawing task, not an unfair technicality layered on top of it.

Hello!