MUME Help
CONTRIBUTING
MUME Contributor Guidelines: Philosophy, Prioritization, and Process
Welcome to the MUME development community. As a project spanning over three decades, MUME is sustained entirely by volunteer effort. Because our development resources are finite, we rely on a structured, traditional hierarchy to maintain the stability, balance, and core identity of Middle-earth.This document pulls back the curtain on how decisions are made, how ideas are evaluated, and how you can effectively navigate our development process.
1. The Core Philosophy: "Old, Boring Software"
MUME is a highly mature, stable ecosystem. For our core player base, predictability is a critical feature given the high risk/reward nature of the game.- The Legacy Challenge: MUME's codebase is filled with interconnected, historic systems and decades-old Mudlle code. A change that appears trivial on the surface-- such as adjusting a single integer for retirement duration or tweaking an outdated shopkeeper-- frequently uncovers a mountain of technical debt.
- Hidden Interdependencies: Modifying these ancient systems requires intense whiteboarding to prevent catastrophic second- and third-order effects. A minor tweak can accidentally disrupt the newbie economy, break backwards compatibility, or corrupt character quest data.
- Stability Over Chaos: We deliberately avoid a "move fast and break things" methodology. Unchecked, rapid balance updates are devastating to casual playstyles. Forcing players to constantly face an unpredictable environment yields a frustrating gameplay experience.
2. The Prioritization Challenge: Ideas vs. Execution
We receive an incredible volume of feature pitches across Discord, the Idea Board, and direct messages. Sifting through this volume requires understanding how our resources are actually allocated.The Passion Gate
Ultimately, the features that get implemented are the ones our volunteer coders are passionate about. Because everyone is a volunteer donating their limited free time, forcing builders to work on tasks that do not interest them would cause them to burn out and leave.Why Good Ideas Get Deferred
An idea being turned down or met with silence does not mean it is bad. The organization simply cannot churn through them all. More often, it means:- The effort-to-reward ratio is out of balance: The code change requires overhauling a deeply complex legacy system for a relatively minor gameplay adjustment.
- Limited bandwidth: The core builders have massive, existing to-do lists to enable background infrastructure and major projects. Current efforts and projects take priority so as not to stall the greater game building process.
- "Not now" does not mean "never": Deferring an idea is a function of strict prioritization, not a dismissal of the idea's merit.
3. The Path to Contribution: The Purpose of the Barrier to Entry
A common friction point for new volunteers is the requirement to build a zone before gaining wider access to manipulate game mechanics. This structure is intentional and serves a practical purpose:- Access Control & Security: Our history has taught us to be fiercely protective of the game's stability and playerbase privacy. Access is incredibly tricky to manage, and unvetted access risks breaking a 30-year-old engine or violating incognito characters.
- Learning the Architecture: Building a zone teaches you exactly how MUME is constructed, how projects are run, and how code interacts with the game world.
- Team Integration: The process gives you the chance to interact with multiple people and learn how to ship updates. It allows the team to learn how well someone fits into the workflow before granting access to sensitive core systems.
4. How to Effectively Contribute
If you want to help maintain and grow MUME, the most effective path is to align your efforts with the realities of our development pipeline:- Engage in Low-Hanging Fruit: Small maintenance tasks like updating outdated helpfiles or fixing typos are highly valued, take minimal builder time to review, and immediately improve the player experience.
- Form Small, Focused Teams: For approved projects (like build projects), work within small, coordinated teams to resolve big architectural questions early in the planning stage.
- Think in Systems: When pitching an idea, look beyond why this idea is the right one to address the underlying problem. Address its potential second-order effects on game balance, play styles, fun, and expected positive and negative impacts.
- Provide Knowledge or Code: The community has many projects like the Wiki or MMapper that allow for smaller improvements without needing a regular time commitment.
Generated on Mon Jun 8 15:43:13 2026