Lantern Run: a Halloween roguelike built with Kiro

kevin huang — Fri, 13 Nov 2026 06:59:00 +0000

This post was written as part of the Kiroween 2026 hackathon.

Lantern Run is a small browser roguelike. You are a jack-o'-lantern carrying a flame through four rooms. The flame goes out over time, ghosts drain it, and candy restores it. Clear each room by collecting its candy goal and reaching the door. After each of the first three rooms you pick one upgrade. The fourth room holds the Pumpkin King.

Play it: https://hyy12345678.github.io/lantern-run/
Code: https://github.com/hyy12345678/lantern-run

Why a roguelike

A jack-o'-lantern is already a small light in the dark, so the game is about protecting that light, not fighting. Roguelikes suit this: each run is short, the rules are simple, and every choice changes what happens next.

How Kiro shaped the project

I used Kiro's spec, steering, and hooks features. Everything lives in the .kiro/ folder of the repo.

Specs. requirements.md lists 13 requirement groups, each with acceptance criteria. design.md covers the modules, data types, tuning values, and test plan. tasks.md tracks progress. When I changed the game from three nights to a roguelike, I updated all three files, then rebuilt the task list around the new run structure.
Steering. Three files keep the project consistent. One sets scope rules, one sets code rules (for example, the core logic must not import Phaser), and one sets the palette and motion limits.
Hooks. One runs the TypeScript check every time a .ts file is saved. Another runs the test suite after each spec task.
Property-based tests. fast-check checks the core rules: the flame stays within bounds, levels are deterministic for a given seed, and the blow ability only moves ghosts inside its radius.

How it works

The game logic lives in src/core/, which has no Phaser imports, so I could test it with Vitest and fast-check without a browser. Phaser scenes only connect input and drawing to that logic.

Levels come from a seeded random generator. The same seed always gives the same map. The generator carves a guaranteed route from the start to the door and uses breadth-first search to keep every candy and ghost reachable.

Everything on screen is drawn in code. There are no image or audio files. Sound effects are synthesized with the Web Audio API.

What worked

Specs kept the work on track, especially after the big change in structure.
Steering kept new code and visuals consistent without re-explaining the rules each time.
Hooks removed a lot of manual checking.
Property tests caught the kinds of bugs that unit examples miss, such as a boundary case in the flame math.

What didn't

The roguelike pivot was the hardest part. Rewriting the spec and reorganizing the tasks took real effort, and keeping the three spec files in sync was easy to get wrong.
Automated tests show that the rules are correct, but not that the game is fun. Balance still needed manual playtesting.

Try it and tell me what you think

If you have a few minutes, play a run and tell me where it feels unfair. I am most interested in whether the upgrades feel meaningful and whether the boss room is too punishing.

Thanks for reading, and happy Kiroween!