Add mudlib documents
This commit is contained in:
parent
9948a36f5f
commit
1223eebeb1
GPG key ID:
22B5C6D66A38B06C
2 changed files with 1033 additions and 0 deletions
441
docs/how/mud-ecosystem.txt
Normal file
441
docs/how/mud-ecosystem.txt
Normal file
|
|
@ -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/
|
||||
592
docs/how/mudlib-landscape.txt
Normal file
592
docs/how/mudlib-landscape.txt
Normal file
|
|
@ -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.
|
||||
Loading…
Reference in a new issue