mud/.claude/CLAUDE.md
Jared Miller 25bb565091
Move notes to docs/how, docs/why, docs/lessons
how/  - how things work (terrain generation, command system)
why/  - design philosophy (telnet-first, text worlds)
lessons/ - things we learned the hard way (charset vs mtts)

Removes notes/ — DAYDREAMING.txt became DREAMBOOK.md, charset-vs-mtts
expanded into docs/lessons/ with the connect_maxwait fix documented.
2026-02-07 13:31:02 -05:00

2 KiB

mudlib

Telnet MUD engine built on telnetlib3. Python 3.12+, managed with uv.

Commands

  • just check - lint (ruff --fix + format), typecheck (pyright), test (pytest)
  • just lint / just typecheck / just test - individual steps
  • just run - start the server (python -m mudlib)
  • just debug - start with debug logging

Project Layout

  • src/mudlib/ - the engine (commands, world, combat, render, store)
  • tests/ - pytest tests
  • worlds/ - world definition files (yaml/toml, version controlled)
  • docs/ - project knowledge (see below)
  • DREAMBOOK.md - the vision, philosophy, wild ideas. not a spec
  • repos/ - symlinked reference repos (telnetlib3, miniboa). gitignored, not our code

Docs

Three categories in docs/. Plain text, not markdown.

  • docs/how/ - how things work. write one when you build something non-obvious. terrain generation, command system, etc. aimed at someone reading the code who wants the "why did we do it this way" context.
  • docs/why/ - design philosophy. telnet-first, text worlds, etc. the reasoning behind big decisions. doesn't change often.
  • docs/lessons/ - things we learned the hard way. write one when you hit a real bug or gotcha that cost time. charset-vs-mtts, etc. include the fix so we don't repeat it.

Update docs when:

  • you build a new system (add a how/)
  • you make a design decision worth explaining (add a why/)
  • you debug something painful (add a lessons/)
  • existing docs become wrong (update them)

Architecture

  • telnetlib3 is a dependency, not vendored. contribute fixes upstream
  • telnetlib3 gives us: GMCP, MSDP, NAWS, async server, reader/writer streams
  • game loop is tick-based (async task alongside telnet server)
  • world definitions live in data files, runtime state lives in memory
  • SQLite for persistence (player accounts, progress)
  • session mode stack filters what events reach the player (normal/combat/editor)

Style

  • simple > clever
  • no mock implementations
  • match existing patterns in each file