Cómo configurar el season reset (reinicio de temporada) en MU Online

El season reset es uno de los rituales más poderosos y más peligrosos en la vida de un servidor de MU Online. Bien hecho, inyecta energía nueva: la economía se reequilibra, los rankings vuelven a valer algo, los jugadores antiguos retornan y los novatos dejan de enfrentar un muro infranqueable de veteranos. Mal hecho, destruye meses de confianza en una sola noche, provoca una ola de chargebacks y transforma un servidor sano en un cementerio. La diferencia entre esos dos destinos casi nunca está en el comando de wipe en sí, y casi siempre está en la planificación a su alrededor. Este tutorial trata el reinicio de temporada como el proyecto de riesgo que es: decidir el alcance del wipe, blindar los datos con un backup verificado, comunicar con la comunidad, diseñar la premiación de fin de temporada y mitigar los riesgos técnicos y humanos. Los conceptos de MU son reales; los nombres de tablas, comandos y herramientas aparecen como ejemplo y varían según el emulador.

Requisitos previos

Un season reset toca todas las partes del servidor al mismo tiempo, así que la base debe estar sólida. Si todavía estás montando el servidor, revisa antes la guía de cómo crear un servidor de MU Online y regresa cuando la operación esté estable.

• Acceso administrativo a la base de datos de producción (MSSQL en la mayoría de los emuladores).
• Herramienta de backup y restauración ya probada, no solo configurada.
• Ambiente de staging para ensayar el reset antes de ejecutarlo en producción.
• Ventana de mantenimiento definida, de preferencia en horario de bajo movimiento.
• Canales de comunicación activos: sitio, Discord, redes sociales, mensaje in-game.
• Registro claro de qué es contenido pago (cash, ítems de tienda) versus progreso de juego.
• LogServer operativo para monitorear las primeras horas de la nueva temporada.

El ítem más importante de esa lista es el ambiente de staging. Ningún season reset debería estrenarse directo en producción. Ensayar en una copia elimina la mayor parte de los desastres antes de que lleguen a los jugadores.

Wipe parcial versus wipe total: elige el alcance

La primera decisión define todo lo que viene después. No existe una respuesta universal; existe la respuesta correcta para la madurez y el público de tu servidor.

El wipe total pone en cero el progreso de juego: personajes, ítems, zen, resets, niveles, guildas. Es el modelo de los servidores que abren una "nueva temporada" como si fuera un servidor nuevo. Maximiza la igualdad en la largada y atrae retornos, pero quema el vínculo emocional de los veteranos con sus personajes. Los servidores jóvenes o muy competitivos lo toleran bien; los servidores maduros suelen sufrir.

El wipe parcial preserva parte de lo que el jugador construyó, poniendo en cero solo el eje que necesita reequilibrio. Las combinaciones más comunes preservan cosméticos, títulos, logros y cash pagado, mientras ponen en cero ítems de poder, ranking y economía. Es el camino más sostenible para servidores con base fiel.

Regla de oro que atraviesa ambos modelos: el contenido pagado con dinero real no se pone en cero. Preservar cash e ítems de tienda es menos una elección de diseño y más una medida de supervivencia contra chargebacks y acciones de consumidor.

Backup: la red de seguridad innegociable

Antes de cualquier cambio, el backup completo y verificado. No el backup automático de rutina; un backup dedicado, hecho en la ventana de mantenimiento, con el servidor ya cerrado a nuevos logins.

1. Cierra el servidor a los jugadores. Apaga el ConnectServer o bloquea nuevos logins para congelar el estado.
2. Confirma que no hay sesiones activas. Un backup tomado con jugadores en línea puede capturar un estado inconsistente.
3. Genera un backup completo de la base de producción. Incluye todas las tablas, no solo las de personaje.
4. Copia los archivos de configuración y binarios del servidor. El estado no vive solo en la base de datos.
5. Mueve el backup fuera de la máquina de producción. Un backup en el mismo disco que muere con la máquina no es un backup.
6. Restaura el backup en staging y valídalo. Esta es la etapa que casi todos saltan y que separa a los profesionales de los aficionados. Un backup nunca probado es una esperanza, no una garantía.

-- Ejemplo ilustrativo (varía según el emulador y el SGBD)
BACKUP DATABASE MuOnline
TO DISK = 'D:\backups\preseason_2026S3.bak'
WITH FORMAT, COPY_ONLY, CHECKSUM;

Guarda el backup previo al reset por un tiempo generoso, semanas como mínimo. Las disputas y pedidos de reversión aparecen después de que baja el polvo.

Ensayando el reset en staging

Con el backup restaurado en staging, ensaya el wipe exactamente como pretendes ejecutarlo en producción. Escribe los comandos o scripts de wipe una vez y ejecútalos en la copia. El objetivo es responder tres preguntas antes del día real: ¿el script borra lo que debería y nada más? ¿Lo que debía preservarse sigue intacto? ¿Cuánto tiempo lleva la operación? Cronometrar importa porque la ventana de mantenimiento anunciada debe ser realista.

