An Appeal to the Dev Community

Morgue files are the richest record of a DCSS game, but they're plain text formatted for human reading. The format has changed across versions with no schema, making reliable parsing a nightmare. I built a parser for this project and it is of medium quality at best — years of format drift mean edge cases are everywhere.

If the game emitted a JSON (or even XML) morgue alongside the text one, every downstream tool — stats sites, analytics dashboards, personal trackers — would get reliable data for free. The text morgue stays for people who love reading them; the structured version exists for machines.

XML might actually be interesting here: with an XSLT stylesheet bundled alongside, players could open a morgue file in their browser and get a nicely formatted, interactive view of their game without any server or app at all. Drop-in local morgue viewer, zero setup.

Impact: Every tool that consumes morgue data becomes trivial to write. The data is already there inside the game at the point where the morgue is generated — it just needs to be serialized differently.

Today, game data lives on individual servers (CAO, CKO, CBR2, etc.) with different directory structures and access patterns. Projects like dcss-stats do the heroic work of crawling each server independently, but every new tool has to rediscover and re-implement this logic.

If there were a standardized API or feed — even something as simple as an aggregated listing endpoint or a shared event stream — tools could subscribe to game completions across all servers without custom crawling per-server. The data format from Proposal 1 would make each entry immediately useful.

This would mean that a project like mine could immediately work with every game ever played, not just the subset I've managed to download. The kind of analysis this enables is meaningful: “What equipment is most common in games where the player dies in Vaults versus when they make it through?” That question is answerable today in theory, but practically impossible without spending weeks on data collection.

Impact: Lowers the barrier for new DCSS tools from “months of scraping” to “point at an API.” Good for the ecosystem, good for players who want richer tools.

This one is more ambitious and isn't immediately related to data access, but it's about what becomes possible once we think of games as replayable artifacts.

StarCraft 2 replays work by recording the random seed, game version, and every player input. The replay file is tiny because it's just a list of commands — the game engine deterministically reproduces the full state. Players can jump to any moment in a match.

DCSS could do the same: record the RNG seed, version, and every keystroke. A replay file would be small (a few KB per game) and would let anyone:

• Watch any game in webtiles without needing the original ttyrec
• Jump to any turn instead of fast-forwarding through hours of play
• Share “puzzle” moments — “Can you survive this situation?” — where others load in at a specific turn and try to play it out
• Analyze decision points from the game state itself, not from a text summary after the fact

These replay games obviously wouldn't count for server points. This is purely about making games into a reusable, shareable resource.

Impact: Turns every game of DCSS into a permanent, interactive artifact. Transforms the community's relationship with game history from “read a text dump” to “step into the game.”