Cómo configurar el Muun System (monturas y pets modernos) en MU Online

El Muun System es la evolución moderna del antiguo Pet System de MU Online. Introducido en las seasons más recientes, sustituye la lógica simple de "un pet, un bono" por un ecosistema de criaturas coleccionables que actúan como compañeros (pets) y como monturas (mounts), con combinación, evolución e integración directa con eventos y tienda. Para el administrador, el Muun es al mismo tiempo una herramienta poderosa de retención y una fuente real de desequilibrio si se configura sin criterio. Esta guía cubre el ciclo completo de habilitar, combinar, balancear e integrar el Muun System en tu servidor.

Como siempre, un aviso: los nombres de archivos, tablas, columnas e IDs citados aquí son ejemplos del estándar que la mayoría de los emuladores de seasons modernas adopta. La implementación real varía según el emulador — algunos guardan todo en SQL con panel web, otros en archivos de configuración. Trata los ejemplos como mapa conceptual y valida cada campo en la documentación de tu emulador.

Prerrequisitos

El Muun System depende de una base de servidor de season moderna ya funcional. Si tu infraestructura aún no está de pie, empieza por la guía de cómo crear un servidor de MU Online antes de avanzar.

Vas a necesitar:

• Servidor de season compatible con Muun (GameServer moderno, ConnectServer, base de datos en el aire).
• Acceso a las tablas/archivos de Muun: definición de criaturas, bonos por Muun, recetas de combinación y vínculo con eventos.
• Cliente de la misma season, con los modelos y efectos de los Muuns instalados.
• Cliente de base de datos (HeidiSQL/SSMS) para editar tablas, si el emulador usa SQL.
• Cuenta de GM con comando para generar Muuns y forzar evolución en prueba.
• Backup completo de la base de datos y de los archivos antes de cualquier cambio.

Ten también una planilla a mano para registrar cada Muun, su tipo, sus bonos y su fuente de obtención. Sin ese inventario, el balance se vuelve adivinanza.

Cómo se organiza el Muun System

El Muun System trabaja con tres conceptos centrales que necesitas dominar antes de editar cualquier valor:

1. Muun de compañía (pet). Se queda al lado del personaje y aplica bonos pasivos (daño, defensa, EXP, tasa de drop, resistencias). Ocupa el slot de pet Muun.
2. Muun de montura (mount). El personaje se sube en él; ofrece movilidad y bonos, y ocupa el slot de montura. Algunos Muuns sirven solo como montura, otros solo como pet, y algunos hacen ambos.
3. Evolución y combinación. Los Muuns pueden combinarse para generar versiones superiores y, en muchas seasons, ganan experiencia propia y suben de nivel, aumentando los bonos.

La gran diferencia con el pet clásico es el sistema de slots dobles: el jugador normalmente puede tener un Muun de pet y un Muun de montura activos simultáneamente. Esto significa que los bonos se apilan, y es exactamente ahí donde reside el riesgo de desequilibrio. Antes de definir cualquier número, mapea cuántos slots ofrece tu emulador y cuáles bonos pueden coexistir.

Habilitando y definiendo Muuns en el servidor

El primer paso práctico es garantizar que cada Muun exista y esté activo en la tabla de definición. En emuladores modernos, esto suele ser una tabla SQL (algo como MuunList, T_Muun o PetMuun) o un archivo de configuración dedicado. Cada Muun define, como mínimo:

• ID del Muun (único).
• Tipo: pet, mount, o ambos.
• Nombre y referencia de modelo (para el cliente).
• Bonos aplicados cuando está activo.
• Política de durabilidad/expiración: permanente o temporal.

Ejemplo conceptual de una entrada de Muun (ilustrativo):

[Muun_101]
Name       = "Little Fox"
Type       = Pet
Model      = 101
BonusExp   = 10        ; +10% EXP
BonusDrop  = 5         ; +5% drop
Evolvable  = 1
Expire     = 0         ; permanente

Puntos de verificación al habilitar cada Muun:

• El ID y el modelo coinciden con el cliente. Un Muun sin modelo en el cliente genera una criatura invisible o un crash.
• El tipo está correcto: un Muun marcado como mount sin soporte de montura en el cliente no renderiza la animación.
• Los bonos están dentro del rango que planeaste. No copies valores de otro servidor sin revisar.
• La política de expiración está definida. Un Muun de evento sin expiración se vuelve permanente por error.

Combinación y evolución de Muuns

La combinación es el corazón del enganche del Muun System. El jugador reúne Muuns menores y los fusiona para obtener un Muun superior, en un NPC o máquina de combinación específica. La receta define entradas, salida, costo y tasa de éxito.

Flujo típico de combinación:

1. Recolectar los Muuns base por drop, evento o tienda.
2. Llevar al NPC/máquina de combinación de Muun.
3. Insertar los Muuns e ítems auxiliares (joyas, ítems de evento, zen).
4. Ejecutar la combinación sujeta a la tasa de éxito configurada; en caso de éxito, los Muuns base son consumidos y el Muun superior es generado.

En el servidor, la receta vive en una tabla de combinación de Muun (ejemplo MuunCombine). Un bloque conceptual:

