Como configurar o season reset (reinício de temporada) no MU Online

O season reset é um dos rituais mais poderosos e mais perigosos na vida de um servidor de MU Online. Feito bem, ele injeta energia nova: a economia se reequilibra, os rankings voltam a valer alguma coisa, jogadores antigos retornam e os novatos deixam de encarar uma parede intransponível de veteranos. Feito mal, ele destrói meses de confiança em uma única noite, provoca uma onda de chargebacks e transforma um servidor saudável em um cemitério. A diferença entre esses dois destinos quase nunca está no comando de wipe em si, e quase sempre está no planejamento em volta dele. Este tutorial trata o reinício de temporada como o projeto de risco que ele é: decidir o escopo do wipe, blindar os dados com backup verificado, comunicar com a comunidade, desenhar a premiação de fim de temporada e mitigar os riscos técnicos e humanos. Os conceitos de MU são reais; nomes de tabelas, comandos e ferramentas aparecem como exemplo e variam por emulador.

Pré-requisitos

Um season reset toca todas as partes do servidor ao mesmo tempo, então a base precisa estar sólida. Se você ainda está montando o servidor, veja antes o guia de como criar servidor de MU Online e retorne quando a operação estiver estável.

• Acesso administrativo ao banco de dados de produção (MSSQL na maioria dos emuladores).
• Ferramenta de backup e restauração já testada, não apenas configurada.
• Ambiente de staging para ensaiar o reset antes de rodá-lo na produção.
• Janela de manutenção definida, de preferência em horário de baixo movimento.
• Canais de comunicação ativos: site, Discord, redes sociais, mensagem in-game.
• Registro claro do que é conteúdo pago (cash, itens de loja) versus progresso de jogo.
• LogServer operacional para monitorar as primeiras horas da nova temporada.

O item mais importante dessa lista é o ambiente de staging. Nenhum season reset deveria estrear direto na produção. Ensaiar em uma cópia elimina a maior parte dos desastres antes que eles cheguem aos jogadores.

Wipe parcial versus wipe total: escolha o escopo

A primeira decisão define tudo o que vem depois. Não existe resposta universal; existe a resposta certa para a maturidade e o público do seu servidor.

O wipe total zera o progresso de jogo: personagens, itens, zen, resets, níveis, guildas. É o modelo dos servidores que abrem "nova temporada" como se fosse um servidor novo. Ele maximiza a igualdade na largada e atrai retornos, mas queima o vínculo emocional dos veteranos com seus personagens. Servidores jovens ou muito competitivos toleram bem; servidores maduros costumam sofrer.

O wipe parcial preserva parte do que o jogador construiu, zerando apenas o eixo que precisa de reequilíbrio. As combinações mais comuns preservam cosméticos, títulos, conquistas e cash pago, enquanto zeram itens de poder, ranking e economia. É o caminho mais sustentável para servidores com base fiel.

Regra de ouro que atravessa os dois modelos: conteúdo pago com dinheiro real não se zera. Preservar cash e itens de loja é menos uma escolha de design e mais uma medida de sobrevivência contra chargebacks e ações de consumidor.

Backup: a rede de segurança inegociável

Antes de qualquer alteração, o backup completo e verificado. Não o backup automático de rotina; um backup dedicado, feito na janela de manutenção, com o servidor já fechado para novos logins.

1. Feche o servidor para jogadores. Desligue o ConnectServer ou bloqueie novos logins para congelar o estado.
2. Confirme que não há sessões ativas. Um backup tirado com jogadores online pode capturar um estado inconsistente.
3. Gere backup completo do banco de produção. Inclua todas as tabelas, não só as de personagem.
4. Copie os arquivos de configuração e binários do servidor. O estado não vive só no banco.
5. Mova o backup para fora da máquina de produção. Um backup no mesmo disco que morre com a máquina não é backup.
6. Restaure o backup em staging e valide. Esta é a etapa que quase todos pulam e que separa profissionais de amadores. Um backup nunca testado é uma esperança, não uma garantia.

-- Exemplo ilustrativo (varia por emulador e SGBD)
BACKUP DATABASE MuOnline
TO DISK = 'D:\backups\preseason_2026S3.bak'
WITH FORMAT, COPY_ONLY, CHECKSUM;

Guarde o backup pré-reset por tempo generoso, semanas no mínimo. Disputas e pedidos de reversão aparecem depois que a poeira baixa.

Ensaiando o reset em staging

Com o backup restaurado em staging, ensaie o wipe exatamente como pretende rodá-lo na produção. Escreva os comandos ou scripts de wipe uma vez e execute-os na cópia. O objetivo é responder três perguntas antes do dia real: o script apaga o que deveria e nada além disso? O que era para ser preservado continua intacto? Quanto tempo a operação leva? Cronometrar importa porque a janela de manutenção anunciada precisa ser realista.

