Show Dev: A Dragon That Burns Your Village If You Misspell

Jean Michael Mayer — Sun, 19 Apr 2026 20:35:05 +0000

The pitch

I built The Dragon's Dictionary: a bilingual (English/Portuguese) word game where a hoarding dragon eats words you feed it. Spell them right, the dragon is pleased and adds them to its hoard. Spell them wrong, and it torches your village.

It started as a joke about how Duolingo's owl is menacing but polite. I wanted something that felt genuinely unhinged — a creature that cares more about its word collection than your feelings.

Why a dragon, why two languages

I'm learning Portuguese. Most vocab apps treat bilingual learners like monolinguals who happen to own a dictionary. I wanted a game where switching languages mid-session is the point, not a settings toggle buried three menus deep.

The dragon also solves a UX problem I keep hitting with language apps: stakes. Flashcards have no stakes. A burning village has stakes. The cognitive load of "don't kill the villagers" turns out to be a surprisingly effective mnemonic device.

The weird technical choices

It's almost entirely AI-generated. Not "AI-assisted" — I mean the dragon's reactions, the villager names, the insults it hurls when you fail, are generated on demand. I keep a small corpus of base words and let the model riff on reactions per session. This is why the dragon feels inconsistent in a charming way: it is inconsistent.

It runs in its own Railway service. I have a small constellation of side projects under edgecasefactory.com, and I used to cram them all into one monorepo behind one Next.js deployment. That was a mistake. One project's dependency bump would break two others. Now each dragon, factory, and whatever-else gets its own Railway service with its own lifecycle. Deploys take 40 seconds and I stopped dreading npm update.

No database for game state. The dragon's hoard lives in localStorage. I considered Postgres, Redis, SQLite-on-a-volume, the works. Then I remembered this is a game about a dragon and nobody needs their village-burning history to sync across devices. Deleting the database was the single best architectural decision I made.

The scoring loop

Here's the core validation call. The model grades the word, returns a reaction, and decides the dragon's mood:

async function feedDragon(word, lang) {
  const res = await fetch('/api/feed', {
    method: 'POST',
    body: JSON.stringify({ word, lang, hoard: getHoard() })
  });

  const { valid, reaction, mood, villagersLost } = await res.json();

  if (valid) {
    addToHoard(word);
  } else {
    burnVillage(villagersLost);
  }

  return { reaction, mood };
}

The server-side check does two things: a dictionary lookup (cheap, deterministic) and an LLM call for the reaction text (expensive, flavorful). If the LLM times out, the dragon just grunts. Graceful degradation, dragon-style.

What surprised me

Portuguese has a lot of accented characters that are easy to get wrong on a US keyboard. I ended up adding a "close enough" mode because forcing learners to type ção correctly on first try felt more like a bureaucratic form than a game. The dragon now accepts cao but makes fun of you for it.

Also: players burn their own village on purpose. A lot. I did not design for this. I now embrace it.

Try it

🐉 dragons-dictionary.edgecasefactory.com

Feed the dragon. Don't feed it gibberish. Or do — the villagers signed waivers.

Feedback welcome, especially from Portuguese speakers who want to tell me my conjugation tables are wrong.

Show Dev: Your Face Is Now a Music Generator

Jean Michael Mayer — Sun, 19 Apr 2026 19:27:43 +0000

The Dumbest Idea I've Shipped This Month

I built a thing called The Mood Ring Playlist. It points your webcam at your face, reads your emotions, and generates a live music track that shifts as you do.

Smile? Tempo kicks up, major key, bright pads. Scowl at your code review? Minor key, slower, a little more low end. Zone out completely? It drifts into ambient territory.

This article is the "why would you do this" post, plus a couple of technical choices that turned out weirder than I expected.

Why Build This

I wanted to play with two things at once: browser-based face detection and procedural audio. Every "AI music" demo I've seen is either:

Generate a 30-second clip, wait, listen, regenerate.
Upload a giant model to the browser and pray the user's laptop doesn't melt.

I wanted something continuous. Not "click to generate a song" but "the song is you, right now." That framing changed every architectural decision.

Face In The Browser, Music On The Server

Face detection runs entirely client-side. Webcam frames → face landmarks → a small vector of emotion probabilities (happy, sad, angry, surprised, neutral, etc.). None of that leaves your machine. This is both a privacy win and a latency win — I don't want to ship webcam frames across the internet just to find out you're mildly annoyed.

The music generation, though, lives in its own Railway service. That was deliberate. The main Next.js app is a thin frontend. The generator is a separate long-running Node service that holds state, manages the synthesis graph, and streams parameter updates based on the emotion vector it receives.

Why split it?

Cold starts would kill the vibe. Serverless functions booting mid-song is not a vibe.
It's stateful. The generator needs memory of what was just playing so transitions don't sound like someone slapping the radio dial.
I can redeploy the UI without killing the audio.

The client just posts emotion snapshots and receives back instructions for what the Web Audio API should do next.

useEffect(() => {
  if (!emotions) return;
  const id = setTimeout(async () => {
    const res = await fetch('/api/mood', {
      method: 'POST',
      body: JSON.stringify({ emotions, t: performance.now() }),
    });
    const { tempo, key, layers } = await res.json();
    mixer.current?.update({ tempo, key, layers });
  }, 250);
  return () => clearTimeout(id);
}, [emotions]);

That 250ms debounce matters. Early versions updated every frame and the music sounded like a panic attack. Humans don't actually change mood 60 times a second — who knew.

The AI Part, Honestly

The "AI" here isn't a giant model generating waveforms. It's a smaller system that maps an emotion vector to musical parameters: scale, tempo range, instrument layer weights, chord progression tendencies. Think of it as a learned policy over a procedural music engine, not Suno-in-a-box. That's how it stays real-time.

I tried the "just call a big model every few seconds" route first. It sounded great when it worked and terrible when it stitched. Seams everywhere. The procedural-with-a-smart-director approach wins because continuity matters more than novelty in ambient music.

Known Weirdness

If you wear glasses with heavy reflections, it thinks you're surprised a lot.
If you laugh hard enough to close your eyes, it briefly assumes you left.
Lighting matters more than I'd like. Sorry.

Try It

Give it your face for a minute. See what you sound like today.

👉 mood-ring-playlist.edgecasefactory.com

Headphones recommended. Webcam required. Judgment optional.

Forem: Jean Michael Mayer