Jason M. Ziegler

Larn-like · Working title · Case study

What if dying made the world more alive?

Larn-like is a browser roguelike where a lost character does not simply disappear. The monster that killed them grows stronger, their equipment can change hands, and their death leaves resources and a shrine for whoever comes next.

Play the live demo See the evidence Review the source
Larn-like town screen rendered in green terminal-style ASCII graphics, showing player statistics, a merchant, the dungeon entrance, and the player character.
An actual development build of the town screen. The game uses a canvas renderer to recreate the feel of an old terminal roguelike.

The original idea

Make every attempt part of a world that remembers.

This project is inspired by Larn, the 1986 roguelike created by Noah Morgan. I was drawn to its compact, arcade-like structure and began imagining how that kind of roguelike could move in a different direction. Larn-like is a working title for this independent experiment. It is not presented as an official sequel, port, or continuation of the original game.

The first version of my idea was closer to an arcade game. A player would pay a very small amount to begin a hero. Death would be permanent, but the time spent playing would continue to matter.

A killer monster could take the hero’s equipment, become stronger, and move deeper into the dungeon. Teeth left at the death site could become currency. A shrine could give a future hero another way to use what the previous character had built.

The larger goal was to explore whether a game could create value with its players instead of only extracting money or attention from them. The payment and player-owned economy remain a design horizon. They are not part of the current prototype and have not been validated.

The bounded experiment

Build the consequence first.

Before testing an economy, the game needed to prove that one player’s loss could create something meaningful for the next attempt.

  1. 01A hero dies

    The game records who died, where it happened, and which monster delivered the final blow.

  2. 02The killer evolves

    The monster gains statistics, records the hero in its history, takes a trophy, and moves deeper.

  3. 03The world keeps the loss

    Teeth, equipment, the promoted monster, and a soul shrine are stored in IndexedDB.

  4. 04A new hero inherits it

    The next character starts fresh but enters a world changed by the heroes who came before.

What exists now

A working game loop around persistent consequences.

01

Playable foundation

Procedural dungeon levels, a town and merchant, movement, turn-based combat, equipment, inventory, status effects, statistics, and achievements.

02

Persistent world

Generated levels, heroes, monsters, death events, teeth drops, shrines, and pending monster promotions are stored locally in a versioned IndexedDB database.

03

Death as content

Killer monsters evolve and carry history forward. Death sites leave currency and shrines that future heroes can use to bless equipment.

04

Visible history

The interface exposes evolved monsters, trophy equipment, world statistics, and the effects left behind by previous characters.

What the prototype proves today

One death can become part of another player’s world.

The current prototype does not prove the larger player economy yet. It does demonstrate the central mechanism that makes that idea worth exploring.

01

The world remembers

A hero’s death becomes a persistent world event instead of disappearing when the run ends.

02

The killer carries history

The monster evolves, records the fallen hero, takes a trophy, and moves deeper into the dungeon.

03

Loss becomes opportunity

Teeth, equipment, and a soul shrine give future heroes something to discover and use.

04

The next hero inherits the consequences

A new character begins from scratch but enters a world shaped by previous attempts.

Verified walkthrough · local production build

Mara dies. Iris inherits the consequences.

This sequence follows one controlled run through the real persistence systems. Query-gated demonstration controls made the scenario reproducible; they are verification tools, not finished player-facing controls.

Death screen showing Mara slain by a Goblin, the Goblin promoted with stronger statistics, seventeen teeth scattered, Mara's dagger claimed, and a soul shrine created.
01 · Death changes the worldA Goblin kills Mara, grows stronger, takes her dagger, and leaves teeth and a soul shrine behind.
Iris standing beside a combined legacy marker identifying seventeen teeth and Mara's soul shrine on the persisted death tile.
02 · A successor finds the siteIris returns to the same Level 1 location and finds both of Mara’s consequences still there.
Mara's Shrine interaction panel showing twenty-two soul energy and blessing choices for Iris's equipment.
03 · The legacy is usableMara’s shrine holds soul energy that Iris can use to attempt to bless her equipment.
Inspection panel for the Goblin Slayer of Mara showing evolved statistics, Mara's dagger as its equipped trophy, and Mara in its kill history.
04 · The killer carries historyOn Level 2, Iris finds the evolved Goblin carrying Mara’s dagger with the kill recorded in its history.

Supporting technical verification

The local baseline is reproducible.

The latest local review compiled the TypeScript projects, completed the production build, passed 764 local tests, and completed the full Mara-to-Iris browser walkthrough. Supabase-connected behavior remains a separate opt-in suite and was not reverified because dedicated test credentials were unavailable. The next proof is whether players understand and value the loop without demonstration controls.

How the idea is being tested

Keep the horizon. Test one assumption at a time.

The project moves forward by turning the largest claim into a smaller question that can be built, observed, and challenged.

  1. 01 · HorizonPlaying should create lasting value that players can share in.
  2. 02 · HypothesisA character’s death can create meaningful content for future players.
  3. 03 · ExperimentPersist the killer, equipment, teeth, shrine, and death history across heroes.
  4. 04 · Current resultThe consequence system exists. A shared player economy has not been validated.
  5. 05 · Next questionDo players find what previous heroes leave behind meaningful enough to build upon?

My role and AI assistance

The idea and direction are mine. The implementation is collaborative.

I developed the original concept, including paid attempts, permanent death, evolving monsters, teeth as currency, and the belief that a player’s contribution should remain valuable after a character is gone.

I used Claude and Codex extensively to turn that direction into requirements, architecture, code, tests, and debugging work. My role has been to explain the system I want, decide what belongs in it, review what the tools produce, identify when the result does not match the idea, and keep narrowing the vision into something that can be tested.

The next part of owning this project is not hiding that process. It is improving my understanding of the implementation, testing the visible behavior, and being able to explain why the system works the way it does.

What comes next

Turn a promising prototype into a game where playing creates value that lasts.

The goal is not only to let players shape the world. It is to make the time, attention, and decisions they contribute matter beyond a single play session. A player’s actions could leave behind monsters, shrines, equipment, currency, and stories that other players can discover, use, trade, or build upon. The larger question is whether players can share in the value they help create instead of that value belonging entirely to the game or the company operating it.

The most important result so far is not that the full vision is finished. It is that the central idea now exists as a system that can be played, inspected, criticized, and improved.

Play the live demo Explore the repository Return to selected work