A MUD library (mudlib) is the collection of code that defines a MUD’s world: its rooms, objects, NPCs, combat system, magic system, character classes, skills, and all the mechanics that make the world work. The mudlib is distinguished from the MUD driver (engine), which handles low-level operations: network connections, memory management, the interpreter or virtual machine, and basic object lifecycle.
This separation was pioneered by LPMud (1989), where the driver (LPMud driver, later MudOS, FluffOS) provides an LPC interpreter and basic object model, while the mudlib provides everything else. The innovation was architectural: the same driver can run completely different games by swapping mudlibs. This is the same separation that later appeared in game engines (Unity, Unreal) and web frameworks (Django, Rails) — the platform provides infrastructure; the application provides content and logic.
Major mudlib traditions include: 2.4.5 lib and its descendants (the original LPMud mudlib, heavily forked), Lima (a clean-room LPMud mudlib), Dead Souls (a comprehensive LPMud mudlib with extensive documentation), Nightmare (George Reese’s influential mudlib), and the various DikuMUD derivative codebases (CircleMUD, ROM, SMAUG), which did not cleanly separate driver from lib but were massively cloned and modified. MOO systems used a different model: the entire world was a single object database programmed in MOO code by users with sufficient permissions.
The mudlib is where world-building and programming converge: writing a mudlib is simultaneously designing a game world and engineering a software system. The quality of the mudlib determines not just the player experience but the builder experience — how easy it is for world creators to add rooms, objects, and mechanics without modifying the engine.