Immortals with Admin command sets
Immortals in MUDs occupy a unique position between players and system architects. Unlike MMORPG GMs with rigid toolsets, MUD staff often operate within the same game world with customizable command sets and zone-building capabilities. This guide provides concrete frameworks for establishing role boundaries, moderation workflows, and promotion criteria that prevent the common failure modes of hobbyist MUD administration: unchecked power accumulation, opaque promotion standards, and inconsistent player-facing communication.
Audit and classify existing immortal commands by risk tier
Review your codebase's command table to categorize every immortal-level command into four tiers: Informational (read-only), Creative (building/quest tools), Social (visibility/communication overrides), and Destructive (player modification, bans, item spawning). Document which commands exist at each tier and which staff levels currently have access. This prevents situations where junior staff accidentally possess world-altering capabilities.
RISK TIER CLASSIFICATION
TIER 1 - INFORMATIONAL (All immortals)
- where, who, stat, identify
- Moderation logs (read-only)
TIER 2 - CREATIVE (Builders, Senior Guides)
- dig, redit, oedit, medit
- quest start/stop (limited zones)
- NOTE: Requires zone ownership verification
TIER 3 - SOCIAL (Administrators)
- invis, wizinvis levels
- force (limited scope)
- channel moderation (mute/silence)
TIER 4 - DESTRUCTIVE (Implementors only)
- purge, set, advance
- ban, delete (player/structure)
- shutdown, copyover⚠ Common Pitfalls
- •Assuming 'builder' means the same thing across all MUD codebases
- •Forgetting to check for hardcoded immortality checks in social commands
- •Missing alias commands that bypass tier restrictions
Define role boundaries with explicit authority matrices
Create a matrix document that maps each staff title to specific permissions and prohibitions. For each role (Helper, Guide, Builder, Administrator, Implementor), list exactly what they can modify, which players they can affect, and escalation paths when they encounter situations outside their scope. Include negative definitions—what they explicitly cannot do without higher approval.
## BUILDER AUTHORITY MATRIX
### CAN DO:
- Edit rooms/objects/mobiles within assigned vnum ranges
- Load test mobs/items in isolated test zones
- Submit zone proposals to Area Council
- Mentor apprentice builders (with co-signature)
### CANNOT DO:
- Modify live player characters or inventories
- Approve own zone for production without review
- Grant immortal status to others
- Override Administrator decisions on player disputes
### ESCALATION:
- Player harassment reports → Administrator
- Code bugs → Implementor
- Inter-builder conflicts → Senior Builder or Admin⚠ Common Pitfalls
- •Using vague terms like 'use good judgment' instead of specific boundaries
- •Creating roles that require simultaneous conflicting with and deferring to other staff
- •Forgetting to include time-bound restrictions (event-only permissions)
Implement structured moderation logging with required fields
Configure your MUD to require specific fields for every immortal action affecting players. At minimum, logs must capture: acting immortal, target player, command issued, timestamp, and free-text justification. For TIER 3 and 4 commands, require secondary confirmation and broadcast to a staff channel. Store logs in a tamper-resistant format (append-only file or database) with monthly archive procedures.
/* Example log structure for MUX/MUSH derivatives */
typedef struct mod_entry {
char actor[32]; /* Immortal account name */
char target[32]; /* Player affected, or 'NONE' */
char command[64]; /* Full command string */
time_t timestamp;
char justification[256]; /* Required for TIER 3+ */
int tier_level; /* From classification audit */
char witness[32]; /* Second immortal for TIER 4 */
} MOD_LOG;
/* Enforce in command parser */
if (cmd_tier >= TIER_3 && !has_witness(ch)) {
send_to_char("TIER 3+ commands require witness. Use: witness <player>\n", ch);
return;
}⚠ Common Pitfalls
- •Logging only commands but not their effects (log 'set level' but not what level was set)
- •Allowing immortals to delete or modify their own log entries
- •Storing sensitive player data (passwords, IP addresses) in the same moderation log
Create role-specific onboarding checklists with probation periods
Develop distinct checklists for each immortal tier with timed milestones. New Helpers might shadow for 30 days before receiving commands; Builders require zone proposal approval before edit access. Include verification steps where senior staff must confirm completion. Structure onboarding as gated access rather than immediate full permissions.
## BUILDER ONBOARDING CHECKLIST
### Week 1-2: Observation (No Commands)
- [ ] Attend 2 zone review sessions
- [ ] Read 3 complete zone submissions (any author)
- [ ] Shadow Senior Builder during editing session
- [ ] VERIFICATION: Senior Builder sign-off
### Week 3-4: Test Zone Access
- [ ] Complete tutorial zone build (100 rooms max)
- [ ] Submit for technical review (no content approval needed)
- [ ] Demonstrate reset/loading procedures
- [ ] VERIFICATION: Area Council approval
### Month 2+: Production Assignment
- [ ] Receive vnum range assignment
- [ ] Submit zone proposal (content + technical)
- [ ] Complete first zone to 'soft open' status
- [ ] VERIFICATION: Implementor grants persistent edit access⚠ Common Pitfalls
- •Skipping the observation period for experienced staff from other MUDs
- •Granting permanent permissions for temporary event support
- •Failing to include offboarding procedures when staff depart
Establish event planning workflows with approval gates
Define a submission and approval process for immortal-run events that impact multiple players. Require event proposals to include: scope (affected vnums/players), required commands, risk assessment, and rollback plan. Events using TIER 3+ commands need Administrator approval; those affecting entire playerbase need Implementor sign-off. Document actual vs. planned outcomes within 48 hours.
## EVENT PROPOSAL TEMPLATE
### EVENT METADATA
- Title:
- Lead Immortal:
- Date/Time (with timezone):
- Estimated Duration:
### SCOPE & COMMANDS
- Affected vnums:
- Player cap (if any):
- Commands required: [ ] TIER 1 [ ] TIER 2 [ ] TIER 3 [ ] TIER 4
- If TIER 3+: Witness immortal required:
### RISK ASSESSMENT
- Potential player conflict scenarios:
- Economic impact (item/currency injection):
- Rollback procedure if event fails:
### APPROVALS
- [ ] Content review (Senior Builder):
- [ ] Technical review (Implementor if TIER 4):
- [ ] Scheduling confirmed (no conflicts):⚠ Common Pitfalls
- •Allowing 'spontaneous' events that bypass approval for 'small' player groups without defining what 'small' means
- •Failing to include timezone considerations for international playerbases
- •Not requiring post-event reports that inform future policy
Document promotion criteria with measurable milestones
For each transition between roles (Player→Helper, Helper→Builder, Builder→Administrator, Administrator→Implementor), define specific accomplishments required. Avoid tenure-based promotions ('active for 6 months') in favor of deliverable-based criteria ('completed 3 zones with <5 bugs each'). Publish these criteria to all staff to prevent accusations of favoritism.
## BUILDER → ADMINISTRATOR PROMOTION CRITERIA
### REQUIRED DELIVERABLES
- [ ] 3 zones in production for 90+ days with <5 critical bugs each
- [ ] Mentored 2 apprentice builders to production status
- [ ] Handled 5 player disputes with documented resolutions
- [ ] Zero moderation log violations in 6 months
### SUBMISSION PROCESS
- Self-nomination or peer nomination to Senior Admin
- Portfolio review (zones, mentorship logs, dispute resolutions)
- 30-day probation with Administrator commands (limited scope)
- Peer feedback session with existing Admin team
### HARD STOPS (Automatic disqualification)
- Any confirmed abuse of immortal commands
- Unresolved zone balance complaints (3+ similar reports)
- Failure to complete assigned reviews within 14 days⚠ Common Pitfalls
- •Promoting based on friendship or availability rather than demonstrated competence
- •Creating 'soft' criteria that allow subjective interpretation
- •Failing to communicate when someone is being considered for promotion
Implement conflict-of-interest policies for dual-role scenarios
Address situations where immortals maintain player characters (alts) or have relationships with active players. Require disclosure of all player alts upon immortal promotion. Prohibit immortals from moderating disputes involving their alts, guildmates, or frequent collaborators. For small MUDs where total isolation is impossible, mandate witness requirements and recusal documentation.
CONFLICT OF INTEREST POLICY
DISCLOSURE REQUIREMENTS:
- All player alts must be registered with Implementor within 7 days of promotion
- Real-life relationships with active players must be disclosed
- Guild/clan affiliations (past 90 days) must be declared
RECUSAL RULES:
- Cannot moderate: own alts, guildmates, trade partners (>5 transactions/month)
- Cannot approve: zones created by disclosed associates
- Cannot arbitrate: disputes where either party is in disclosed relationship
DOCUMENTATION:
- All recusals logged with reason (specific relationship, not 'conflict')
- Annual re-attestation of disclosure accuracy
- Failure to disclose = immediate suspension pending review⚠ Common Pitfalls
- •Assuming 'everyone knows' who is related to whom in small communities
- •Allowing 'light touch' moderation of friends with verbal warnings only
- •Not requiring disclosure of past character names after name changes
Create player-facing communication protocols
Standardize how immortals identify themselves, explain decisions, and escalate issues. Require immortals to use consistent titles or tags in player channels. Define which decisions require written explanation (bans, item confiscation, quest disqualification) versus verbal-only. Establish response time expectations and escalation paths when players disagree with rulings.
## COMMUNICATION STANDARDS
### IDENTIFICATION
- Always use [IMM] tag in public channels
- Private tells: 'I am speaking as [Title], not as a player'
- Invis/wizinvis: Must announce presence before acting if revealing self
### DECISION EXPLANATION REQUIREMENTS
| Action | Explanation Required | Response Time |
|--------|---------------------|---------------|
| Mute/silence | Channel + duration + appeal method | Immediate |
| Item confiscation | Reason + return conditions | Within 1 hour |
| Quest disqualification | Rule violated + evidence | Immediate |
| Ban (any length) | Written notice to email + log entry | Immediate |
| Death restoration | None (handled in-game) | N/A |
### ESCALATION PATH
Player → Guide → Administrator → Implementor Council
- Each level must respond within 48 hours
- Implementor decisions are final (document this explicitly)
- Appeals must cite specific policy violations, not disagreement⚠ Common Pitfalls
- •Allowing immortals to 'go native' and hide status when convenient
- •Inconsistent enforcement of rules between 'famous' and unknown players
- •Failing to document that Implementor decisions are final, leading to endless appeals
Schedule regular staff audits and permission reviews
Implement quarterly reviews of immortal permissions to catch drift and abandoned accounts. Check for: promoted staff still holding lower-tier commands that should be revoked, departed staff with lingering access, and accumulated permissions beyond current role. Automate this if possible; manual reviews often reveal access that 'should have been' removed months ago.
-- Quarterly permission audit queries (MySQL/MariaDB example)
-- Run against player/immortal tables
-- Find immortals with higher-tier commands than their role allows
SELECT p.name, p.title, c.command_name, c.tier
FROM players p
JOIN command_access ca ON p.id = ca.player_id
JOIN commands c ON ca.command_id = c.id
WHERE c.tier > (SELECT max_tier FROM roles WHERE role_name = p.immortal_level)
AND p.immortal_level IS NOT NULL;
-- Find immortals inactive >90 days with TIER 3+ access
SELECT p.name, p.last_login, c.tier
FROM players p
JOIN command_access ca ON p.id = ca.player_id
JOIN commands c ON ca.command_id = c.id
WHERE p.last_login < DATE_SUB(NOW(), INTERVAL 90 DAY)
AND c.tier >= 3
GROUP BY p.name;
-- Detect commands granted outside standard role templates
SELECT DISTINCT p.name, ca.command_name
FROM command_access ca
JOIN players p ON ca.player_id = p.id
WHERE ca.granted_by IS NULL -- Direct DB edits bypass role system
OR ca.granted_date < DATE_SUB(NOW(), INTERVAL 1 YEAR);⚠ Common Pitfalls
- •Auditing only active logins and missing dormant immortal accounts
- •Forgetting to check for database-level edits that bypass role systems
- •Not notifying staff before permission reductions causing confusion
Document offboarding procedures for departing staff
Create a checklist for immortal departure that ensures clean transitions. Immediately upon resignation or removal: disable all TIER 2+ commands, archive personal zones for review, transfer mentorship responsibilities, and notify affected players if the departure impacts ongoing events. After 30 days, remove TIER 1 access and convert account to standard player status. Document reasons for involuntary removal privately with Implementor council.
## IMMORTAL OFFBOARDING CHECKLIST
### IMMEDIATE (Within 24 hours)
- [ ] Disable TIER 2+ commands (retain logs access for handoff)
- [ ] Remove from staff communication channels (Discord/MUD channels)
- [ ] Archive in-progress zones to 'pending review' status
- [ ] Cancel scheduled events or reassign
- [ ] Transfer active mentorship relationships
### SHORT-TERM (Within 7 days)
- [ ] Complete moderation log review for pending issues
- [ ] Transfer zone ownership or assign new maintainer
- [ ] Remove from staff documentation access (wikis, spreadsheets)
- [ ] Finalize any player dispute resolutions in progress
### FINAL (30 days post-departure)
- [ ] Remove TIER 1 commands, revert to mortal status
- [ ] Archive immortal-specific email/communication accounts
- [ ] Update staff roster on website and in-game
- [ ] (If involuntary) Document reasons in sealed Implementor record⚠ Common Pitfalls
- •Leaving 'friendly' departures with immortal access 'just in case'
- •Failing to reassign zone ownership causing unmaintained content
- •Not removing access to out-of-game staff resources (Discord, wikis, email)
What you built
MUD immortal structures fail when roles accumulate organically without documentation. The frameworks here prioritize containment of authority through explicit command tiering, measurable promotion criteria, and systematic offboarding. Implementation should occur in sequence: audit existing permissions first, then establish boundaries, then build workflows. Expect resistance from long-standing staff accustomed to informal flexibility; address this by grandfathering existing permissions while requiring new standards for future promotions. Review and update these documents quarterly as codebase capabilities and staff composition evolve.
.