Chapter 4 Personal Game Dev

---
title: "Part 23 · Chapter 4. The Puzzle Game I Built Alone — A Critter Sort Field Report"
part: 23
chapter_in_part: 4
status: v3
written: 2026-05-24
version: v3
author: 이민수
ip_check: done
---

# Part 23 · Chapter 4. The Puzzle Game I Built Alone — A Critter Sort Field Report

One Saturday afternoon, my wife was playing a color-matching puzzle on her phone. It was a game called *Yarn Fever*, where you sort tangled skeins of yarn into baskets of the same color. Every time a round ended she would say, "Same thing again," and close it. With nothing new coming, she got bored fast.

The thought that hit me at that moment was simple. That loop has proven addictiveness, and the mechanic itself is not subject to copyright. Swap in an animal theme, stamp out levels procedurally without end, and the "same thing again" problem disappears. Build it alone, as HTML 3D that runs right in the browser, and my wife doesn't even need to install anything on her phone.

The problem is that I am not a graphics engineer. Twenty-four years as a game designer, but I had never written a shader with Three.js. So this chapter is the actual record of getting one game running in a few days, alone, with AI. It is also a record of separation: I used the same tools as my company MMORPG (Project A hereafter) while mixing in not a single line of its domain content.

The actual game lives in the `critter-sort/` repository, and git tags v0.1–v0.3 preserve three days of decisions. This is not a polished-up case study; I quote that repository as is.

---

## 23.4.1 Reverse Engineering by Prompt — And Losing the Signature

The first thing I did was break the original down into words and throw it at the AI. The first prompt went like this.

> **Prompt (v0.1 kickoff):**
> "I want to adapt the core loop of a casual puzzle called Yarn Fever to an animal theme, built with Three.js + Vite. The loop goes like this: you sort tangled color-clumps into bins of the same color, and if you overflow the temporary slots, it's game over. Let's make animals the things being sorted — tap a tangled pile of animals and they go to a nest of the same color. Write the logic as a pure JS state machine independent of Three.js so it can be tested headless. Also add procedural infinite levels (seed-based)."

The AI followed faithfully. It split the folder structure into `game/` (pure logic) and `render/` (Three.js), wrote `state.js`, `rules.js`, and `generator.js` first, then put the board on screen with colored-box placeholders. v0.1 was running not in days but in a single session.

But the moment I played it myself to show my wife, something felt off. It had become a generic match puzzle where animals hop across the screen into baskets. The feel of the original was gone. *Yarn Fever*'s identity was not "sorting" — it was **the tactile sensation of untangling skeins by hand** and **the act of rotating the screen to check colors hidden from view**. In my prompt I had flattened that into a generic sort — "tap an animal and it goes to a nest" — and the AI had simply been faithful to the definition I gave it.

This is the first trap of reverse engineering. Summarize the original and the signature evaporates, because a summary preserves the surface, not the essence.

Let me make one thing clear here. The AI did not give a wrong answer. My prompt was wrong. So the next cycle was not a code fix but **a correction of the definition**.

---

## 23.4.2 The Spine — The Correction Cycles That Revived Rotation and Unraveling

Right after seeing v0.1, I respecified the core in two passes. The first correction targeted the action; the second targeted the feel.

> **Prompt (correction 1 — the action):**
> "This has turned into a plain match puzzle. Yarn Fever's identity is 'rotating the 3D view to check hidden colors and deciding the order to unravel.' Don't scatter the board flat — pile it into a tall mound in the center so you have to rotate to see the colors hidden behind. Add rotation with OrbitControls. But rotation and tap are going to conflict — how will you separate them?"

> **Claude's output (raw, no summarizing):**
> "You're right. The rotation gesture and the tap are the same pointer events, so they conflict. I propose splitting them by distance and time thresholds. Record the coordinates and timestamp on `pointerdown`; on `pointerup`, if the travel distance exceeds 9px or the press duration exceeds 400ms, treat it as a rotation gesture and ignore the tap. Only below that do we pick an animal with the raycaster and call `state.tap()`. I'll clamp OrbitControls' azimuth to about ±54° so the pile doesn't drift off screen. One caveat: 9px may be too sensitive on mobile, so it needs checking on a real device."

That 9px/400ms threshold still lives in `src/main.js` today. No-frills code you can verify directly.