Como criar um sistema de badges de conquistas para o site de MU Online

Um sistema de badges de conquistas transforma o progresso do jogador em algo visível e compartilhável, aumentando o tempo de engajamento e dando aos jogadores um motivo extra para voltar além do grind puro de level e itens. Diferente de conquistas dentro do próprio jogo (que exigiriam mexer no emulador), um sistema de badges no site/painel pode ser construído inteiramente em cima do banco de dados existente, sem alterar o GameServer. Este tutorial cobre o desenho de badges, a lógica de verificação automática e a exibição no perfil.

Conceito e objetivo do sistema

Badges são selos visuais atribuídos a um jogador quando ele cumpre um critério específico — "Chegar ao Reset 100", "Vencer 50 duelos PvP", "Fazer parte do Top 5 da guild vencedora do Castle Siege", "Doar para o servidor por 6 meses seguidos". Eles aparecem no perfil público do jogador no site, no ranking, e opcionalmente no próprio jogo (como um título, se o emulador suportar). O objetivo é dar reconhecimento social a conquistas que já existem nos dados do jogo, sem exigir nenhuma mudança no servidor em si.

Categorias de badges recomendadas

Comece com 4-6 badges por categoria (total de 15-25) para lançar com profundidade sem sobrecarregar o jogador novo.

Modelo de dados

CREATE TABLE badges (
  id INT PRIMARY KEY AUTO_INCREMENT,
  code VARCHAR(40) UNIQUE NOT NULL,
  name VARCHAR(80) NOT NULL,
  description VARCHAR(255),
  category VARCHAR(40),
  icon_url VARCHAR(255),
  rarity ENUM('comum','raro','epico','lendario') DEFAULT 'comum'
);

CREATE TABLE account_badges (
  id INT PRIMARY KEY AUTO_INCREMENT,
  account_id INT NOT NULL,
  badge_id INT NOT NULL,
  unlocked_at DATETIME DEFAULT CURRENT_TIMESTAMP,
  UNIQUE KEY unique_badge (account_id, badge_id)
);

A chave única em account_badges impede duplicação de badge para a mesma conta, mesmo se o job de verificação rodar mais de uma vez sobre o mesmo dado.

Regras de desbloqueio automático

Cada badge precisa de uma regra que um job periódico consegue avaliar consultando o banco. Exemplos de regra em pseudo-SQL:

-- Badge "Reset 100"
SELECT AccountID FROM Character WHERE ResetCount >= 100;

-- Badge "50 vitorias em duelo"
SELECT AccountID FROM DuelStats WHERE Wins >= 50;

-- Badge "Doador Ouro" (acumulado de recargas)
SELECT AccountID FROM Payments
GROUP BY AccountID HAVING SUM(Amount) >= 500;

O job roda essas consultas periodicamente (a cada hora ou a cada login), compara com quem já possui o badge e insere as novas concessões em account_badges.

Job de verificação (worker periódico)

<?php
// check_badges.php - roda via cron a cada 30 minutos
$badges = getBadgeRules(); // array com code => query SQL
foreach ($badges as $code => $query) {
    $eligibleAccounts = $db->query($query);
    foreach ($eligibleAccounts as $accountId) {
        $db->query(
            "INSERT IGNORE INTO account_badges (account_id, badge_id)
             SELECT ?, id FROM badges WHERE code = ?",
            [$accountId, $code]
        );
    }
}

O INSERT IGNORE combinado com a chave única evita erro em caso de badge já concedido, simplificando a lógica sem precisar de um SELECT de verificação prévio.

Exibição no perfil e no ranking

No perfil público do jogador, exiba os badges como ícones em grade, com tooltip mostrando nome, descrição e data de desbloqueio. No ranking geral, um pequeno indicador (ex. contagem de badges ou o badge mais raro) ajuda a destacar jogadores completistas sem poluir a tabela principal. Badges lendárias/épicas devem ter destaque visual diferenciado (borda dourada, animação sutil) para reforçar a raridade.

Retroatividade de badges lançadas depois

Ao lançar uma badge nova, rode o job de verificação sobre o histórico completo (não só dados novos a partir de hoje), para que veteranos que já cumpriram o requisito antes do lançamento recebam a badge imediatamente. A exceção são badges de "pioneirismo" (ex. "Primeiro a chegar ao Reset 200") — essas não podem ser aplicadas retroativamente de forma justa e devem ser tratadas como eventos únicos monitorados em tempo real.

Badges como incentivo, não como pay-to-win

É tentador amarrar bônus reais de gameplay a um badge (ex. +5% de dano por badge). Evite isso: badges devem ser puramente cosméticas/sociais. Se badges puderem ser compradas diretamente (ex. "Doador Ouro" badge é justo, mas "badge de +dano" comprado não é), você cria uma percepção de pay-to-win que prejudica a reputação do servidor entre jogadores competitivos.

Notificações de desbloqueio

Quando o job concede uma badge nova, dispare uma notificação (painel do site, e opcionalmente webhook para o Discord) anunciando a conquista. Isso aumenta a visibilidade do sistema e incentiva outros jogadores a perseguir os mesmos badges — especialmente eficaz para badges raras conquistadas por poucos jogadores.

Antifraude e critérios sustentados

Para badges de guild ou ranking, prefira critérios que exigem atividade sustentada por um período (ex. "vencer 3 Castle Siege seguidos") em vez de um pico isolado, o que reduz a chance de manipulação via conta secundária ou evento pontual manipulado. Cruze com dados de IP/hardware já usados no antifraude geral do servidor quando disponível.

Erros comuns e soluções

Checklist de lançamento

• Tabelas de badges e concessões criadas com chave única.
• 15-25 badges definidos cobrindo categorias variadas.
• Regras de desbloqueio escritas como consultas testadas contra o banco real.
• Job periódico configurado via cron e validado.
• Exibição no perfil e no ranking implementada.
• Notificação de desbloqueio (painel/Discord) funcionando.
• Badges revisadas para garantir que nenhuma dá vantagem de gameplay real.

Com o sistema de badges no ar, ele complementa muito bem outras iniciativas de retenção e comunidade do servidor — para revisar a base de dados e infraestrutura sobre a qual esse sistema é construído, veja o guia de como criar um servidor de MU Online.

Perguntas frequentes