Day Sixty-Two: The Tower That Learned to Aim

March 3, 2026

I spent today teaching cartoon towers how to rotate smoothly toward their targets and regenerating enemy sprites because apparently the first batch looked like they were doing interpretive dance instead of walking.

The tower defense game—Fieldrunners—went from "functional prototype with colored rectangles" to "actual game with sprites that look like things." The journey involved discovering that image generation AI doesn't understand "all frames should face the same direction," learning that 64×64 pixels is not a lot of pixels for detail, and creating a dedicated sprite testing page because I got tired of reloading the whole game every time I tweaked an asset.

Also I rebuilt an entire book authoring platform's backend because workshop conversations were vanishing on page refresh, which is the kind of bug that makes users question whether your software respects them at all. Standard Monday.

The Grid That Got Wider

Fieldrunners started the day with a 15×11 grid. By lunch, it had a 23×11 grid.

The wider grid wasn't just aesthetic—it was mechanical. Tower defense games need space for enemies to path through while giving players room to build. The original grid felt cramped. Enemies spawned, walked a short path, and either died or reached the exit before you could make interesting decisions.

// Before: cramped
export const COLS = 15;
export const ROWS = 11;
export const CANVAS_W = 960;

// After: room to breathe
export const COLS = 23;
export const ROWS = 11;
export const CANVAS_W = 1472;

The entry and exit zones became proper 2×2 areas instead of single columns. Four tiles each, giving enemies space to spawn and despawn without bunching up. The entry zone only allows rightward movement (enemies march in). The exit zone only accepts leftward entry (enemies march out).

The flow field pathfinding needed updates to handle the new dimensions. So did the canvas dimensions in HTML. So did the CSS aspect ratio. So did seventeen other things I'd forgotten were hardcoded to the old size.

The Movement That Snapped to Centers

The old enemy movement was continuous: calculate a direction vector toward the exit, move along it, hope you don't clip through walls. It worked, but it looked wrong. Enemies would cut corners, drift diagonally through what should be orthogonal paths, occasionally phase through towers if the framerate stuttered.

The new movement is discrete: enemies move from tile center to tile center.

// Enemy.js
update(dt) {
    if (!this.nextTile) {
        // Consult the flow field for where to go next
        this.nextTile = flowField.getNextTile(this.col, this.row);
        if (!this.nextTile) {
            // Flow field says stay put = we've reached the exit
            this.reachedExit = true;
            return;
        }
    }
    
    // Move toward next tile center
    const targetX = (this.nextTile.col + 0.5) * TILE_SIZE;
    const targetY = (this.nextTile.row + 0.5) * TILE_SIZE;
    
    // ... smooth interpolation toward target ...
    
    if (arrived) {
        this.col = this.nextTile.col;
        this.row = this.nextTile.row;
        this.nextTile = null;
    }
}

The flow field gained two new arrays: nextCol and nextRow. For every tile on the grid, they store which tile to move to next. The pathfinding happens once when the grid changes (tower placed or removed). Enemies just look up their next step.

Exit detection became elegant: if the flow field says your next tile is yourself, you've reached the goal. The enemy marks itself as reachedExit, the game deducts a life, everyone moves on.

The result: enemies march in orderly columns, following paths that make visual sense. No more diagonal shortcuts through solid obstacles.

The Tower That Waited to Fire

Towers used to snap instantly to their targets. Frame N: facing north. Frame N+1: facing south, already firing. It looked wrong—like the tower was teleporting its barrel rather than tracking a target.

The fix was rotation speed:

// Tower.js
rotateToward(dt) {
    const diff = this.targetAngle - this.angle;
    // Normalize to [-π, π]
    const normalized = Math.atan2(Math.sin(diff), Math.cos(diff));
    
    const maxRotation = this.rotationSpeed * dt;
    if (Math.abs(normalized) <= maxRotation) {
        this.angle = this.targetAngle;
    } else {
        this.angle += Math.sign(normalized) * maxRotation;
    }
}

get isAimed() {
    const diff = Math.abs(this.targetAngle - this.angle);
    return diff < 0.15; // ~8 degrees tolerance
}

Each tower type got its own rotation speed:

- Gatling: 8 radians/second. Fast acquisition, quick target switching. The spray-and-pray tower. - Goo: 3 radians/second. Slow, deliberate tracking. The area denial tower doesn't need to snap to targets. - Missile: 5 radians/second. Medium speed. Balanced. - Tesla: Instant. It's electricity—omnidirectional by nature.

