Cómo configurar la jerarquía y los cargos de guild en tu servidor de MU Online

El guild es la unidad social más importante de MU Online: es donde los jugadores organizan guerras (GvG), reparten el loot de bosses, coordinan el Castle Siege y construyen identidad dentro del servidor. Una jerarquía de cargos bien definida evita desorden de liderazgo, da claridad sobre quién puede invitar, expulsar o declarar guerra, y crea un camino de progresión social para quien quiere asumir responsabilidades. Este tutorial explica los cargos estándar de MU, cómo configurarlos y personalizarlos en tu servidor, y cómo estructurar reglas de sucesión, alianzas y guerra que sostienen una comunidad sana a largo plazo.

La jerarquía estándar de MU Online

El sistema oficial de guilds trabaja con tres a cuatro roles bien definidos, cada uno con permisos específicos dentro del juego y de la interfaz de guild (ventana G).

Esta estructura ya resuelve buena parte de la gestión básica, pero los servidores más grandes tienden a crear capas adicionales mediante un panel web o un sistema de guild personalizado, para dar más granularidad a quien administra un guild de 30+ personas.

Dónde se configura la jerarquía

A diferencia de los ítems o monstruos, la lógica de cargos de guild generalmente vive en dos capas: el GameServer (reglas de juego, límite de miembros, permisos de comando) y la base de datos (tabla de guilds y miembros, generalmente Guild y GuildMember o equivalente). Algunos emuladores exponen parámetros de guild en un archivo propio, como GuildConfig.txt o una sección [Guild] en el config principal del GameServer.

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

• MaxGuildMembers define el tope de integrantes.
• GuildCreateLevel exige un nivel mínimo para fundar un guild, evitando guilds descartables creados por cuentas nuevas.
• WarDeclareCooldownHours evita el spam de declaraciones de guerra contra el mismo objetivo.

Creando cargos personalizados más allá del estándar

Si tu emulador o panel web permite extender la tabla de guilds, un modelo de cargos más rico para servidores con comunidad grande queda así:

Estos cargos casi nunca existen de forma nativa en el protocolo del juego — en la práctica son convenciones sociales reforzadas por un rol especial en el Discord del guild o por un flag en el panel web, ya que el cliente de MU solo reconoce los cargos oficiales en la interfaz.

Reglas de sucesión de liderazgo

Uno de los mayores problemas de las comunidades de MU es el Guild Master que desaparece sin traspasar el liderazgo. Define una regla clara y documéntala públicamente en las reglas del servidor:

1. Inactividad del GM durante 15 días consecutivos → el Segundo Cargo puede solicitar la transferencia mediante un ticket de soporte.
2. Comprobación de titularidad (cuenta vinculada, historial de login) evita que un tercero malintencionado reclame el liderazgo.
3. Transferencia mediante comando de GM en la base de datos (UPDATE Guild SET Master = ...) o mediante una herramienta del panel administrativo, siempre con log de la acción.
4. Plazo de contestación de 48h antes de que la transferencia se efectivice, para que el antiguo GM pueda regresar y cancelar el proceso.

Permisos técnicos por cargo (implementación)

Al implementar los cargos del lado del servidor, cada acción sensible debería verificar el nivel jerárquico del jugador antes de ejecutarse. Un pseudo-flujo típico dentro del GameServer:

onGuildCommand(player, command):
    role = getGuildRole(player)
    if command == "DECLARE_WAR" and role < GUILD_MASTER:
        deny("Solo el Guild Master puede declarar guerra")
    if command == "KICK_MEMBER" and role < VICE_MASTER:
        deny("Permiso insuficiente")
    if command == "INVITE" and role < VICE_MASTER:
        deny("Permiso insuficiente")
    execute(command)

Este tipo de verificación evita que miembros comunes usen exploits de cliente (comandos de guild modificados) para ejecutar acciones restringidas.

Alianzas entre guilds

Las alianzas permiten que dos o más guilds cooperen en GvG y Castle Siege sin riesgo de fuego amigo. La configuración típica limita el número de guilds por alianza y bloquea la guerra interna:

Guerra de guilds (GvG) y el papel de la jerarquía

Solo el Guild Master (o el Segundo Cargo, si está configurado) puede declarar guerra. Esto evita que un miembro común, por impulso, arrastre a todo el guild a un conflicto no deseado. Al configurar el sistema:

• Define una tarifa de declaración (Zen) para desincentivar guerras frívolas.
• Configura la duración de la guerra (generalmente 20 a 60 minutos de ventana activa por día).
• Establece un marcador de kills visible para ambos lados, incentivando la organización por parte de los Battle Masters.
• Considera recompensas de guerra (Guild Points, ítems exclusivos) para dar un propósito real al cargo de liderazgo.

Guild Fund y gestión financiera

Muchos servidores implementan una "caja del guild" donde los miembros aportan Zen o ítems para compras colectivas (Castle Siege, bonus de guerra). La jerarquía debe decidir quién puede retirar:

• Guild Master: acceso total.
• Segundo Cargo: acceso limitado a un tope diario/semanal.
• Tesorero (si existe): acceso configurado manualmente por el GM mediante comando o panel.
• Miembro común: solo depósito, nunca retiro.

Sin ese control, es común que surjan denuncias de "robo de guild" en la comunidad — uno de los motivos más frecuentes de solicitudes de soporte en servidores privados.

Panel web de gestión de guild

Un buen complemento al sistema in-game es un panel en el sitio del servidor donde el Guild Master y el Segundo Cargo puedan visualizar miembros, historial de guerra, ranking de contribución y enviar invitaciones sin necesidad de estar conectados al juego. Esto reduce la dependencia de herramientas externas como planillas y Discord para el control básico, y centraliza la información que la comunidad más pide: "quién está activo" y "cuánto aportó cada uno".

Comunicación y reglas de la comunidad

La jerarquía técnica no reemplaza reglas claras de convivencia. Publica en las reglas del servidor:

• Criterios objetivos para la expulsión (inactividad, comportamiento tóxico, ausencia en Castle Siege).
• Proceso de apelación para jugadores expulsados injustamente.
• Política de reclutamiento (los guilds no pueden "robar" miembros de otro guild en guerra activa, por ejemplo).
• Consecuencias por abuso de cargo (un Segundo Cargo que expulsa en masa por venganza, por ejemplo, puede ser degradado por decisión administrativa mediante denuncia comprobada).

Errores comunes y soluciones

Lista de verificación de configuración de jerarquía de guild

• Cargos estándar (GM, Segundo Cargo, Battle Master, Miembro) configurados y probados en el juego.
• Límite de miembros y nivel mínimo de creación definidos en el config.
• Regla de sucesión de liderazgo documentada y comunicada a la comunidad.
• Validación de permisos por cargo implementada en el GameServer.
• Reglas de alianza (límite, cooldown, bloqueo de guerra interna) definidas.
• Guild Fund con control de retiro por cargo y log de auditoría.
• Panel web de gestión de guild disponible (opcional, pero recomendado).
• Reglas de convivencia y proceso de apelación publicados en el sitio.

Con la jerarquía de guilds ya madura, el siguiente paso natural es darles a los guilds un objetivo competitivo mayor, como un sistema de torneo estructurado entre ellos — revisa el tutorial de creación de servidor para repasar la base de tu entorno antes de avanzar.

Preguntas frecuentes