How to Create a Code of Conduct for Your MU Online Server's Staff
Draft a clear Code of Conduct for your MU Online server's staff team, covering power limits, GM command usage, conflicts of interest, internal punishments, and transparency with the community.
An MU Online server is only as trustworthy as its staff's conduct. Game Master commands, database access, and the power to ban give staff an influence that, if misused, destroys community trust within days — even if the server has excellent technical infrastructure. A Staff Code of Conduct formalize
An MU Online server is only as trustworthy as its staff's conduct. Game Master commands, database access, and the power to ban give staff an influence that, if misused, destroys community trust within days — even if the server has excellent technical infrastructure. A Staff Code of Conduct formalizes the limits on using these powers, internal investigation processes, and transparency rules with players. This tutorial details how to structure this code, from GM command usage rules to the process for punishing a member of the team itself.
Why staff needs its own rules
Regular players have limited power in the game. Staff, especially Game Masters and administrators, have access to commands that can create items, teleport characters, ban accounts, and, on many emulators, directly edit the database. A generic code of conduct ("be respectful") doesn't cover the specific risks of this access level — you need explicit rules about what's allowed, what requires another person's approval, and what's forbidden under any circumstance.
Recommended code of conduct structure
| Section | Content |
|---|---|
| Scope and hierarchy | Who counts as staff, access levels |
| GM command usage | What can be used freely vs. what requires approval |
| Conflict of interest | Rules on playing on the own server, favoring friends |
| Confidentiality | Player data, passwords, internal logs |
| Public communication | Tone, transparency, what can/can't be said |
| Internal disciplinary process | How to investigate and punish staff itself |
| Consequences | Warning, access suspension, permanent removal |
Step 1 — Define the hierarchy and access levels
Before writing conduct rules, make it clear who has what power:
| Level | Typical role | Access |
|---|---|---|
| 1 | Support/Attendant | No GM commands, ticket access only |
| 2 | Moderator | Chat commands (mute, kick), no item access |
| 3 | Game Master | Item creation, teleport, ban commands |
| 4 | Administrator | Database and server configuration access |
Conduct rules should scale with access level — an administrator with database access needs much stricter rules than a chat moderator.
Step 2 — Clear rules for GM command usage
This is the code's most critical section. Explicitly define:
ALLOWED WITHOUT PRIOR APPROVAL:
- Mute a player for blatant spam/abuse
- Teleport yourself to investigate an in-game report
- Temporarily ban for a flagrant and documented exploit
REQUIRES APPROVAL FROM ANOTHER STAFF MEMBER (equal or higher rank):
- Create or hand over any item to a player
- Permanent account ban
- Reverse a transaction or restore a lost item
FORBIDDEN UNDER ANY CIRCUMSTANCE:
- Using GM commands for personal benefit or that of acquaintances
- Creating an item/Zen for yourself, even "just to test"
- Sharing GM access credentials with anyone
- Accessing a player's account without a documented investigation reasonWithout this explicit distinction between "allowed," "requires approval," and "forbidden," each staff member applies their own judgment, which creates inconsistency and opens room for abuse.
Step 3 — Conflict of interest rules
Define whether and how staff members can play on their own server:
| Situation | Recommended rule |
|---|---|
| Staff plays with a personal account | Allowed, but with public transparency about the accounts |
| Staff uses GM access to benefit own account | Forbidden, with punishment equal to or greater than a regular player |
| Staff moderates a dispute involving a close friend | Should recuse and delegate to another moderator |
| Staff sells items/services outside the official system | Forbidden, creates the appearance of corruption even without real abuse |
Transparency about which accounts belong to staff prevents the community from suspecting favoritism (whether justified or not).
Step 4 — Confidentiality of player data
Staff frequently have access to sensitive information: emails, IPs, purchase history, private chat logs. The code must explicitly state:
- Player data can only be accessed for support investigation or report purposes.
- Sharing, screenshotting, or publicly disclosing any player's personal data is forbidden.
- Investigation logs can only be used internally, never as public "proof" in a Discord dispute.
Step 5 — Public communication rules
How staff position themselves publicly directly affects the server's reputation:
- Don't discuss moderation decisions publicly without approval
from whoever is responsible for official communications.
- Don't make promises about features/deadlines without confirmation
from project leadership.
- Keep a professional tone even under player provocation —
responding in the heat of the moment produces screenshots
that circulate in the community for a long time.Step 6 — Internal disciplinary process for staff itself
When a staff member commits an infraction (from minor command misuse to item duplication), the process should be just as serious as the one applied to players — in many cases stricter, because it involves a breach of trust:
1. Report or detection of the problem (log, player, other staff).
2. Investigation by at least 2 members of equal/higher rank
than the one investigated (avoids unilateral decisions).
3. Right of response for the investigated party before the final decision.
4. Decision documented internally, with date and responsible parties.
5. Communication: always internal; public when the case directly
affects the community (e.g., a duplicated item that impacted
the economy).Step 7 — Scale of consequences
| Severity | Example | Typical consequence |
|---|---|---|
| Minor | Command used outside scope, no harm done | Formal warning on record |
| Moderate | Minor favoritism (e.g., privileged info to a friend) | Temporary GM access suspension |
| Serious | Creating an item/Zen for personal benefit | Removal from staff, possible personal account ban |
| Very serious | Item duplication, selling access, data leak | Permanent removal + transparent communication to the community |
Step 8 — Periodic review of the code
The code of conduct shouldn't be static. Review it every new season or whenever an incident exposes an uncovered gap (for example, staff use of automated bots, or conflict of interest in a guild dispute). Document the changes and communicate them to the entire team, not just new members.
Common errors and fixes
| Symptom | Likely cause | Fix |
|---|---|---|
| Staff uses GM commands for personal benefit without punishment | No code of conduct exists or isn't enforced | Formalize the code and apply real consequences |
| Community suspects favoritism toward staff | Lack of transparency about staff accounts | Publish a list of known staff accounts |
| Internal punishments inconsistent between members | No defined consequence scale | Adopt a standardized severity/consequence table |
| Player data leak | Confidentiality not formalized | Add an explicit confidentiality section to the code |
| Staff protects each other during investigations | Disciplinary process with no third-party review | Require 2+ investigators of equal/higher rank |
Code of conduct implementation checklist
- Staff hierarchy and access levels documented.
- GM command usage rules split into allowed/needs-approval/forbidden.
- Conflict of interest rules (staff playing on the server) defined.
- Player data confidentiality section included.
- Public communication guidelines established.
- Internal disciplinary process documented, with multiple investigators.
- Consequence scale by severity defined.
- Code reviewed and communicated at each new season.
With the staff code of conduct formalized, the natural next piece of governance is ensuring players also follow a clear behavior standard — see how to structure that side of the coin when planning your MU Online server from the ground up.
Frequently asked questions
Why does staff need a code of conduct separate from the player rules?
Because staff have powers regular players don't (GM commands, database access, moderation), and abusing those powers causes much greater damage to the community than a typical player infraction. A specific code sets clear limits for those with this privileged access.
Can a staff member play on their own server with a personal account?
It depends on the server's policy, but the recommended practice is to allow it with clear restrictions: a ban on using GM commands to benefit their own account or friends', and a requirement to publicly disclose which accounts belong to staff members, for transparency with the community.
What should be done when a staff member commits a serious infraction (e.g., duplicating an item)?
There should be a documented internal investigation and punishment process, with the same seriousness (or greater) as applied to a regular player. Servers that shield staff from punishment out of loyalty quickly lose credibility once the community finds out.
Is it mandatory to publicly disclose internal staff punishments?
It's not mandatory in every case, but selective transparency (announcing that action was taken, without necessarily exposing personal details) strengthens community trust. Total silence about serious staff infractions, once discovered, generally causes more reputational damage than transparency would.
How many people should approve a punishment against another staff member?
It's recommended that punishments against staff require at least two people of equal or higher rank than the one being investigated, avoiding unilateral decisions and possible personal retaliation within the team itself.