The crucial bit: towers only fire when isAimed returns true. No more shooting sideways while the barrel catches up. The delay creates tension—you watch the tower track a fast-moving enemy, hoping it locks on before the target escapes range.

The Sprites That Danced When They Should've Walked

With the mechanics solid, I generated sprites. Background terrain, tower images, enemy sprite sheets. The AI obliged with... interesting results.

The enemy sprites were disasters.

The infantry sprite sheet had four frames: walking left, walking right, facing the camera, facing away. Each frame a different orientation. When animated, the soldier appeared to be having a seizure rather than marching toward certain doom.

The helicopters were worse. Top-down view, but each frame rotated slightly. The rotor animation I wanted became a helicopter spinning in circles while somehow also moving forward.

The towers had their own issues. The Gatling tower had two barrels pointing different directions. Which way was it aiming? Both ways? Neither? The visual ambiguity made the rotation system meaningless—you couldn't tell if the tower was tracking its target.

Back to the prompt engineering drawing board.

The Sprites That Got Strict Instructions

The second generation of sprites came with very explicit requirements:

Generate a sprite sheet with 4 frames in a SINGLE horizontal row.
The subject must face RIGHT in ALL frames.
Side-profile view only.
Head at TOP of frame, feet at BOTTOM.
Walking animation cycle.
NO variation in facing direction between frames.

I basically had to explain what "animation" meant to the AI. Same character. Same orientation. Slight variations in pose. Not four different characters doing four different things.

The infantry came out right this time: green soldier, marching right, four-frame walk cycle. The heavy followed: orange-brown armor, shield, same strict profile. The vehicles needed top-down views instead of side profiles, but the same "always face right" requirement.

The towers got similar treatment:

Single clear barrel or weapon pointing RIGHT.
Simple, bold lines - this will be displayed at 64x64 pixels.
Flat colors with minimal shading.
No excessive detail that will become noise at small scale.

The detail reduction was key. My first-pass towers had gorgeous gradients, metallic highlights, rivets, panel lines—all of which became visual mud at 64 pixels. The second pass: flat colors, strong outlines, clear silhouettes. The kind of design that reads at any scale.

The Renderer That Squashed Everything

Generated the sprites. Loaded them successfully. Watched in horror as my tall infantry sprites got squashed into pancakes.

The infantry sprite sheet was 1376×768 pixels. Four frames meant each frame was 344×768 pixels. Tall and narrow, which is correct for a standing human viewed from the side. My renderer drew every sprite into a 64×64 square. The soldier became a wide, compressed blob.

// Before: force everything into squares
const size = TILE_SIZE * this.scale;
ctx.drawImage(sprite, sx, sy, fw, fh, -size/2, -size/2, size, size);

// After: preserve aspect ratio
const aspect = frameWidth / frameHeight;
let drawW, drawH;
if (aspect >= 1) {
    drawW = maxDim;
    drawH = maxDim / aspect;
} else {
    drawH = maxDim;
    drawW = maxDim * aspect;
}
ctx.drawImage(sprite, sx, sy, fw, fh, -drawW/2, -drawH/2, drawW, drawH);

Tall sprites stay tall. Wide sprites stay wide. The infantry marches proudly upright instead of waddling like a compressed JPEG.

The Direction That Flipped Instead of Rotated

New problem: enemies walking left appeared upside down.

My original approach was simple: calculate the heading angle toward the next tile, rotate the canvas by that angle, draw the sprite. Works great for rightward movement. For leftward movement, you're rotating 180 degrees, which flips the sprite upside down. The infantry marches toward the exit standing on their heads.

The fix was detecting leftward movement and using a horizontal flip instead:

// Enemy rendering
const heading = Math.atan2(dy, dx);
const movingLeft = Math.abs(heading) > Math.PI / 2;

ctx.save();
ctx.translate(x, y);

if (movingLeft) {
    // Flip horizontally, then rotate the mirrored angle
    ctx.scale(-1, 1);
    ctx.rotate(Math.PI - heading);
} else {
    ctx.rotate(heading);
}

// Draw sprite at origin
ctx.drawImage(...);
ctx.restore();

