Jared Miller
25bb565091
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.
32 lines
1.3 KiB
Text
32 lines
1.3 KiB
Text
why telnet first
|
|
================
|
|
|
|
from the dreambook: "we honor telnet. the protocol is the interface."
|
|
|
|
telnet is the native interface. a person with a terminal emulator gets the full
|
|
experience. no browser, no client download. `telnet mud.example.com 6789` and
|
|
you're in.
|
|
|
|
telnetlib3 gives us:
|
|
- NAWS (terminal dimensions — adapt viewport to window size)
|
|
- TTYPE/MTTS (client capability detection)
|
|
- GMCP/MSDP (structured data for rich clients like Mudlet)
|
|
- SGA (suppress go-ahead for modern line handling)
|
|
- async server with reader/writer streams
|
|
|
|
the MUD ecosystem has decades of protocol extensions built on telnet. we get
|
|
all of them for free by staying in the protocol.
|
|
|
|
a web client, when it comes, should just be a terminal emulator (xterm.js)
|
|
pointing at the telnet port. same protocol, different transport.
|
|
|
|
design consequences
|
|
-------------------
|
|
|
|
- all output is text + ANSI escape codes. no binary formats.
|
|
- line endings are \r\n (telnet NVT standard)
|
|
- input is line-based (readline). no raw keystroke handling (yet)
|
|
- server-side echo is complicated — MUD clients handle their own echo
|
|
(see docs/lessons/charset-vs-mtts.txt for the will_echo story)
|
|
- NAWS tells us the terminal size. viewport adapts. small terminal = smaller
|
|
map view. this is a feature, not a limitation.
|