Cómo generar reportes automáticos de economía para tu servidor de MU Online

Toda economía de un servidor de MU Online tiende a la inflación si nadie está observando los números — el Zen se acumula, las jewels se acumulan, y el ítem que era raro en el lanzamiento se convierte en commodity pocos meses después. La diferencia entre un servidor que mantiene la economía saludable por años y uno que "muere" de inflación en pocos meses generalmente no es la tasa de drop configurada inicialmente, sino la capacidad de detectar el desequilibrio a tiempo y actuar. Los reportes automáticos de economía son exactamente esa capacidad: un conjunto de consultas y alertas que corren solas y avisan al administrador antes de que el problema se vuelva visible para todos los jugadores. Este tutorial arma ese pipeline desde cero.

Por qué automatizar los reportes de economía

Mirar la economía "a ojo" — vía feedback de jugadores en Discord o impresión personal del administrador — siempre llega tarde. Cuando los jugadores empiezan a quejarse de que "el precio de todo subió", la inflación ya está en etapa avanzada y la corrección (reducir el drop, agregar un sink de Zen) causa más fricción de la que habría causado si se hubiera hecho a tiempo. Los reportes automáticos, corriendo diaria o semanalmente, dan visibilidad continua y permiten ajustes pequeños y graduales en vez de correcciones bruscas e impopulares.

Métricas esenciales de una economía de MU saludable

Fuentes de datos: dónde viven los números

La mayoría de los emuladores de MU (IGCN, MuEMU, X-Team) guarda esta información en tablas relativamente previsibles, aunque los nombres varían:

Si tu emulador no mantiene log de drop o transacción por defecto, vale la pena habilitar ese log vía configuración (la mayoría tiene la opción, aunque desactivada por defecto) antes de necesitarlo — sin historial, solo puedes analizar el estado actual, no la tendencia.

Paso 1 — Consulta de Zen total en circulación

SELECT
    (SELECT COALESCE(SUM(Money), 0) FROM Character) +
    (SELECT COALESCE(SUM(Money), 0) FROM Warehouse) AS zen_total_circulacao,
    (SELECT COUNT(DISTINCT AccountID) FROM Character WHERE LastLogin > NOW() - INTERVAL 7 DAY) AS contas_ativas_7d;

Corre esta consulta diariamente y guarda el resultado en una tabla histórica propia (no en las tablas del juego), para poder comparar la evolución a lo largo del tiempo:

CREATE TABLE eco_report_daily (
    report_date DATE PRIMARY KEY,
    zen_total BIGINT,
    contas_ativas INT,
    zen_medio_por_conta DECIMAL(20,2)
);

Paso 2 — Consulta de jewels en circulación por tipo

SELECT
    ItemIndex,
    CASE ItemIndex
        WHEN 14 THEN 'Jewel of Bless'
        WHEN 15 THEN 'Jewel of Soul'
        WHEN 22 THEN 'Jewel of Life'
        WHEN 31 THEN 'Jewel of Chaos'
        ELSE 'Otro'
    END AS jewel_nome,
    COUNT(*) AS quantidade_total
FROM Character_Inventory
WHERE ItemIndex IN (14, 15, 22, 31)
GROUP BY ItemIndex
ORDER BY quantidade_total DESC;

Ajusta los ItemIndex según la tabla de ítems de tu emulador — los valores anteriores son ilustrativos y varían según season/cliente.

Paso 3 — Detectando concentración de riqueza

SELECT AccountID, SUM(Money) AS zen_conta
FROM Character
GROUP BY AccountID
ORDER BY zen_conta DESC
LIMIT 20;

Compara la suma de esas 20 cuentas con el zen_total_circulacao calculado en el Paso 1. Si las 20 cuentas más ricas concentran, por ejemplo, más del 40% del Zen total, esto ya es señal de desequilibrio que vale la pena investigar — puede ser farm legítimo de jugadores muy dedicados, o puede ser señal de exploit/bot a escala.

Paso 4 — Calculando la tasa de sink de Zen

El "sink" es el Zen que sale de circulación (gastado en NPC, reparación de ítem, tasa de mercado). Si tu emulador no registra esto directamente, una aproximación es comparar el Zen total en dos puntos en el tiempo contra una estimación de generación (drop promedio × jugadores activos):

-- Comparación simple entre dos reportes diarios
SELECT
    d2.report_date,
    d2.zen_total - d1.zen_total AS variacao_zen,
    d2.contas_ativas
FROM eco_report_daily d1
JOIN eco_report_daily d2 ON d2.report_date = d1.report_date + INTERVAL 1 DAY
ORDER BY d2.report_date DESC
LIMIT 30;

Una variación positiva constante y creciente, sin correspondencia con jugadores nuevos, es la señal más directa de inflación en curso.

Paso 5 — Automatizando la ejecución (cron/planificador)

En Linux, programa las consultas vía cron llamando a un script (PHP, Python o incluso un .sql vía mysql -e) que corre las consultas y guarda el resultado en la tabla de historial:

# crontab -e
0 6 * * * /usr/bin/php /var/www/scripts/eco_report_daily.php >> /var/log/mu_eco_report.log 2>&1

El script (eco_report_daily.php) debe: conectarse a la base de datos, correr las consultas del Paso 1 al 4, guardar el resultado en eco_report_daily, y opcionalmente enviar un resumen a un webhook del Discord administrativo.

Paso 6 — Alertas automáticas por umbral

Configura el script para disparar una alerta (webhook de Discord, correo) cuando algún indicador supere un umbral definido:

if ($variacao_percentual_zen > 0.15 && $crescimento_jogadores < 0.05) {
    enviarAlertaDiscord("Alerta de inflación: el Zen creció {$variacao_percentual_zen}% sin crecimiento proporcional de jugadores.");
}

Paso 7 — Transformando datos en decisiones

Un reporte solo tiene valor si lleva a una acción. Establece respuestas estándar para cada señal:

Paso 8 — Reporte semanal consolidado para el equipo

Además de las alertas diarias automáticas, arma un resumen semanal (aunque sea manual, copiando los números del historial) con un gráfico simple de evolución de Zen total, jewels en circulación y cuentas activas. Compartir este resumen con todo el equipo de administración — no solo quien se encarga de la economía — ayuda a que las decisiones relacionadas (eventos, drop de ítems nuevos) consideren el estado actual de la economía.

Errores comunes y soluciones

Lista de verificación de implementación del pipeline de reportes

• Tabla histórica de reportes (eco_report_daily o equivalente) creada.
• Consultas de Zen total, jewels en circulación y concentración de riqueza validadas.
• Logs de drop/mercado habilitados en el emulador, si aún no lo estaban.
• Script de automatización programado vía cron (o equivalente en Windows).
• Alertas configuradas con umbrales calibrados tras un período de observación.
• Proceso de respuesta documentado para cada tipo de alerta.
• Resumen semanal compartido con el equipo de administración.

Con los reportes automáticos monitoreando la salud de la economía, el siguiente paso es usar esos datos para calibrar directamente las tasas de drop y los sistemas de ítems del servidor, cerrando el ciclo entre monitoreo y configuración — un buen punto de partida es revisar las tasas generales en el tutorial de creación de servidor de MU Online.

Preguntas frecuentes