The brief: make a drawing exercise or game that teaches a computational concept, test it with someone, and document what happens.
Finding a concept
I started with a list of things I thought might count as a computational concept — loops, sequence, conditionals, variables, events, class, style, recursion.
Recursion is the one I kept coming back to. I first thought it worked like a loop, which I understood as a set of rules a program follows repeatedly until it reaches some goal. But recursion is defined as a function calling itself, directly or indirectly. The similarity between the two — and how easily I confused them — is exactly why I picked it.
Understanding the concept
Digging into what people actually use recursion for, one line helped more than any definition:
If a problem can be broken down into similar subproblems which can be solved individually, and whose solutions can be combined together to get the overall solution, then there might exist a recursive solution to the problem1.
It turns out "how do you explain recursion to a four-year-old" is a popular interview question and a popular forum thread2.

Designing a game
The general flow of a recursive function: initialise with data; check whether the current value matches the base case and return it if so; redefine the answer in terms of a smaller subproblem; run the algorithm on that; combine the results; return.
My first attempt at translating that into a drawing exercise:
- Draw two circles on a piece of paper. The first can be anywhere, any size.
- Draw another circle of any size that intersects one edge of the paper at a point and touches at most one other circle.
- If there is no room for another circle, stop. Otherwise repeat.

The game stopped almost immediately. You can only draw so many big circles before you are left tracing small ones along the paper's edge, and the participant never got the feeling of recursion — though he did say it reminded him of fractals, and suggested polygons instead.
So I looked up what a fractal is: a geometric shape containing detailed structure at arbitrarily small scales, with a fractal dimension strictly exceeding its topological dimension3. The mathematical version of the same idea is the factorial —
n! = n × (n−1) × … × 3 × 2 × 1, and 0! = 1
— and dividing or multiplying a number by one a single step smaller than itself turned out to be a good way to write rules for a game.

A second design, from that:
- Draw a polygon with three sides of any length.
- Find the longest side of the last polygon and its midpoint.
- Draw a line perpendicular from that midpoint, any length.
- Connect the far end of that line to either end of the longest side.
- Repeat until a new polygon intersects an earlier one or the edge of the paper.

This was far more interesting to play, and the same participant said it did give him the feeling of recursion. I explained that recursion breaks a large problem into smaller versions of itself — here, one side of every new polygon is half the longest side of the last. Restricting the turn to only left or only right would give the system a drift.
Expanding the game
The exercise reminded me of a paper I read a few years ago, Michael Hansmeyer's Design by Subdivision4. Subdivision is recursive by nature, and it is what modern modelling software uses to soften geometry: the higher the level, the smoother the surface and the more compute it costs.
Where Catmull–Clark subdivision splits every quad into four smaller quads by fixed averages and smooths an object, Hansmeyer turned that smoothing utility into a generative framework. He introduced variable weights controlling how far points move or extrude at each step, calculated from the mesh's own geometry — topology, vertex valence, edge motives, local curvature and planarity — and from external spatial fields around the object. Which is my steps two and three combined into a loop that does more than take the midpoint of the longest edge.

What interests me is that he produces non-reductionist complexity with an algorithm rooted in reductionism. The reproduction of faces is deterministic and traceable — just not by hand. It can only be reached by writing rules a computer can follow.
Below is an attempt, with Claude Code, at implementing Hansmeyer's methods in a browser: starting from primary polyhedra and subdividing into surfaces that never smooth out.


After making a few subdivision creatures I added a live camera feed to the canvas to see how far it could be pushed:
- Depth Anything V2 (small) via transformers.js, for real depth in the feed.
- MediaPipe's selfie segmenter, for subject isolation.
- Hansmeyer's modified Catmull–Clark subdivision, written from scratch in TypeScript.
- A web worker, so the subdivision runs off the main thread and the interface stays smooth.
- Three.js through React Three Fiber for the 3D view.
- React, TypeScript, Vite and Tailwind for the interface, with tokens and fonts from my own design system.
Conclusion
It was genuinely fun to learn a computational concept by designing a game for it. What I did not expect is how little separates the two ends: a system as involved as the subdivision sculptor is a more detailed, better-instructed version of the triangle game. Whether the instructions are for a person or a machine, it comes down to how clear and how neat the instructions are — which is also, I think, what improved my commanding when coding with agents.
References
-
Wong, I. (n.d.) 'Recursion: a step-by-step introduction', Medium. Available at: medium.com (Accessed: 24 September 2026). ↩
-
freeCodeCamp (n.d.) 'Recursion demystified'. Available at: freecodecamp.org (Accessed: 24 September 2026). ↩
-
Khan, S. (n.d.) 'Understanding the recursive nature of fractals', Medium. Available at: thesagekhan.medium.com (Accessed: 24 September 2026). ↩
-
Hansmeyer, M. (2010) 'Design by subdivision', Bridges 2010. Available at: bridgesmathart.org (Accessed: 24 September 2026). ↩