Lua vs LPC vs Python
MUD scripting splits between client-side automation (capturing output and sending commands) and server-side extension (modifying game logic and persistence). Client scripts offer immediate player customization but lack server state visibility, while server-side languages provide complete control at the cost of architectural complexity and maintenance burden. This comparison evaluates four primary approaches across implementation effort, lock-in risk, and operational reliability.
Mudlet Lua
Rich client automation with Lua 5.1 and integrated GUI framework
Best for: Players requiring complex client-side automation with visual feedback elements like gauges and maps
LPC
Server-side C-variant with object inheritance for LP MUD architectures
Best for: Developers maintaining or extending legacy LP MUD codebases with persistent object requirements
Python (Evennia)
Modern Python framework leveraging Django ORM for MUD development
Best for: Teams building new MUDs requiring contemporary testing practices and database flexibility
TinTin++
Lightweight terminal client with regex-based action scripting
Best for: Minimalist users needing basic automation across multiple MUDs without client commitment
| Criterion | Mudlet Lua | LPC | Python (Evennia) | TinTin++ | Winner |
|---|---|---|---|---|---|
Initial Learning Curve Time required to write functional scripts excluding domain-specific game knowledge | Low to moderate - Lua syntax is minimal, but Mudlet API requires studying event system and GUI objects | High - Requires understanding C syntax, MUD inheritance chains, and driver-specific security mechanisms | Low - Standard Python syntax with extensive external tutorials and IDE support | Very low - Simple #action and #alias syntax with minimal programming constructs | TinTin++ |
Debugging Tooling Availability of breakpoints, stack traces, and variable inspection during development | Built-in error console, variable inspector, and access to Lua debug library | Driver-dependent; often limited to compile-time errors and runtime tracebacks | Full pdb integration, IDE breakpoints, and Django error reporting | Basic logging and #echo commands; no breakpoint or stepping capability | Python (Evennia) |
Cross-Platform Support Operating system compatibility for development and deployment | Windows, macOS, and Linux binaries maintained with consistent API | Server-side; requires Unix-like environment matching specific driver compilation | Any platform supporting Python 3.x; container deployment available | Primary Unix support; Windows requires Cygwin or WSL with reduced performance | Mudlet Lua |
Game State Access Depth of visibility into internal game variables and object states | Limited to parsed text output and locally stored variables; no server introspection | Complete access to object properties, database queries, and internal game state | Full database and object manipulation through Django ORM | Text parsing only; relies on server output formatting for state inference | LPC |
Persistence Model Mechanisms for saving and restoring script state across sessions | Profile-local XML storage; requires explicit save calls and manual data migration | Automatic object persistence via driver save/restore with incremental backups | Database persistence through Django models with migration support | Static configuration files; session variables lost on disconnect | Python (Evennia) |
Code Sharing Mechanisms Methods for distributing scripts to other players or developers | XML package export with dependency management through Mudlet forums or GitHub | Inheritance-based code libraries requiring compatible driver and domain knowledge | Standard pip packages and GitHub integration with requirements.txt | Plain text configuration files distributed through paste services | Python (Evennia) |
Maintenance Burden Effort required to keep scripts functional across updates | Moderate - API updates may deprecate functions; requires testing against new client versions | High - Driver updates require code review; legacy inheritance chains complicate refactoring | Low - Semantic versioning and standard testing frameworks reduce regression risk | Very low - Simple text configurations rarely break between versions | TinTin++ |
Performance Characteristics Runtime resource usage and latency impact | Client-side only; minimal CPU impact except during heavy GUI updates | Server CPU bound; efficient for game logic but subject to driver evaluation limits | Interpreted overhead mitigated by modern hardware; async support for I/O operations | Negligible resource usage; pattern matching optimized in C | TinTin++ |
Vendor Lock-in Risk Difficulty of migrating scripts to alternative platforms | Medium - Deep integration with Mudlet-specific events and GUI objects | High - Tightly coupled to specific LP driver implementations and mudlib structures | Low - Standard Python with possible framework abstraction | Very low - Portable regex and simple commands transfer to any terminal client | TinTin++ |
Documentation Availability Quality and completeness of reference materials | Extensive wiki with searchable function database and active Discord community | Fragmented across driver variants; historical manuals often outdated or driver-specific | Comprehensive ReadTheDocs with auto-generated API references | Complete manual pages and built-in #help system with version consistency | Python (Evennia) |
Our Verdict
Mudlet Lua offers the best balance for player automation requiring GUI elements, while Python suits new server development with modern practices. LPC remains necessary for legacy LP MUD maintenance but imposes significant architectural constraints and maintenance overhead. TinTin++ serves minimal automation needs without commitment but lacks capabilities for complex systems.
Use-Case Recommendations
Scenario: Building a complex combat system with health bars, maps, and timers
→ Mudlet Lua
Client-side GUI framework allows visual feedback and automation without requiring server modification or affecting other players
Scenario: Creating persistent NPCs with complex behavior trees and state machines
→ Python (Evennia)
Server-side persistence and modern object-oriented patterns support complex AI state management with proper version control
Scenario: Maintaining a legacy LP MUD with 1990s codebase and established player base
→ LPC
Existing inheritance structures and driver-specific optimizations require LPC compatibility; migration cost exceeds benefit
Scenario: Quick multi-MUD aliases for basic command shortening and simple triggers
→ TinTin++
Minimal setup and portable text configurations work across any MUD without client lock-in or learning curve
Scenario: Prototyping new game mechanics before client implementation
→ Python (Evennia)
Rapid iteration with standard testing frameworks allows validation before committing to permanent architecture
.