python mudlib using telnetlib3
Jared Miller
c52e59c5d4
The Quetzal spec stores the PC pointing at the save instruction's branch data. On restore, this branch must be processed as "save succeeded" to advance the PC to the actual next instruction. Without this, the branch bytes were decoded as an opcode, corrupting execution. Detect the save opcode (0xB5) immediately before the restored PC to distinguish in-game saves from out-of-band saves (which don't need branch processing). Also improve error diagnostics: pop_stack now raises ZStackPopError with frame context, and the instruction trace dumps on all exceptions. |
||
|---|---|---|
| .claude | ||
| content | ||
| docs | ||
| scripts | ||
| src/mudlib | ||
| tests | ||
| worlds/earth | ||
| .dockerignore | ||
| .gitignore | ||
| compose.yml | ||
| demo_terrain.py | ||
| Dockerfile | ||
| DREAMBOOK.md | ||
| justfile | ||
| mud.tin | ||
| pyproject.toml | ||
| README.md | ||
| uv.lock | ||
mudlib
A telnet MUD engine. No client needed — just telnet and you're in.
Built on telnetlib3, Python 3.12+, managed with uv.
Quickstart
uv sync
just run
Then connect: telnet localhost 6789
Commands
just check # lint + typecheck + test
just run # start the server
just debug # start with debug logging
just render # generate world map HTML
What's in here
src/mudlib/— the engine (commands, world, combat, rendering, storage)tests/— pytest testsworlds/— world definitions (yaml/toml)docs/— internal knowledge baseDREAMBOOK.md— vision and wild ideas
How it works
The world is a toroidal 2D grid of terrain tiles, not discrete rooms. Players see a viewport centered on their position. Terrain types have mechanics — shallow water slows you, mountains block you, forests hide you.
Combat is timing-based with telegraphed moves and cooldown management, not turn-based.
The server runs a tick-based async game loop alongside the telnet server. SQLite handles persistence. Session mode stacks filter what reaches the player depending on context (exploring, fighting, composing, solving puzzles).