Cómo evaluar el desempeño de los GM en tu servidor de MU Online
Arma un proceso objetivo para evaluar a los Game Masters de tu servidor de MU Online, con métricas de atención, indicadores de abuso de poder y un modelo de scorecard mensual para decidir ascensos y desvinculaciones.
Mantener un equipo de Game Masters (GM) motivado y confiable es uno de los mayores desafíos de quien administra un servidor privado de MU Online: son ellos quienes deciden baneos, resuelven tickets y tienen acceso a comandos que, mal usados, pueden destruir la confianza de la comunidad en pocas hora
Mantener un equipo de Game Masters (GM) motivado y confiable es uno de los mayores desafíos de quien administra un servidor privado de MU Online: son ellos quienes deciden baneos, resuelven tickets y tienen acceso a comandos que, mal usados, pueden destruir la confianza de la comunidad en pocas horas. Sin un proceso de evaluación estructurado, las decisiones de ascender, amonestar o desvincular a un GM terminan siendo emocionales, basadas en un reclamo aislado o en simpatía personal. Este tutorial presenta un modelo de evaluación objetivo, con métricas medibles, indicadores de riesgo de abuso y un scorecard listo para aplicar mensualmente en tu staff.
Por qué evaluar a los GM de forma estructurada
Un GM tiene acceso a comandos que alteran el juego directamente: teletransporte, aparición de ítems, alteración de stats, baneo de cuentas. Sin evaluación formal, el dueño del servidor solo descubre un problema cuando ya se convirtió en reclamo público en Discord o en el foro. Un proceso estructurado se anticipa a esos problemas: identifica caídas en la calidad de atención, uso indebido de comandos y favoritismo antes de que la comunidad lo note. Además, le da al propio GM un camino de crecimiento claro —de Helper a GM pleno, de GM pleno a Head-GM— basado en criterios visibles, no en el favoritismo del dueño.
Métricas de atención (volumen y calidad)
La primera dimensión de la evaluación es operativa: ¿el GM resuelve los tickets que le llegan, y con qué calidad?
| Métrica | Cómo medir | Meta sugerida |
|---|---|---|
| Tiempo promedio de primera respuesta | Timestamp del ticket hasta el primer mensaje del GM | Menos de 10 minutos en horario pico |
| Tasa de resolución en el primer contacto | Tickets cerrados sin reapertura / total | Más del 70% |
| Tickets reabiertos | Cuántos tickets el jugador reclamó por solución incompleta | Menos del 10% |
| Volumen por turno | Tickets atendidos / tickets disponibles en el turno | Comparar entre GM del mismo turno, nunca entre turnos distintos |
| Nota de satisfacción (si hay sistema de evaluación post-ticket) | Promedio de 1 a 5 dado por el jugador | Más de 4,0 |
Recolectá estos datos del propio sistema de tickets (Discord con bot de tickets, o panel web): la mayoría de los bots de soporte ya genera este tipo de reporte automáticamente.
Indicadores de abuso de poder
Esta es la dimensión más sensible y la que exige logs confiables del servidor. Activá (o confirmá que ya está activo) el log de comandos GM en tu emulador: cada /summon, /additem, /ban, /setstats debe registrar quién lo ejecutó, cuándo y sobre qué objetivo.
| Indicador | Qué verificar | Señal de alerta |
|---|---|---|
| Ítems generados para sí mismo | Comandos /additem con destino = la propia cuenta del GM | Cualquier ocurrencia fuera de una prueba documentada |
| Baneos sin justificación registrada | Ban aplicado sin ticket o denuncia asociada | Más de 1 caso por mes |
| Teletransporte fuera de contexto de atención | /move//warp sin ticket abierto en ese horario | Patrón recurrente, no un caso aislado |
| Favoritismo en disputas | Decisiones siempre a favor del mismo grupo de jugadores | Reclamos recurrentes de varios jugadores distintos |
| Uso de comando fuera del horario de guardia | Log de comando fuera de la ventana de turno declarada | Investigar siempre, puede ser una cuenta comprometida |
Un único ítem generado "para probar" puede ser legítimo si está documentado en el canal de staff antes de la acción. El problema es el patrón silencioso, no el evento aislado.
Evaluación de comunicación y postura
Además de los números, evaluá cualitativamente una muestra de conversaciones del GM con jugadores (con consentimiento previo acordado en la contratación). Criterios objetivos:
- Usa un lenguaje respetuoso incluso con jugadores alterados u hostiles.
- Explica la decisión (por qué el ban, por qué el ítem no será recreado) en vez de solo aplicar la acción.
- No debate política, religión ni asuntos personales en el canal oficial.
- Escala al Head-GM cuando el caso excede su alcance, en vez de improvisar.
- Mantiene el mismo estándar de respuesta en el idioma informal del servidor, sin jergas ofensivas.
Modelo de scorecard mensual
Un scorecard simple, de 0 a 5 por categoría, con peso distinto por dimensión, funciona bien para servidores de cualquier tamaño:
| Categoría | Peso | Nota (0-5) | Puntuación ponderada |
|---|---|---|---|
| Volumen y resolución de tickets | 25% | — | — |
| Calidad de atención (comunicación) | 25% | — | — |
| Ausencia de indicadores de abuso | 30% | — | — |
| Cumplimiento de escala/guardia | 10% | — | — |
| Colaboración con el resto de la staff | 10% | — | — |
Una nota final por debajo de 2,5 en cualquier mes dispara una conversación individual obligatoria. Dos notas seguidas por debajo de 2,5 en la categoría "ausencia de indicadores de abuso" justifican la suspensión del acceso GM, independientemente de las demás notas.
Estructura de feedback (1:1 mensual)
No basta con calcular la nota: el retorno tiene que llegar al GM de forma constructiva. Un formato que funciona: empezá por los puntos fuertes específicos (no genéricos, "resolvió el caso del duplicador de ítems rápido"), después los puntos de mejora con un ejemplo concreto (no "sé más educado", sino la captura de la conversación problemática), y terminá con un acuerdo de acción para el próximo mes. Documentá el 1:1 en un canal privado de RR.HH. de la staff: eso protege tanto al GM como a la gestión ante una disputa futura.
Criterios para ascender de Helper a GM
Muchos servidores usan una jerarquía Helper → GM → Head-GM. Definí criterios claros de ascenso, evitando que parezca arbitrario:
| Criterio | Exigencia mínima |
|---|---|
| Tiempo en la función actual | 60 a 90 días |
| Nota promedio en el scorecard | Más de 4,0 en los últimos 2 meses |
| Cero indicadores de abuso confirmados | Ninguna ocurrencia en el período |
| Conocimiento técnico | Dominio de los comandos del nivel siguiente, probado en ambiente de staging |
| Recomendación del Head-GM directo | Obligatoria |
Criterios para amonestación y desvinculación
Así como el ascenso necesita criterio, la desvinculación también: eso evita que la decisión parezca persecución personal y protege al servidor de disputas dentro de la propia staff.
| Situación | Acción recomendada |
|---|---|
| Primer reclamo de mala conducta, sin prueba de abuso | Amonestación verbal registrada en acta |
| Segundo reclamo en el mismo trimestre | Amonestación formal por escrito + suspensión temporal del acceso |
| Ítem generado para sí mismo/terceros confirmado en el log | Desvinculación inmediata, sin importar el historial previo |
| Filtración de información interna (planes de evento, correcciones) | Desvinculación inmediata |
| Caída de desempeño sin indicio de mala fe | Plan de mejora de 30 días antes de cualquier desvinculación |
Herramientas para automatizar la recolección de datos
Cuanto más manual sea la recolección, menos consistente será la evaluación. Algunas opciones prácticas:
- Bot de tickets en Discord (ej.: Ticket Tool, Hexadecimal) genera reportes de tiempo de respuesta y volumen automáticamente.
- Log de comandos del propio emulador (MuEmu, IGCN) generalmente se guarda en una tabla SQL; una consulta simple extrae comandos por GM y por período.
- Planilla compartida (Google Sheets) con el scorecard, actualizada al cierre del mes, mantiene el historial accesible para todo el liderazgo.
- Canal privado de staff en Discord con webhook de log de comandos sensibles, para auditoría en tiempo real sin necesidad de entrar a la base de datos.
Cómo manejar conflictos entre el GM evaluado y el evaluador
Cuando el propio Head-GM tiene una relación de amistad con el evaluado, el proceso pierde credibilidad. Definí una regla simple: ningún evaluador evalúa a un GM con quien tiene un vínculo personal fuera del servidor (familia, socio en otro proyecto). En esos casos, el dueño del servidor asume la evaluación directamente o la delega a otro Head-GM. Documentá esta regla en el manual interno de la staff, para que no parezca improvisada cuando el conflicto realmente aparezca.
Errores comunes y soluciones
| Síntoma | Causa probable | Solución |
|---|---|---|
| La evaluación siempre es subjetiva, termina en discusión | Falta de métricas y logs objetivos | Activar el log de comandos GM y adoptar el scorecard con pesos |
| El GM se siente perseguido tras una mala evaluación | Feedback dado sin ejemplos concretos | Adjuntar siempre una captura/log específico al señalar un problema |
| El abuso solo se descubre por denuncia de un jugador | Ninguna auditoría proactiva del log | Revisión semanal liviana de comandos sensibles, no solo mensual |
| Los ascensos parecen favoritismo | Criterios de ascenso no documentados | Publicar los criterios en el manual interno antes del próximo ascenso |
| Los datos de tickets no coinciden entre GM | Sistemas de medición distintos por turno | Estandarizar un único bot/panel de tickets para toda la staff |
Lista de verificación de evaluación de GM
- Log de comandos GM activo y accesible para auditoría.
- Scorecard mensual con pesos definidos y aplicado a todos los GM.
- 1:1 mensual agendado con feedback documentado.
- Criterios de ascenso y desvinculación publicados en el manual de la staff.
- Regla de conflicto de interés entre evaluador y evaluado definida.
- Canal de auditoría proactiva (no solo reactiva a denuncias) funcionando.
- Historial de evaluaciones archivado para consulta en disputas futuras.
Con el proceso de evaluación en marcha, el siguiente paso natural es revisar también cómo se comunica la staff con el servidor en general, incluyendo los canales automatizados de moderación, lo que se conecta directamente con la estructura general de administración descrita en el tutorial de creación de servidor de MU Online.
Preguntas frecuentes
¿Con qué frecuencia debo evaluar a los GM?
Lo ideal es una evaluación liviana semanal (volumen de tickets, tiempo de respuesta) y una evaluación completa mensual con el scorecard. Las evaluaciones solo trimestrales dejan pasar desapercibidos abusos de poder o caídas de calidad durante demasiado tiempo.
¿Debo avisarle al GM que está siendo evaluado?
Sí, la transparencia del proceso debe acordarse desde el ingreso del GM al equipo. Una evaluación encubierta genera desconfianza y, si el GM lo descubre después, mina la autoridad de la staff frente al resto del equipo.
¿Qué logs necesito activar para evaluar correctamente?
Como mínimo el log de comandos GM (entrega de ítems, teletransporte, ban/unban, alteración de stats) y el log del chat del canal de staff. Sin estos dos, cualquier evaluación se vuelve 'especulación' y no resiste un reclamo de favoritismo.
¿Un GM con pocos tickets resueltos es siempre un problema?
No necesariamente: puede reflejar un turno de baja actividad. Compará siempre contra el promedio de tickets disponibles en ese turno, no contra un número absoluto fijo, para no castigar injustamente al GM de un horario flojo.
¿Qué hacer cuando la evaluación detecta abuso de poder confirmado?
Suspendé el acceso GM de inmediato mientras investigás, sin esperar el próximo ciclo de evaluación. El abuso de poder (darse ítems a sí mismo o a amigos, perseguir a un jugador) es la única categoría que exige acción fuera del calendario normal.