MUD Conflict Resolution with Mediation scripts
Multi-User Dungeons rely on text-based interactions that generate permanent logs, making evidence-based conflict resolution possible but requiring structured workflows. This guide provides concrete implementations for immortal staff to triage player disputes, conduct mediated conversations, and enforce boundaries without escalating community drama. It assumes you run a LPMUD, DikuMUD, or similar codebase with logging capabilities and staff access levels.
Configure Immutable Evidence Logging
Set up your game driver to capture player communications to append-only storage before disputes arise. For LPMUDs, modify the user.c object to write tells, channels, and emotes to a PostgreSQL table with JSONB columns for metadata. Set file permissions to 640 (read/write owner, read group, no other) to prevent tampering. This creates the audit trail required for triage.
CREATE TABLE mud_evidence (
id SERIAL PRIMARY KEY,
utc_timestamp TIMESTAMPTZ DEFAULT NOW(),
actor VARCHAR(32) NOT NULL,
target VARCHAR(32),
channel VARCHAR(32),
content TEXT,
room_id VARCHAR(64),
hash VARCHAR(64) GENERATED ALWAYS AS (digest(content, 'sha256')) STORED
);
CREATE INDEX idx_evidence_actor_time ON mud_evidence(actor, utc_timestamp);⚠ Common Pitfalls
- •Logging private messages may violate GDPR or CCPA without consent mechanisms
- •Storing full content indefinitely creates storage bloat; implement 90-day rotation for minor incidents
Deploy the Incident Timeline Template
Standardize documentation by creating a Markdown template that staff populate during triage. The template must capture UTC timestamps, involved player IDs, evidence hashes from Step 1, and escalation triggers (harassment, cheating, OOC threats). Store these in a Git repository or wiki with restricted access to prevent player discovery of ongoing investigations.
## Incident ID: {{YYYYMMDD}}-{{SEQUENCE}}
**Status:** Triage | Active | Resolved | Closed
**Parties:** @player1, @player2
**First Report:** {{TIMESTAMP}}
**Evidence Hash:** sha256:abc123...
### Timeline
- HH:MM:SS Event description (link to log)
### Escalation Criteria
- [ ] OOC threats
- [ ] Repeated boundary violations
- [ ] Involvement of new players (<7 days)⚠ Common Pitfalls
- •Using local timezones causes synchronization errors across international staff
- •Failing to link evidence hashes allows disputed log editing accusations
Architect Staff Review Channels
Create three distinct communication channels to prevent information cross-contamination: #investigation (read-only, evidence dumps), #deliberation (staff-only decision making), and #mediation (controlled access for accused/accuser). For Discord, use private threads with specific role mentions. For IRC, use +z (secure) channels with ChanServ access lists. Never discuss active cases in public staff lounges.
/msg ChanServ REGISTER #mud-investigation
/msg ChanServ FLAGS #mud-investigation *!*@staff.host +V (voice for speaking)
/msg ChanServ SET #mud-investigation SECURE ON
/msg ChanServ SET #mud-investigation PRIVATE ON⚠ Common Pitfalls
- •Allowing informal DMs between staff and involved parties creates perception of bias
- •Forgetting to archive channels after resolution destroys precedent records
Implement Mediation Script Protocols
Structure live mediation sessions using a four-phase script: (1) Venting (uninterrupted statement), (2) Fact-checking against evidence logs, (3) Interest identification (what each player actually wants), (4) Option generation. Staff act as facilitators, not judges. Use MUD's 'idle' command or Discord's slow-mode to enforce turn-taking and prevent interruption floods.
PHASE 1: VENTING
Staff: 'You have 5 minutes or 2000 characters to explain your perspective. @player2 will not respond until you finish.'
[Staff monitors for OOC harassment; pauses if detected]
PHASE 2: FACT CHECK
Staff: 'According to logs at 2024-01-15T14:30:00Z, you said [quote]. Is this accurate?'
PHASE 3: INTERESTS
Staff: 'What specific change would let you continue playing here comfortably?'
PHASE 4: OPTIONS
Staff: 'Option A: Mutual ignore lists. Option B: Faction territory boundaries. Which works?'⚠ Common Pitfalls
- •Skipping Phase 2 allows fabricated narratives to solidify
- •Staff proposing solutions in Phase 3 removes player agency and reduces buy-in
Build the Sanction Tracking System
Create a database table or flat-file log that tracks disciplinary actions with automatic expiration dates and appeal flags. Link sanctions to Incident IDs from Step 2. Include fields for sanction type (mute, siteban, faction freeze), duration, and automated unban scripts. This prevents 'forgotten' indefinite bans and identifies repeat offenders through JOIN queries.
CREATE TABLE sanctions (
id SERIAL PRIMARY KEY,
player_id VARCHAR(32) REFERENCES players(name),
incident_id INTEGER REFERENCES incidents(id),
type VARCHAR(32) CHECK (type IN ('mute', 'ban', 'freeze')),
start_time TIMESTAMPTZ DEFAULT NOW(),
end_time TIMESTAMPTZ,
reason TEXT,
appealable BOOLEAN DEFAULT TRUE,
appeal_date TIMESTAMPTZ
);
-- Query to find repeat offenders
SELECT player_id, COUNT(*) as strike_count
FROM sanctions
WHERE start_time > NOW() - INTERVAL '6 months'
GROUP BY player_id HAVING COUNT(*) > 2;⚠ Common Pitfalls
- •Manual ban expiration requires cron jobs or event-based MUD code; forgetting this creates permanent accidental bans
- •Not linking to incident IDs makes appeal reviews impossible
Configure Automated Boundary Enforcement
Hardcode restrictions into your MUD's command parser to enforce mediation outcomes automatically. If players agree to 'no contact,' implement a block system in the tell/say/emote commands that checks a 'blocks' table before delivering messages. For 'faction truces,' modify the combat code to return errors when targeting specific players. This removes staff from constant monitoring.
// In player.c or commands.c
int cmd_tell(string arg) {
string target, msg;
if(sscanf(arg, "%s %s", target, msg) != 2) return 0;
// Check active blocks
if(db_check_block(this_player()->query_name(), target)) {
write("You cannot communicate with that player per mediation agreement #"+db_get_block_incident(target)+".\n");
return 1;
}
// ... normal tell logic
}⚠ Common Pitfalls
- •Soft blocks (social agreements) fail when players are emotionally escalated
- •Not logging block attempts misses violation evidence
Establish Post-Conflict Recovery Protocols
Create a 30-60-90 day checkpoint system for reintegrating sanctioned players. At 30 days, automated query checks for new incidents. At 60 days, staff sends a private survey link (Google Forms or LimeSurvey) to involved parties. At 90 days, review if restrictions can be lifted. For MUDs with quest systems, create optional 'reputation recovery' quests that require cooperative play with neutral parties.
-- Automated 30-day check
SELECT s.player_id, COUNT(e.id) as new_violations
FROM sanctions s
LEFT JOIN evidence e ON e.actor = s.player_id
AND e.utc_timestamp > s.start_time + INTERVAL '30 days'
WHERE s.end_time < NOW() AND s.start_time > NOW() - INTERVAL '30 days'
GROUP BY s.player_id;⚠ Common Pitfalls
- •Prematurely lifting sanctions before 30 days undermines the consequence gravity
- •Failing to notify neutral players about reintegration creates surprise conflicts
What you built
Conflict resolution in MUDs succeeds when technical systems (logging, automated enforcement) support human judgment (mediation, triage). Implement these steps incrementally: start with evidence logging and incident templates before attempting live mediation. Review your sanction tracking queries monthly to identify systemic issues—repeat offenders often indicate missing game mechanics (imbalanced PvP, scarce resources) rather than purely social problems. Archive resolved incident timelines in a 'precedents' document to train new staff consistently.
.