From 1223eebeb178a604a87aad306f9f7545efe9c3be Mon Sep 17 00:00:00 2001 From: Jared Miller Date: Sat, 7 Feb 2026 15:21:48 -0500 Subject: [PATCH] Add mudlib documents --- docs/how/mud-ecosystem.txt | 441 +++++++++++++++++++++++++ docs/how/mudlib-landscape.txt | 592 ++++++++++++++++++++++++++++++++++ 2 files changed, 1033 insertions(+) create mode 100644 docs/how/mud-ecosystem.txt create mode 100644 docs/how/mudlib-landscape.txt diff --git a/docs/how/mud-ecosystem.txt b/docs/how/mud-ecosystem.txt new file mode 100644 index 0000000..2c007ea --- /dev/null +++ b/docs/how/mud-ecosystem.txt @@ -0,0 +1,441 @@ +mud ecosystem reference + +a catalog of engines, clients, protocols, and communities in the MUD world. +companion to mudlib-landscape.txt (which covers architecture patterns). + + +-------------------------------------------------------------------------------- +engines and codebases +-------------------------------------------------------------------------------- + +python: + - evennia + https://github.com/evennia/evennia + python/django/twisted. THE python MUD framework. 1994 stars + + - ainneve + https://github.com/evennia/ainneve + example RPG built on evennia + + - arxcode + https://github.com/Arx-Game/arxcode + production game on evennia + + - mud-pi + https://github.com/Frimkron/mud-pi + simple teaching MUD server + + - sorrows + https://github.com/rmtew/sorrows-mudlib + stackless python MUD + + - talismud + https://github.com/vincent-lg/talismud + async modern python + + - taleweave-ai + https://github.com/ssube/taleweave-ai + AI NPCs via LLMs + + - DUM + https://github.com/wowpin/dumserver + modern python MU* engine + + - Tale + https://github.com/irmen/Tale + MUD/IF framework + +dikumud family (C/C++): + - dikumud original + https://github.com/Seifert69/DikuMUD + 1990, the ancestor + + - dikumud3 + https://github.com/Seifert69/DikuMUD3 + modern evolution, HTML/websockets + + - tbamud + https://github.com/tbamud/tbamud + continued circlemud. most used diku derivative + + - anatoliamud + https://github.com/jaromil/anatoliamud + diku > merc > rom lineage + + - empiremud + https://github.com/EmpireMUD/EmpireMUD-2.0-Beta + persistent world map + + - awakemud + https://github.com/luciensadi/AwakeMUD + community fork + +lpc drivers: + - fluffos + https://github.com/fluffos/fluffos + active, mudos fork, C++ + + - ldmud + https://github.com/ldmud/ldmud + C, long history + + - dgd + https://github.com/dworkin/dgd + independent implementation + + - cd mud + https://github.com/cotillion/cd-gamedriver + alternative driver + + - mudos + https://github.com/maldorne/mudos + historical fork + +lpc mudlibs: + - dead souls + https://github.com/quixadhal/deadsouls + beginner-friendly, batteries-included + + - lima + https://github.com/limalib/lima + clean modern + + - morgengrauen + https://github.com/MorgenGrauen/mg-mudlib + oldest german lpmud (1992) + + - cdlib/genesis + https://github.com/genesismud/mudlib + historically influential + + - nightmare-residuum + https://github.com/michaelprograms/nightmare-residuum + active development + + - discworld + https://github.com/Yuffster/discworld_distribution_mudlib + terry pratchett themed + + - realms-mud + https://github.com/realms-mud/core-lib + rich combat/crafting. 75 stars + + - oxidus + https://github.com/gesslar/oxidus-mudlib + modern fluffos mudlib + + - hexagon + https://github.com/maldorne/hexagon + mudos-alike on dgd + +moo/mush: + - toaststunt + https://github.com/lisdude/toaststunt + enhanced lambdamoo. most active fork + + - stunt + https://github.com/toddsundsted/stunt + lambdamoo with maps, REST + + - room.js + https://github.com/doughsay/room.js + node.js moo server + + - hellcore + https://github.com/necanthrope/HellCore + lambdamoo fork + + - fuzzball + https://github.com/fuzzball-muck/fuzzball + tinymuck server + +node.js: + - ranvier + https://github.com/RanvierMUD/ranviermud + modular, data-driven. 829 stars + + - rockmud + https://github.com/MoreOutput/RockMUD + websocket MUD. 155 stars + +elixir: + - exventure + https://github.com/oestrich/ex_venture + MMORPG engine. 665 stars + + - kalevala + https://github.com/oestrich/kalevala + world-building toolkit. 191 stars + + - fluxspace + https://github.com/mainframecity/fluxspace + WIP elixir MUD + +go: + - gomud + https://github.com/GoMudEngine/GoMud + clean, fast. 205 stars + + - dragon-mud + https://github.com/bbuck/dragon-mud + go + lua. 123 stars + +java: + - coffeemud + https://github.com/bozimmerman/CoffeeMud + most feature-complete. 217 stars + +C#: + - archaicquest + https://github.com/ArchaicQuest/ArchaicQuest-II + web-playable. 148 stars + +rust: + - ataxia + https://github.com/xenith-studios/ataxia + rust + lua scripting. 70 stars + +haskell: + - currymud + https://github.com/jasonstolaruk/CurryMUD + pure functional. 78 stars + +archives: + - dikumud omnibus + https://github.com/DikuMUDOmnibus + 100+ diku projects + + - mud historical society + https://github.com/mudhistoricalsociety + preservation + + +-------------------------------------------------------------------------------- +protocols reference +-------------------------------------------------------------------------------- + +tier 1 - essential for any mud: + + telnet (RFC 854, 855) + the base protocol + + NAWS (RFC 1073) + window size negotiation + + GMCP + JSON over telnet for structured data. the modern standard + https://tintin.mudhalla.net/protocols/gmcp/ + + MTTS + terminal type/capabilities + https://tintin.mudhalla.net/protocols/mtts/ + +tier 2 - widely supported, add when needed: + + MSDP + structured data protocol (alternative to gmcp) + https://tintin.mudhalla.net/protocols/msdp/ + + MCCP2/3 + compression + https://tintin.mudhalla.net/protocols/mccp/ + + MSSP + server status for crawlers/listings + https://tintin.mudhalla.net/protocols/mssp/ + + MNES + environment standard, supplements mtts + https://tintin.mudhalla.net/protocols/mnes/ + +tier 3 - specialized: + + MXP + enhanced text markup (zuggsoft) + https://www.zuggsoft.com/zmud/mxp.htm + + MSP + sound (zuggsoft) + https://www.zuggsoft.com/zmud/msp.htm + + MCMP + sound via gmcp (mudlet) + https://wiki.mudlet.org/w/Standards:MUD_Client_Media_Protocol + + MCP + moo client protocol + http://www.moo.mud.org/mcp/index.html + + MSLP + clickable links + https://tintin.mudhalla.net/protocols/mslp/ + + MMCP + p2p chat protocol + +our telnetlib3 handles: GMCP, MSDP, NAWS, CHARSET, MTTS + + +-------------------------------------------------------------------------------- +clients +-------------------------------------------------------------------------------- + +desktop: + + mudlet + linux/mac/windows + gmcp, mssp, mcmp, msp, atcp, msdp, mxp, mmp + lua scripting. the dominant modern client + https://www.mudlet.org/ + + tintin++ + all platforms + android/ios + gmcp, mccp, mccp3, msdp, mslp, mssp, mtts, mmcp, naws, mnes + terminal-based + https://tintin.mudhalla.net/ + + blightmud + linux/mac + tls, gmcp, msdp, mccp2 + terminal-based, rust + https://github.com/LiquidityC/Blightmud + + mushclient + windows + mxp, mccp, mmcp, mtts + http://www.gammon.com.au/mushclient/ + + cmud + windows + mxp, msp, mcp, mccp, atcp + commercial + http://www.zuggsoft.com/ + + axmud + linux/windows + mxp, gmcp, msdp, mnes, mtts + perl/gtk3 + https://axmud.sourceforge.io/ + + kildclient + linux/windows + ssl, mccp, mmcp, zchat + https://www.kildclient.org + + beipmu + windows + tls, mcmp + https://beipdev.github.io/BeipMU/ + +mobile: + + blowtorch + android + mccp + + mudrammer + ios + https://github.com/splinesoft/MUDRammer + +web: + + mudportal + mccp, mxp, msdp, gmcp, atcp, mtts + proxy + web client + https://github.com/plamzi/MUDPortal-Web-App + + grapevine + mud listing with web client + https://grapevine.haus/ + + mudslinger + proxy + web client. mxp + https://github.com/ryanberckmans/mudslinger + + +-------------------------------------------------------------------------------- +community and resources +-------------------------------------------------------------------------------- + +active communities: + + mud coders guild + slack community for text game devs + https://mudcoders.com + + r/MUD + reddit + https://www.reddit.com/r/MUD + + the MUD discord + https://discord.gg/zuz4D8s + + mud bytes + forum and file archives + http://www.mudbytes.net/ + +listings: + + grapevine + https://grapevine.haus/ + + game scry + https://game-scry.online/ + + mudverse + https://www.mudverse.com + + mud connector + http://www.mudconnect.com/ + +documentation: + + mudhalla + protocols docs, tintin home + https://mudhalla.net/ + + mudlet wiki + protocol and scripting docs + https://wiki.mudlet.org/ + + mud standards + https://mudstandards.org/ + + mudvault protocols + https://mudvault.org/protocols + +awesome lists: + + awesome-mud + https://github.com/mudcoders/awesome-mud + + awesome-muds + https://github.com/maldorne/awesome-muds + +history: + + wikipedia MUD chronology + https://en.wikipedia.org/wiki/Chronology_of_MUDs + + raph koster's timeline + https://www.raphkoster.com/gaming/mudtimeline.shtml + + richard bartle's MUD1 incarnations + https://mud.co.uk/richard/incarns.htm + + 50 years of text games + https://if50.substack.com/ + +academic: + + "players who suit muds" + richard bartle, 1996. player types + https://mud.co.uk/richard/hcds.htm + + "designing virtual worlds" + richard bartle + https://mud.co.uk/dvw/ + + titans of text podcast + 33 episodes + https://www.titansoftext.com/ diff --git a/docs/how/mudlib-landscape.txt b/docs/how/mudlib-landscape.txt new file mode 100644 index 0000000..a5b7ab5 --- /dev/null +++ b/docs/how/mudlib-landscape.txt @@ -0,0 +1,592 @@ +mudlib landscape - research into the MUD engine ecosystem + +this document synthesizes research into existing MUD engines, their architectures, +and their design decisions. useful reference when designing our own mudlib. + + +━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ +SECTION 1: the mud family tree +━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ + +dikumud (1990) +-------------- +the combat MUD ancestor. C, room-based, zone files, tick-based. + +spawned the entire diku family: merc, rom, circle/tbamud, smaug. + +binary/text zone files define the world. NPCs are templates that get instantiated +via "resets". main loop is tick-based (1/4 second typical). zones have 6 sections: +zone declaration, mobiles, objects, rooms, resets, DIL scripts. + +major descendants: + - merc 2.0 was a total rewrite improving code quality, dropping binary formats + - circlemud stayed closer to original diku, cleaner but fewer features + - smaug was the biggest architectural divergence - reintroduced complexity merc + stripped out + - tbamud is the modern circle continuation + + +lpc/lpmud (1989) +---------------- +the big innovation: driver + mudlib separation. + +driver is a VM for the LPC language. mudlib is the game framework written in LPC. +this means game logic is hot-reloadable interpreted code while the engine is +compiled C/C++. + +drivers: + - fluffos (active, mudos fork, C++) + - ldmud (C, long history) + - dgd (independent implementation) + +mudlibs: + - dead souls (beginner-friendly, batteries-included) + - lima (clean modern) + - discworld (the famous one) + - morgengrauen (oldest german lpmud, since 1992) + - realms-mud (rich combat/crafting) + - cdlib/genesis (historically influential) + +LPC is C-like, OOP. blueprint objects serve as templates, clones are instances. +objects inherit from parents forming hierarchies. code lives in .c files compiled +by the driver at runtime. + +in-world programming: builders write LPC code that gets compiled by the driver +without restart. this is the core appeal of lpc muds. + + +moo/lambdamoo +------------- +everything-is-an-object. the entire world is a persistent object database. + +objects have properties (data) and verbs (methods/commands). verbs are the core +interaction - "put ball in box" parses into a verb call with direct object, +preposition, indirect object. + +in-world programming via @program command - attach MOO code to object verbs. + +persistence: entire DB in RAM, periodic checkpoints to disk. + +fork statement creates background tasks for async work. + +modern forks: + - toaststunt: multiple inheritance, HTTP, JSON, threading for sqlite/sort/etc + - stunt: adds map datatype, RESTful interface + + +mush/mux (tinymud family) +------------------------- +objects with attributes (key-value), flags (booleans), locks (permission +expressions). + +two kinds of code: + - hardcoded (C, needs restart) + - softcoded (mushcode, stored in attributes, hot-reloadable) + +three parsers: command parser, function parser, locks parser. + +building with @dig, @create, @link. + + +modern engines +-------------- + +evennia (python/twisted/django) + see section 2 for deep dive. most framework-like of modern engines. + +ranvier (node.js) + bundle system where nearly everything is modular. bundles package commands, + areas, items, NPCs, channels, behaviors. network layer is swappable. + unopinionated core. + +exventure (elixir) + uses erlang/otp process model. kalevala framework underneath. web client, + telnet, clustering, prometheus metrics, cross-game gossip chat. + +coffeemud (java) + most feature-complete MUD codebase. supports everything: MSP, MXP, GMCP, OLC, + built-in web+mail server. d20-style combat with extensive modifier system. + +compiled engine + scripted logic pattern: + - gomud (go) + - dragon-mud (go+lua) + - ataxia (rust+lua) + +taleweave-ai (python) + AI NPCs via LLMs, discord integration, stable diffusion visuals. + + +━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ +SECTION 2: evennia deep dive +━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ + +most relevant reference since we're also python. + + +architecture +------------ +dual-process: portal (networking) + server (game logic), communicate via AMP +protocol. + +portal handles all protocols: telnet, SSH, SSL, websocket, IRC, discord, grapevine. + +server runs game logic, django ORM for persistence. + +twisted-based async, event-driven (not tick-based by default). + +scripts use ExtendedLoopingCall for timed tasks (tickers). + + +object model +------------ +TypedObject base -> ObjectDB (django model) -> typeclasses (DefaultObject, +DefaultRoom, DefaultCharacter, DefaultExit) + +rooms are objects with location=None. + +exits are objects with db_destination. they dynamically create CmdExit commands. +typing "north" runs the exit's command which checks locks and traverses. + +contents cached via ContentsHandler. + +attributes: arbitrary pickled data via obj.db.attrname, stored in DB. + +tags: lightweight string labels with categories, fast for filtering. + +locks: function-based access control strings like "cmd:perm(Builder) AND +attr(canEdit)". + + +command system +-------------- +commands define: key, aliases, locks, arg_regex, parse(), func(). + +processing pipeline: + gather cmdsets from session/account/character/room/exits + -> merge + -> match + -> execute: at_pre_cmd -> parse -> func -> at_post_cmd + +cmdset merging uses set theory operations with priorities: + - union (default) + - intersect + - replace + - remove + +priorities: exits=10, account=0, room objects=lower. + +this is how game states work: push a "fishing" cmdset that overrides "throw", +pop it when done fishing. push "dark room" cmdset that replaces default commands. +stack them. + +this is genuinely novel - set-theoretic operations on command availability. + + +session handling +---------------- +portal creates PortalSession per connection. + +server creates ServerSession, links to Account and Character. + +MULTISESSION_MODE: + 0 = exclusive + 1 = multiple chars + 2 = multiple sessions per char + 3 = full multi + + +building +-------- +@create, @dig, @link, @open, @desc, @set, @tag, @lock, @typeclass, @spawn + +no in-game python execution in base evennia. + +prototypes: dict-based object templates with inheritance via prototype_parent. + +spawn system creates objects from prototypes. + + +persistence +----------- +django ORM with any supported DB (sqlite default, postgres for production). + + +what's unique about evennia +---------------------------- +- cmdset merging system is genuinely novel +- typeclass system lets you change object behavior by swapping its class at + runtime +- multi-protocol portal means same game is playable via telnet, web, ssh + simultaneously +- django integration means you get admin panel, REST API, web views for free +- most "framework-like" of all MUD engines - it's a toolkit, not a game + + +━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ +SECTION 3: how they all solve the same problems +━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ + + +world representation +-------------------- + +room graph (most common) + rooms as nodes, exits as edges, directed graph. diku, lpc, evennia, ranvier + all use this. + + advantage: clear sight lines (same room = visible) + disadvantage: no consistent coordinate system + +grid-based + n*m orthogonal grid, each cell ~8 neighbors. used for wilderness areas in some + lpc muds. consistent scale but less flexible. + +continuous/coordinate + entities at exact 2D/3D coordinates, descriptions generated from proximity. + modern trend. + + advantages: seamless movement, true spatial relationships + challenge: rendering continuous space as text + +OUR APPROACH (from dreambook) + 2D toroidal tile grid with terrain types. viewport centered on player. hybrid - + overworld is grid, interiors can be rooms. this is relatively uncommon in the + MUD world. + + +command parsing +--------------- +all MUDs: text in -> parse command name -> extract arguments -> dispatch to +handler -> execute -> text out + +simple + split on first space, command + args string + +complex (moo) + parse verb + direct object + preposition + indirect object + +mush + three separate parsers for commands, functions, and locks + +evennia + fuzzy matching against merged cmdset, disambiguation for ambiguous matches + +ranvier + modular command definitions in bundles + + +persistence +----------- + +flat files + diku zone files, moo database dumps. human-readable, version-controllable. + +ORM/SQL + evennia (django), some modern engines. structured, queryable, scalable. + +in-memory + checkpoint + moo model. fast but needs enough RAM. + +sqlite + good for embedded single-server muds. ACID compliant, single file. + +OUR APPROACH + world definitions in yaml/toml files (version controlled), runtime state in + memory, player data in sqlite. + + +game loop +--------- + +tick-based (diku) + fixed interval (1/4 sec), process all queues each tick. synchronous progression. + simple, deterministic. + +event-driven (evennia, ranvier, exventure) + no central loop, react to events. tickers optional for periodic tasks. better + for async, scales with concurrency. + +turn-based + advance only on player input. good for single-player IF, awkward for multiplayer. + +OUR APPROACH (from dreambook) + tick-based (10 ticks/sec), drain input queues each tick. timing-based combat + needs a real clock. + + +combat +------ + +diku-style + automatic attacks on timer ("pulse_violence" ~3 sec), player can enter special + moves. hit/miss/damage calculated from stats, armor, weapon, random rolls. + +no built-in combat + most frameworks (evennia, ranvier) provide none - you build it. + +coffeemud + most complete combat system. d20-style with extensive modifier system. + +OUR APPROACH (from dreambook) + timing-based with telegraph/response windows. PL as health AND damage multiplier. + stamina as action economy. diminishing returns on grinding. + + +communication +------------- +universal pattern: channels with audience types. + + say (room) + tell (private) + yell (area) + chat (global) + emote (room action) + +ranvier's architecture: channel = name + audience type + formatter functions. + +inter-mud: gossip protocol, IMC2, I3. + + +in-world creation/coding +------------------------ + +lpc + write LPC code, driver compiles it live. most powerful but requires learning + a language. + +moo + @program attaches code to object verbs. everything modifiable from inside. + +mush + softcode in attributes. simpler language than lpc/moo but capable. + +evennia + no in-game coding. prototypes and building commands only. spawn system for + templates. + +ranvier + bundles written externally, loaded on startup. + +OUR APPROACH (from dreambook) + world-building DSL for puzzles/triggers/state machines, writable in in-MUD + editor. NOT a full programming language but powerful enough for IF-style + content. + + +━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ +SECTION 4: protocols +━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ + +telnet is the base. extensions negotiate via telnet option subnegotiation. + + +essential +--------- + +NAWS (RFC 1073) + terminal window size. critical for viewport sizing. + +GMCP + generic mud communication protocol. JSON over telnet. the modern standard for + structured data (hp bars, inventory, room info). + +MSDP + mud server data protocol. typeless variables, arrays, tables. alternative to + gmcp. + +MCCP2/3 + compression. zlib over telnet. + + +useful +------ + +MTTS + terminal type standard. client capabilities negotiation. + +MNES + new environment standard. supplements mtts. + +MSSP + server status protocol. for MUD crawlers/listings. + +MSLP + clickable links in terminal. + + +content +------- + +MXP + markup for enhanced text (zuggsoft). + +MSP + sound protocol (zuggsoft). + +MCMP + modernized sound via gmcp (mudlet). + +MCP + moo client protocol. + + +our telnetlib3 already handles +------------------------------- +GMCP, MSDP, NAWS, CHARSET, MTTS + + +━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ +SECTION 5: clients and what they support +━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ + + +top clients by protocol support +-------------------------------- + +mudlet + gmcp, mssp, mcmp, msp, atcp, msdp, mxp, mmp. lua scripting. the dominant + modern client. + +tintin++ + gmcp, mccp, mccp3, msdp, mslp, mssp, mtts, mmcp, naws, mnes. terminal-based. + +blightmud + tls, gmcp, msdp, mccp2. terminal-based, rust. + +mushclient + mxp, mccp, mmcp, mtts. windows only. + +cmud + mxp, msp, mcp, mccp, atcp. commercial, windows. + +axmud + mxp, gmcp, msdp, mnes, mtts. perl/gtk3. + + +web clients +----------- + +mudportal + mccp, mxp, msdp, gmcp, atcp, mtts. proxy + web client. + +grapevine + mud listing with web client. + +xterm.js approach + terminal emulator in browser pointing at telnet (our dreambook mentions this). + + +━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ +SECTION 6: what's missing from our INDEX.txt +━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ + +repos worth adding for study: + + https://github.com/dworkin/dgd + DGD driver - independent LPC driver, not derived from lpmud + + https://github.com/EmpireMUD/EmpireMUD-2.0-Beta + EmpireMUD - persistent world map, circlemud derivative + + https://github.com/wowpin/dumserver + DUM/dumserver - modern python MU* engine + + https://github.com/irmen/Tale + Tale - python MUD/IF framework by irmen + + https://github.com/fuzzball-muck/fuzzball + Fuzzball MUCK - tinymuck server + + https://github.com/necanthrope/HellCore + HellCore - lambdamoo fork + + https://github.com/luciensadi/AwakeMUD + AwakeMUD - community fork, C++ + + https://github.com/mainframecity/fluxspace + fluxspace - elixir MUD engine + + https://github.com/maldorne/mudos + MudOS - historical fork + + https://github.com/cotillion/cd-gamedriver + CD MUD driver - alternative LPC driver + + https://github.com/DikuMUDOmnibus + DikuMUD Omnibus - 100+ diku-related projects + + https://github.com/mudhistoricalsociety + MUD Historical Society - preservation + + +━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ +SECTION 7: key takeaways for our design +━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ + +observations relevant to our mudlib: + + +1. driver/mudlib separation +---------------------------- +the driver/mudlib split (lpc model) is the most influential architectural +decision in MUD history. + +we get a version of this with python: the engine is the "driver", game +content/logic is the "mudlib". keeping this separation clean matters. + + +2. composable command sets +-------------------------- +command sets that compose (evennia's cmdset merging) are a genuinely good idea +for session modes. + +our mode stack (normal/combat/editor/IF) maps directly to pushing/popping +cmdsets. + + +3. room graphs vs grids +----------------------- +everyone uses room graphs. our tile grid is unusual. + +the dreambook's hybrid (grid overworld + room interiors) is the right call - it +gives us the spatial consistency of a grid with the narrative flexibility of +rooms. + + +4. in-world creation +-------------------- +in-world creation is the MOO dream. + +we don't need a full programming language, but the DSL for IF/puzzles needs to +be powerful enough that people can create real content from a telnet client. + + +5. persistence strategy +----------------------- +world in files + player state in sqlite is actually the cleanest approach. + +most modern engines do something similar. don't fight the pattern. + + +6. protocol investment +---------------------- +gmcp is the protocol to invest in. + +it's what mudlet and tintin++ both support well, and it's how we'll send +structured data (maps, gauges, inventory) to smart clients. + + +7. tick-based for combat +------------------------ +tick-based is right for timing-based combat. event-driven is cleaner for +everything else. + +hybrid is fine - main loop ticks, but non-combat systems can be event-driven. + + +8. prototype/spawn pattern +-------------------------- +the prototype/spawn pattern (evennia, diku zone resets) is how everyone handles +mob/item templates. + +define once, instantiate many.