Um script de wipe é uma sequência de operações destrutivas em ordem cuidadosa. Um esqueleto ilustrativo de wipe parcial:

-- ILUSTRATIVO — nomes de tabela variam por emulador
-- 1) Preservar cash e itens pagos (não tocar nessas tabelas)
-- 2) Zerar itens de poder e inventários de jogo
TRUNCATE TABLE warehouse_items_game;
-- 3) Zerar economia in-game
UPDATE character SET zen = 0;
-- 4) Zerar ranking e progresso competitivo da temporada
UPDATE character SET resets = 0, level = 1, experience = 0;
-- 5) Preservar títulos/conquistas (não tocar)

Nunca rode um bloco desses direto na produção sem tê-lo executado com sucesso em staging. E envolva a operação em transação quando o SGBD permitir, para poder abortar ao primeiro sinal de erro.

Comunicação com a comunidade

A parte técnica do reset é a mais fácil. A parte humana derruba servidores. Um wipe anunciado tarde ou de forma ambígua é lido como traição, especialmente por quem gastou dinheiro. Comunique cedo, com clareza e mais de uma vez.

A mensagem precisa responder, sem rodeios, três perguntas que todo jogador fará: o que eu perco, o que eu mantenho, e o que eu ganho por ter jogado a temporada que acabou. Ambiguidade em qualquer uma delas gera revolta. Deixe explícito, por escrito e em destaque, que cash e itens pagos são preservados.

Premiação de fim de temporada

A premiação transforma o fim de uma temporada de perda em conquista. Ela recompensa quem investiu tempo e dá motivo para competir até o último dia. Baseie as recompensas em conquistas verificáveis dos rankings antes do wipe: top de resets, campeão de Castle Siege, maior mestre de determinada classe, top de eventos.

As recompensas devem sobreviver ao wipe, então normalmente são cosméticos, títulos exclusivos daquela temporada, cash bônus ou itens de loja, justamente as categorias que você preserva. Capture os rankings finais antes de qualquer alteração e guarde essa foto: ela é a base da premiação e também prova, caso alguém conteste o resultado.

-- Congele o ranking final ANTES do wipe
SELECT TOP 10 name, resets, level
INTO SeasonS3_Ranking
FROM character
ORDER BY resets DESC, level DESC;

Sincronizando a largada

A nova temporada deveria começar para todos ao mesmo tempo. Um início escalonado, em que alguns entram antes, dá vantagem injusta e envenena a percepção de justiça logo no primeiro dia. Reabra o servidor em um horário anunciado e mantenha a staff de plantão nas primeiras horas, porque a largada é o momento de maior risco de exploit: bots prontos, contas de reserva e scripts de farm entram todos de uma vez. Reforce o monitoramento dos logs nesse período e esteja pronto para agir rápido.

Riscos e mitigações

Todo season reset carrega riscos previsíveis. Nomeá-los antes é metade da mitigação.

• Perda de dados irreversível. Mitigação: backup verificado por restauração, mantido fora da produção.
• Fuga de veteranos. Mitigação: preferir wipe parcial em servidores maduros e valorizar a premiação de temporada.
• Chargebacks por cash zerado. Mitigação: nunca zerar conteúdo pago e comunicar isso com destaque.
• Exploits na largada. Mitigação: início sincronizado, staff de plantão e monitoramento reforçado de logs.
• Estouro da janela de manutenção. Mitigação: cronometrar o script em staging e anunciar um prazo folgado.
• Script de wipe apagando o que não devia. Mitigação: ensaio em staging e uso de transações que possam ser abortadas.
• Revolta por comunicação tardia. Mitigação: anúncio com semanas de antecedência e lembretes escalonados.

Erros comuns e soluções

Checklist de lançamento

• Escopo do wipe (parcial ou total) decidido e documentado
• Conteúdo pago claramente mapeado e marcado como preservado
• Ambiente de staging com cópia atual da produção
• Script de wipe ensaiado e cronometrado em staging
• Backup completo pré-reset gerado com o servidor fechado
• Backup restaurado e validado em staging
• Backup pré-reset copiado para fora da máquina de produção
• Ranking final da temporada congelado em tabela antes do wipe
• Premiação de temporada definida e baseada em conquistas verificáveis
• Anúncio publicado com 2 a 4 semanas de antecedência
• Lembretes escalonados agendados até a manutenção
• Janela de manutenção anunciada com prazo realista
• Script envolvido em transação abortável quando possível
• Largada sincronizada com horário único de reabertura
• Staff de plantão e logs reforçados nas primeiras horas
• Comunicado de pós-reset pronto com resumo e recompensas

Um season reset bem conduzido é uma renovação, não uma ruptura. Quando o backup está verificado, o escopo é claro, a comunicação chega cedo e a temporada que termina é celebrada com premiação, o wipe deixa de ser um risco de morte e vira o motor que mantém o servidor vivo temporada após temporada.

Perguntas frequentes