How to set up guild hierarchy and ranks on your MU Online server

The guild is the most important social unit in MU Online: it's where players organize wars (GvG), split boss loot, coordinate Castle Siege, and build an identity within the server. A well-defined rank hierarchy prevents leadership chaos, makes clear who can invite, kick, or declare war, and creates a path of social progression for players who want to take on responsibility. This tutorial explains MU's standard ranks, how to configure and customize them on your server, and how to structure succession, alliance, and war rules that sustain a healthy community over the long run.

MU Online's standard hierarchy

The official guild system works with three to four well-defined roles, each with specific permissions within the game and the guild interface (G window).

This structure already covers most of the basic management, but larger servers tend to create extra layers via a web panel or a custom guild system, giving finer granularity to whoever administers a guild of 30+ people.

Where the hierarchy is configured

Unlike items or monsters, guild rank logic usually lives in two layers: the GameServer (game rules, member limits, command permissions) and the database (guild and member tables, typically Guild and GuildMember or equivalent). Some emulators expose guild parameters in a dedicated file, such as GuildConfig.txt or a [Guild] section in the GameServer's main config.

[Guild]
MaxGuildMembers = 32
MaxAlliance = 1
GuildCreateLevel = 100
GuildCreateCost = 500000
WarDeclareCooldownHours = 24

• MaxGuildMembers sets the member cap.
• GuildCreateLevel requires a minimum level to found a guild, avoiding disposable guilds created by new accounts.
• WarDeclareCooldownHours prevents spam war declarations against the same target.

Creating custom ranks beyond the standard set

If your emulator or web panel lets you extend the guild table, a richer rank model for servers with a large community looks like this:

These ranks rarely exist natively in the game protocol — in practice they are social conventions reinforced by a special role in the guild's Discord or a flag in the web panel, since the MU client only recognizes the official ranks in its interface.

Leadership succession rules

One of the biggest problems in MU communities is a Guild Master who disappears without handing off leadership. Define a clear rule and publish it in the server's public rules:

1. GM inactivity for 15 consecutive days → the Vice Master can request a transfer via a support ticket.
2. Proof of ownership (linked account, login history) prevents a bad-faith third party from claiming leadership.
3. Transfer via GM command in the database (UPDATE Guild SET Master = ...) or through an admin panel tool, always with an action log.
4. 48-hour contest window before the transfer takes effect, so the former GM can return and cancel the process.

Technical permissions per rank (implementation)

When implementing ranks server-side, every sensitive action should check the player's hierarchy level before executing. A typical pseudo-flow inside the GameServer:

onGuildCommand(player, command):
    role = getGuildRole(player)
    if command == "DECLARE_WAR" and role < GUILD_MASTER:
        deny("Only the Guild Master can declare war")
    if command == "KICK_MEMBER" and role < VICE_MASTER:
        deny("Insufficient permission")
    if command == "INVITE" and role < VICE_MASTER:
        deny("Insufficient permission")
    execute(command)

This kind of check prevents regular members from using client exploits (modified guild commands) to execute restricted actions.

Alliances between guilds

Alliances let two or more guilds cooperate in GvG and Castle Siege without friendly-fire risk. The typical setup limits how many guilds can join an alliance and blocks internal war:

Guild war (GvG) and the hierarchy's role

Only the Guild Master (or the Vice Master, if configured) can declare war. This prevents a regular member from impulsively dragging the whole guild into an unwanted conflict. When configuring the system:

• Set a declaration fee (Zen) to discourage frivolous wars.
• Configure the war duration (usually a 20-to-60-minute active window per day).
• Establish a visible kill scoreboard for both sides, encouraging Battle Masters to organize.
• Consider war rewards (Guild Points, exclusive items) to give the leadership rank real purpose.

Guild Fund and financial management

Many servers implement a "guild vault" where members contribute Zen or items for collective purchases (Castle Siege, war bonuses). The hierarchy should decide who can withdraw:

• Guild Master: full access.
• Vice Master: access limited to a daily/weekly cap.
• Treasurer (if it exists): access configured manually by the GM via command or panel.
• Regular member: deposit only, never withdrawal.

Without this control, "guild fund theft" complaints are common in the community — one of the most frequent support-request reasons on private servers.

Web guild management panel

A good complement to the in-game system is a panel on the server's site where the Guild Master and Vice Master can view members, war history, contribution rankings, and send invites without needing to be logged into the game. This reduces dependence on external tools like spreadsheets and Discord for basic control, and centralizes the information the community asks about most: "who's active" and "how much did each person contribute."

Community communication and rules

Technical hierarchy doesn't replace clear community rules. Publish in the server rules:

• Objective criteria for expulsion (inactivity, toxic behavior, Castle Siege absence).
• An appeal process for unfairly kicked players.
• A recruitment policy (guilds can't "poach" members from another guild in active war, for example).
• Consequences for rank abuse (a Vice Master who mass-kicks out of spite, for example, can be demoted by administrative decision upon a verified report).

Common errors and fixes

Guild hierarchy configuration checklist

• Standard ranks (GM, Vice Master, Battle Master, Member) configured and tested in game.
• Member limit and minimum creation level set in the config.
• Leadership succession rule documented and communicated to the community.
• Per-rank permission validation implemented on the GameServer.
• Alliance rules (cap, cooldown, internal war block) defined.
• Guild Fund with per-rank withdrawal control and audit log.
• Web guild management panel available (optional but recommended).
• Community rules and appeal process published on the site.

With a mature guild hierarchy in place, the natural next step is giving guilds a bigger competitive goal, such as a structured tournament system between them — check out the server creation tutorial to review your environment's foundation before moving forward.

Frequently asked questions