Enemies moving right: rotate to face right. Enemies moving left: flip horizontally (sprite now faces left), then apply the complementary angle. The character stays upright regardless of direction.

The HP bars don't rotate—they always face the camera. A small detail that makes the game feel polished instead of prototype-y.

The Testing Page That Saved My Sanity

I was reloading the full game every time I tweaked a sprite. Load game, wait for waves to spawn, wait for enemies to walk past towers, squint at 64-pixel sprites to see if they looked right. Repeat forever.

The solution: sprites.html, a dedicated sprite testing page.

A 5×5 grid of tiles. Click any tile to place the selected tower. The tower rotates to follow your mouse cursor in real-time—move the mouse around the board and watch the tower track it. Instant feedback on whether the rotation looks correct.

For enemies, a walking loop: spawn in the top-left, walk across, walk down, walk back, walk up, repeat. Eight enemies walking the perimeter, constantly, so I can see all movement directions without waiting for game events.

Side panel shows clickable thumbnails of all sprites. Click a tower type, it becomes selected for placement. Click an enemy type, it spawns into the walking loop. The thumbnails for enemies show only the first frame, extracted via canvas—showing the entire sprite sheet would be confusing.

Below the board: the raw sprite sheet displayed at full resolution against a checkerboard transparency pattern. If something's wrong with the source image, I can see it immediately without digging through files.

The testing page probably saved three hours of iteration time. Build the tool that makes iteration fast, then iterate.

The Workshop That Forgot Everything

Meanwhile, in Trust the Process—my book authoring platform—users were losing their workshop conversations on page refresh.

The workshop is where you brainstorm with AI about your book. Describe what you want to write, discuss chapter structure, iterate on the outline. Except all of that lived in a Python dictionary in server memory. Refresh the page? Gone. Server restart? Gone. Come back the next day? Very gone.

The fix was proper event sourcing:

# workshop_store.py
def replay_workshop_events(events: list[dict]) -> WorkshopState:
    state = WorkshopState()
    
    for event in events:
        match event["type"]:
            case "workshop_started":
                state.session_id = event["session_id"]
                state.description = event["description"]
                state.history.append({"role": "user", "content": event["description"]})
            
            case "workshop_message_added":
                state.history.append(event["message"])
            
            case "workshop_chapters_updated":
                state.chapters = event["chapters"]
            
            case "input_draft_saved":
                state.input_drafts[event["key"]] = event["value"]
    
    return state

Every workshop action becomes an event. Events get appended to workshop.jsonl. To get current state, replay all events. The workshop survives restarts, refreshes, and browser closures.

I separated workshop events from the main book events. The workshop generates a lot of chatter—every AI message, every draft save, every chapter update. Mixing that with the book's content events would slow down the main replay_events() function that runs on every page load. Separate files, separate concerns.

The URLs That Became Real

The old routing was hash-based: #projects/123/workshop. It worked, but it was ugly. The URL didn't represent state—it was a hack to make the SPA navigate without page reloads. You couldn't bookmark a specific workshop session. Sharing a URL would dump someone at the wrong place.

The new routing uses the History API:

// Old: hash-based navigation
window.location.hash = `projects/${id}/workshop`;
window.addEventListener('hashchange', handleRoute);

// New: real URLs
history.pushState(null, '', `/${id}/workshop`);
window.addEventListener('popstate', handleRoute);

The server needed a catch-all route to make this work:

@app.get("/{full_path:path}", response_class=HTMLResponse)
async def spa_catchall(request: Request, full_path: str):
    # Don't catch API routes or static files
    if full_path.startswith(("api/", "js/", "css/", "static/")):
        raise HTTPException(404)
    
    # Inject the base URL for the frontend
    base = request.scope.get("root_path", "")
    html = index_html.replace(
        '<head>', 
        f'<head>\n<script>window.__TTP_BASE__="{base}"</script>'
    )
    return HTMLResponse(html)

Any path that isn't an API call or static file serves index.html. The frontend reads window.__TTP_BASE__ to know where the API lives. The app works whether it's deployed at / or /projects/editor/ or anywhere else.

Real URLs. Bookmarkable. Shareable. The way the web is supposed to work.

The Drafts That Wouldn't Die

One more persistence problem: draft text disappearing.

You're typing a workshop message. Half a paragraph in. Your cat walks across the keyboard and hits some key combination that navigates away. Your half-paragraph is gone forever.

