LPC vs FluffOS vs LDMud
Selecting an LP MUD driver determines your world's persistence model, scripting capabilities, and long-term maintenance burden. FluffOS offers modern MudOS compatibility with active development, LDMud provides strict LPC adherence with institutional stability, and DGD implements atomic persistence for continuous worlds. This comparison examines compilation requirements, live coding workflows, and mudlib compatibility to inform your driver selection based on technical constraints rather than historical popularity.
FluffOS
Modern MudOS fork with event-driven I/O and WebSocket support
Best for: Developers porting legacy MudOS mudlibs requiring modern protocol support
www.fluffos.info/ ↗LDMud
German-developed driver with strict LPC standards and conservative release cycles
Best for: Long-term institutional deployments requiring backward compatibility guarantees
www.ldmud.eu/ ↗DGD
Persistent object driver with atomic state management and swap-based memory
Best for: Continuous worlds requiring rebootless code updates and full state persistence
www.dworkin.nl/dgd/ ↗| Criterion | FluffOS | LDMud | DGD | Winner |
|---|---|---|---|---|
LPC Standard Compliance Adherence to original Lars Pensjö C syntax and MudOS extensions | High compatibility with MudOS 0.9x/1.0 syntax plus modern extensions | Strict LPC with proprietary extensions requiring conditional compilation | LPC-like syntax with significant deviations including atomic functions | LDMud |
Live Coding Workflow Ability to modify running objects without player disconnections or full reboots | Full update() support with destruct/reload cycles; objects lose state during replacement | Limited hot-swapping; inheritance changes require object reconstruction | Atomic updates preserve object state; functions reload without instance destruction | DGD |
Persistence Architecture Method for retaining world state across driver restarts | Explicit save_object/restore_object with snapshot-based serialization | Standard LP save format with external backup management required | Automatic persistent object state; survives reboots without explicit serialization | DGD |
Build System Complexity Dependency requirements and compilation difficulty from source | CMake-based build requiring libevent, OpenSSL, and C++17 compiler | Autotools/configure with minimal dependencies; builds on legacy systems | Single-directory makefile with no external dependencies beyond standard C library | DGD |
Available Mudlibs Pre-existing codebase foundations compatible with the driver | Nightmare IV, Lima, Dead Souls 2/3, Discworld (ported) | LD mudlib, MorgenGrauen custom libs, German-language documentation | Phantasmal, kernel library (minimal), requires significant custom development | FluffOS |
Network Protocol Support Built-in client communication standards beyond raw telnet | Native TLS, WebSocket, GMCP, MXP, ANSI color with fallback detection | Standard telnet with MCP support; extensions require LPC implementation | Basic telnet; all protocol handling must be coded in LPC layer | FluffOS |
Memory Management Garbage collection strategy and resource limit enforcement | Generational GC with configurable heap limits and runtime profiling | Reference counting with cycle detection; manual memory limit enforcement | Swap-based system persisting idle objects to disk automatically | FluffOS |
Concurrent User Performance Architecture for handling multiple simultaneous connections | Event-driven epoll/kqueue with non-blocking I/O | Process-per-connection or select-based with configurable polling | Single-threaded with tick-based scheduling and voluntary thread suspension | FluffOS |
Documentation Accessibility Availability of API references and implementation examples | Extensive wiki, GitHub issues, Discord community, auto-generated docs | German and English manuals, mailing list archives, stable but sparse | Academic papers, Dworkin's manual, small but deep technical community | FluffOS |
State Migration Path Ease of moving from other LP drivers or importing existing LPC code | Direct drop-in replacement for MudOS 1.0/2.0 with minor compatibility shims | Requires syntax auditing for LDMud-specific extensions and driver hooks | Fundamental architecture mismatch; requires complete rewrite to atomic model | FluffOS |
Our Verdict
FluffOS suits most new LP MUD development requiring modern protocols and active maintenance, while LDMud serves conservative deployments prioritizing stability over features. DGD occupies a specialized niche for persistent-world simulations where reboots are unacceptable, demanding significant architectural investment. Driver selection should prioritize your team's LPC expertise against protocol requirements and persistence needs.
Use-Case Recommendations
Scenario: Porting an existing MudOS 1.0 or Nightmare-based MUD to modern infrastructure
→ FluffOS
Maintains object compatibility while adding TLS and WebSocket support without rewriting LPC inheritance systems
Scenario: Operating a German-language MUD with 20+ year continuity requirements
→ LDMud
Conservative release cycle and strict backward compatibility prevent future breakage of legacy LPC codebases
Scenario: Building a persistent simulation world with no acceptable downtime window
→ DGD
Atomic persistence model eliminates save/reload cycles and allows continuous operation during code updates
Scenario: Rapid prototyping with existing Dead Souls mudlib for proof-of-concept
→ FluffOS
Dead Souls 3.6 runs unmodified on FluffOS with immediate access to WebSocket clients for browser-based testing
.