Un script de wipe es una secuencia de operaciones destructivas en un orden cuidadoso. Un esqueleto ilustrativo de wipe parcial:

-- ILUSTRATIVO — los nombres de tabla varían según el emulador
-- 1) Preservar cash e ítems pagados (no tocar estas tablas)
-- 2) Poner en cero ítems de poder e inventarios de juego
TRUNCATE TABLE warehouse_items_game;
-- 3) Poner en cero la economía in-game
UPDATE character SET zen = 0;
-- 4) Poner en cero ranking y progreso competitivo de la temporada
UPDATE character SET resets = 0, level = 1, experience = 0;
-- 5) Preservar títulos/logros (no tocar)

Nunca ejecutes un bloque así directo en producción sin haberlo ejecutado con éxito en staging. Y envuelve la operación en una transacción cuando el SGBD lo permita, para poder abortar al primer signo de error.

Comunicación con la comunidad

La parte técnica del reset es la más fácil. La parte humana derriba servidores. Un wipe anunciado tarde o de forma ambigua se lee como traición, especialmente por quien gastó dinero. Comunica temprano, con claridad y más de una vez.

El mensaje debe responder, sin rodeos, tres preguntas que todo jugador hará: qué pierdo, qué mantengo y qué gano por haber jugado la temporada que terminó. La ambigüedad en cualquiera de ellas genera revuelta. Deja explícito, por escrito y destacado, que el cash y los ítems pagados se preservan.

Premiación de fin de temporada

La premiación transforma el fin de una temporada de pérdida en logro. Recompensa a quien invirtió tiempo y da motivo para competir hasta el último día. Basa las recompensas en logros verificables de los rankings antes del wipe: top de resets, campeón de Castle Siege, mayor maestro de determinada clase, top de eventos.

Las recompensas deben sobrevivir al wipe, así que normalmente son cosméticos, títulos exclusivos de esa temporada, cash bonus o ítems de tienda, justamente las categorías que preservas. Captura los rankings finales antes de cualquier cambio y guarda esa foto: es la base de la premiación y también prueba, en caso de que alguien impugne el resultado.

-- Congela el ranking final ANTES del wipe
SELECT TOP 10 name, resets, level
INTO SeasonS3_Ranking
FROM character
ORDER BY resets DESC, level DESC;

Sincronizando la largada

La nueva temporada debería comenzar para todos al mismo tiempo. Un inicio escalonado, en el que algunos entran antes, da una ventaja injusta y envenena la percepción de justicia ya en el primer día. Reabre el servidor en un horario anunciado y mantén al staff de guardia en las primeras horas, porque la largada es el momento de mayor riesgo de exploit: bots listos, cuentas de reserva y scripts de farm entran todos de una vez. Refuerza el monitoreo de los logs en ese período y prepárate para actuar rápido.

Riesgos y mitigaciones

Todo season reset carga riesgos previsibles. Nombrarlos antes es la mitad de la mitigación.

• Pérdida de datos irreversible. Mitigación: backup verificado por restauración, mantenido fuera de producción.
• Fuga de veteranos. Mitigación: preferir wipe parcial en servidores maduros y valorar la premiación de temporada.
• Chargebacks por cash en cero. Mitigación: nunca poner en cero el contenido pagado y comunicarlo de forma destacada.
• Exploits en la largada. Mitigación: inicio sincronizado, staff de guardia y monitoreo reforzado de logs.
• Desborde de la ventana de mantenimiento. Mitigación: cronometrar el script en staging y anunciar un plazo holgado.
• Script de wipe borrando lo que no debía. Mitigación: ensayo en staging y uso de transacciones que puedan abortarse.
• Revuelta por comunicación tardía. Mitigación: anuncio con semanas de antelación y recordatorios escalonados.

Errores comunes y soluciones

Lista de verificación de lanzamiento

• Alcance del wipe (parcial o total) decidido y documentado
• Contenido pagado claramente mapeado y marcado como preservado
• Ambiente de staging con copia actual de producción
• Script de wipe ensayado y cronometrado en staging
• Backup completo previo al reset generado con el servidor cerrado
• Backup restaurado y validado en staging
• Backup previo al reset copiado fuera de la máquina de producción
• Ranking final de la temporada congelado en una tabla antes del wipe
• Premiación de temporada definida y basada en logros verificables
• Anuncio publicado con 2 a 4 semanas de antelación
• Recordatorios escalonados agendados hasta el mantenimiento
• Ventana de mantenimiento anunciada con un plazo realista
• Script envuelto en una transacción abortable cuando sea posible
• Largada sincronizada con un único horario de reapertura
• Staff de guardia y logs reforzados en las primeras horas
• Comunicado post-reset listo con resumen y recompensas

Un season reset bien conducido es una renovación, no una ruptura. Cuando el backup está verificado, el alcance es claro, la comunicación llega temprano y la temporada que termina se celebra con premiación, el wipe deja de ser un riesgo de muerte y se convierte en el motor que mantiene al servidor vivo temporada tras temporada.

Preguntas frecuentes