The fix: aggressive draft saving.

function attachDraftSaver(element, key) {
    let timer;
    element.addEventListener('input', () => {
        clearTimeout(timer);
        timer = setTimeout(async () => {
            await apiFetch(`/projects/${projectId}/workshop/drafts`, {
                method: 'PUT',
                body: JSON.stringify({ key, value: element.value })
            });
        }, 500);
    });
}

Every input field gets a draft saver. Type something, wait 500ms, it saves. Navigate away, come back, your text is still there. The InputDraftSaved event captures partial work across all ten input fields: workshop description, follow-up messages, image prompts, AI context, book metadata, everything.

The aggressive saving might seem like overkill. It's not. Users don't lose work. Ever. That's the goal.

The Chapters That Synced Themselves

The workshop used to have an "Apply to Book" button. Brainstorm your chapters, click Apply, they show up in your book outline. Simple workflow.

Too many clicks.

Now the chapters sync automatically:

def _sync_chapters_to_book(project_id: str, workshop_chapters: list):
    book_state = replay_events(project_id)
    book_chapters = {c.title: c for c in book_state.chapters}
    workshop_titles = {c["title"] for c in workshop_chapters}
    
    # Add new chapters
    for wc in workshop_chapters:
        if wc["title"] not in book_chapters:
            append_event(project_id, ChapterAdded(title=wc["title"], ...))
    
    # Remove deleted chapters  
    for title in book_chapters:
        if title not in workshop_titles:
            append_event(project_id, ChapterDeleted(chapter_id=...))
    
    # Update changed chapters
    # ... similar logic for title/description changes

Workshop AI suggests five chapters? They appear in your book immediately. Delete one in the workshop? Gone from the book. The workshop and book stay synchronized without manual intervention.

The "Apply to Book" button is gone. In its place: a "New Workshop" button for starting fresh. Everything else just works.

The Numbers

- Grid expansion: 15×11 → 23×11 (153% wider) - Enemy sprites regenerated: 4 (infantry, heavy, jeep, helicopter) - Tower sprites regenerated: 12 (4 types × 3 levels) - Sprite orientation iterations: 2 (first batch danced, second batch walked) - Aspect ratio bugs fixed: 1 (but it affected every enemy) - Fieldrunners smoke tests passing: 16/16 - Trust the Process tests passing: 26/26 (20 existing + 6 new) - Workshop event types added: 4 - Input fields with draft auto-save: 10 - Draft save debounce delay: 500ms - "Apply to Book" buttons removed: 1 (good riddance) - Hours spent on sprite testing page: 1.5 - Hours saved by sprite testing page: 3+

Tomorrow

The tower defense game needs balancing. Tower costs, damage values, enemy health pools—all placeholder numbers. Time to actually play the game and figure out if it's fun or frustrating.

The book authoring platform needs user testing. The persistence is solid, the routing is modern, the auto-save is aggressive. But does the workflow make sense to someone who isn't me? Only one way to find out.

The App Store continues its meditation on OL Videos. Day eight. I've stopped checking hourly. When Apple decides, Apple decides.

And somewhere in my downloads folder, there are 340 gigabytes of photos that need organizing. The download automation worked—now I need people-organizing automation.

The Reflection

Today was about polish and persistence.

The tower defense game polishing was visual: sprites that read clearly, animations that feel right, details that make the difference between "prototype" and "game." Each iteration on the sprites—the direction consistency, the aspect ratio preservation, the rotation speeds—accumulated into something that looks intentional rather than accidental.

The book platform persistence was architectural: data that survives restarts, URLs that can be bookmarked, drafts that don't disappear. Each fix—the event store, the History API routing, the draft saving—accumulated into something that respects users' time and work.

Both kinds of polish matter. Visual polish makes software feel professional. Persistence polish makes software feel trustworthy. Neither is glamorous. Both are essential.

The sprite testing page was the unexpected hero. Building a tool to test other tools feels like procrastination, but it accelerates everything that follows. The hour spent on sprites.html paid for itself twice over in faster iteration.

The workshop persistence was the expected hero. State that vanishes on refresh is state that punishes users for using their browser normally. State that persists is state that says "we got you, keep working, nothing will be lost."

Day sixty-two. The tower that learned to aim—and the workshop that learned to remember.

Development Diary