[Combine_Fox_to_WhiteFox]
In1   = Muun_101      ; Little Fox
In2   = Muun_101      ; Little Fox
Item  = Jewel_Chaos:1
Zen   = 2000000
Out   = Muun_150      ; White Fox
Rate  = 65

Además de la combinación, muchas seasons implementan evolución por experiencia: el Muun gana EXP al acompañar al personaje en combate y sube de nivel, escalando sus bonos. Si tu emulador soporta esto, habrá tablas de EXP por nivel y de bonos por nivel del Muun. Configura la curva de EXP para que la evolución sea perceptible pero no instantánea, y define el techo de nivel.

Recomendaciones de balance para combinación y evolución:

• Tasas de éxito entre 50% y 70% para combinaciones intermedias mantienen la búsqueda interesante sin generar frustración extrema.
• Curva de EXP creciente: niveles bajos rápidos para dar sensación de progreso, niveles altos lentos para retener al jugador.
• El consumo de los Muuns base debe ser real: sin consumo, no hay economía, y el mercado de Muuns colapsa.

Bonos, apilamiento y balance

Este es el punto más delicado del Muun System. Como pet y montura Muun coexisten, sus bonos se suman entre sí y con las alas, sets y demás fuentes. Sin control, un jugador acumula +EXP, +drop, +daño y +HP de varias capas al mismo tiempo.

Directrices para mantener el equilibrio:

• Define techos globales para bonos sumables, especialmente EXP y drop, si el emulador lo permite. Así, incluso apilando fuentes, existe un límite.
• Diferencia los roles: deja el Muun de pet enfocado en bonos de utilidad (EXP, drop) y el Muun de montura enfocado en combate (daño, HP, velocidad). Esto evita que un único Muun concentre todo.
• Mide el impacto real en farm y PvP con cuentas cobaya antes de liberar. Los números que parecen pequeños en la tabla se vuelven mucho cuando se apilan.
• Separa los Muuns de tienda de los de gameplay. Si los Muuns fuertes solo salen de la tienda paga, el servidor se vuelve pay-to-win; equilibra con fuentes obtenibles jugando.

Integración con eventos y tienda

El Muun System suele ser el principal gancho de eventos y de la economía moderna del servidor. Los Muuns de evento aparecen en campañas estacionales con durabilidad que expira, incentivando la participación. Los Muuns de tienda mueven la monetización. Y los Muuns de drop dan objetivo a quien prefiere jugar en vez de pagar.

Para integrar bien:

1. Registra los Muuns de evento con expiración y vincula su entrega al sistema de recompensas del evento.
2. Define claramente cuáles Muuns son de tienda y ajusta los precios para no desequilibrar el PvP.
3. Distribuye los Muuns de drop en mapas coherentes con la dificultad del bono.
4. Anuncia el origen de cada Muun a los jugadores, evitando la sensación de sistema opaco.

Cuidado especial con los Muuns de evento: por tener expiración, necesitan un mensaje claro de tiempo restante en el cliente, si no el jugador se queja de "desaparición" del bono.

Sincronizando servidor y cliente

Todo Muun necesita existir de ambos lados con ID, modelo y tipo coherentes. El cliente de la season correspondiente debe contener los modelos, texturas y efectos de cada Muun, además de las entradas de nombre. Un Muun personalizado o reskin exige el modelo correspondiente en el patch del cliente.

Flujo seguro:

1. Define/edita el Muun en el servidor.
2. Confirma que el modelo del Muun existe en el cliente.
3. Refleja nombre y tipo en las configuraciones del cliente.
4. Genera el Muun en una cuenta de prueba y valida pet, montura, bonos y evolución.
5. Solo entonces distribuye el patch a los jugadores.

Errores comunes y soluciones

Pruebas de balance

Antes de liberar, arma un escenario de prueba con una cuenta cobaya por clase principal y combina las peores (mejores) situaciones de apilamiento: pet Muun + montura Muun + alas + set. Mide EXP/hora en farm, daño en PvP y supervivencia. Si el resultado vuelve al Muun obligatorio para competir, reduce los bonos o aplica un techo. El objetivo es que los Muuns fuertes sean una ventaja, no una exigencia para existir en el servidor.

Prueba también la economía de combinación: ¿cuántos Muuns base y cuánto tiempo para llegar a un Muun de tope? Calibra para que la jornada sea de semanas, no de horas, y para que exista un mercado activo de Muuns entre jugadores.

Lista de verificación de lanzamiento

• Backup completo de la base de datos y de los archivos antes de editar
• Todos los Muuns registrados con ID, tipo y modelo verificados
• Modelos y efectos de los Muuns presentes en el patch del cliente
• Bonos de cada Muun documentados en planilla
• Slots de pet y montura Muun validados (coexistencia intencional)
• Recetas de combinación con IDs, costos y tasas revisados
• Curva de EXP y bonos por nivel definida (si hay evolución)
• Techos globales de EXP/drop configurados cuando sea posible
• Muuns de evento con expiración y vínculo al sistema de recompensas
• Muuns de tienda con precios que no desequilibran el PvP
• Apilamiento de bonos probado en farm y PvP con cuenta cobaya
• Prueba final de invocación, montura, combinación y evolución aprobada

Preguntas frecuentes