Como implementar notificações push no app mobile do seu servidor de MU Online

Notificações push transformam o portal ou app do seu servidor de MU Online em um canal de comunicação em tempo real, capaz de avisar o jogador sobre o início de um Castle Siege, a abertura de um evento raro ou uma promoção relâmpago na loja — mesmo com o navegador ou app fechado. Diferente de e-mail ou Discord, o push chega instantaneamente na tela do dispositivo, com taxa de atenção muito mais alta. Implementar isso corretamente exige integrar Firebase Cloud Messaging, configurar um Service Worker no PWA, conectar eventos reais do servidor de jogo a gatilhos de envio, e sobretudo respeitar a preferência do jogador para não gerar cancelamento em massa da permissão. Este tutorial cobre a implementação completa, do zero até a integração com eventos do GameServer.

Por que push notification e não só e-mail ou Discord

Cada canal de comunicação tem um papel diferente na retenção de jogadores. E-mail é assíncrono e bom para conteúdo mais longo (patch notes, resumos semanais); Discord depende do jogador estar com notificações ativas naquele servidor específico; push chega direto na tela de bloqueio do celular ou como notificação do sistema operacional, com tempo de reação muito mais rápido. Para avisos sensíveis ao tempo — "Castle Siege começa em 10 minutos", "Invasion de Kundun ativa agora" — push é o único canal com chance real de o jogador ver a tempo de agir.

Escolhendo entre PWA e app nativo

Antes de implementar push, defina a plataforma. Para a maioria dos servidores de MU Online, um PWA bem configurado é a escolha mais eficiente:

Para a maioria dos casos, comece com PWA e só avalie app nativo se a base de jogadores em iOS for grande o suficiente para justificar o custo adicional.

Configurando o Firebase Cloud Messaging

O Firebase Cloud Messaging (FCM) é o serviço de envio mais usado por ser gratuito e cobrir Android, iOS e Web. Os passos iniciais de configuração:

1. Criar um projeto no console do Firebase (console.firebase.google.com).
2. Adicionar um app Web ao projeto e copiar as credenciais (apiKey, projectId, messagingSenderId, etc.).
3. Gerar um par de chaves VAPID na aba de Cloud Messaging, necessário para Web Push.
4. Instalar o SDK no projeto do site (npm install firebase).

Exemplo de configuração inicial em um projeto Next.js:

// lib/firebase.js
import { initializeApp } from 'firebase/app';
import { getMessaging, getToken, onMessage } from 'firebase/messaging';

const firebaseConfig = {
  apiKey: process.env.NEXT_PUBLIC_FIREBASE_API_KEY,
  projectId: process.env.NEXT_PUBLIC_FIREBASE_PROJECT_ID,
  messagingSenderId: process.env.NEXT_PUBLIC_FIREBASE_SENDER_ID,
  appId: process.env.NEXT_PUBLIC_FIREBASE_APP_ID,
};

const app = initializeApp(firebaseConfig);
export const messaging = typeof window !== 'undefined' ? getMessaging(app) : null;

Registrando o Service Worker

O push só funciona com um Service Worker registrado, responsável por receber a notificação mesmo com a aba/app fechado:

// public/firebase-messaging-sw.js
importScripts('https://www.gstatic.com/firebasejs/10.7.0/firebase-app-compat.js');
importScripts('https://www.gstatic.com/firebasejs/10.7.0/firebase-messaging-compat.js');

firebase.initializeApp({
  apiKey: 'SUA_API_KEY',
  projectId: 'SEU_PROJECT_ID',
  messagingSenderId: 'SEU_SENDER_ID',
  appId: 'SEU_APP_ID',
});

const messaging = firebase.messaging();

messaging.onBackgroundMessage((payload) => {
  self.registration.showNotification(payload.notification.title, {
    body: payload.notification.body,
    icon: '/icons/icon-192.png',
  });
});

Esse arquivo precisa ficar na raiz pública do site (public/firebase-messaging-sw.js), acessível diretamente pela URL, para o navegador conseguir registrá-lo.

Solicitando permissão do jogador corretamente

Pedir permissão de notificação assim que o jogador entra no site pela primeira vez é o erro mais comum e a principal causa de rejeição. A abordagem correta é contextual:

• Espere o jogador realizar uma ação relevante (ex.: se cadastrar, visitar a página de eventos) antes de pedir permissão.
• Explique o valor antes do prompt nativo do navegador: um pequeno banner "Quer ser avisado quando o Castle Siege começar? Ative as notificações" antes de chamar a API real de permissão.
• Nunca peça novamente de forma insistente se o jogador negar — respeite a escolha e ofereça a opção de ativar depois nas configurações do perfil.

async function solicitarPermissao() {
  const permissao = await Notification.requestPermission();
  if (permissao === 'granted') {
    const token = await getToken(messaging, { vapidKey: 'SUA_VAPID_KEY' });
    // enviar token para o backend, associado ao jogador logado
    await fetch('/api/push/registrar', {
      method: 'POST',
      body: JSON.stringify({ token }),
    });
  }
}

Segmentando notificações por tipo de evento

Assim como na newsletter, notificar tudo para todo mundo gera cansaço e cancelamento de permissão. Estruture categorias que o jogador pode escolher:

Guarde a preferência de cada jogador (quais categorias aceitou) em uma tabela do banco de dados do site, vinculada ao token de push, e sempre segmente o envio por essa preferência.

Integrando eventos reais do GameServer ao disparo

A parte mais poderosa (e mais trabalhosa) é conectar o próprio GameServer ao sistema de push, para notificar o momento exato em que um evento de jogo começa, não um horário fixo aproximado. Uma arquitetura comum:

1. Um pequeno serviço intermediário monitora os logs do GameServer ou consulta o banco de dados do jogo periodicamente (a cada 10-30 segundos), procurando pela mudança de estado de eventos (ex.: coluna EventStatus na tabela de configuração de evento).
2. Ao detectar que um evento mudou de "fechado" para "aberto", esse serviço chama a API do backend do site.
3. O backend do site consulta a tabela de tokens de push segmentados pela categoria correspondente e envia a notificação via API do Firebase Admin SDK.

Exemplo simplificado do disparo no backend, usando Firebase Admin:

// server: dispara notificação quando o serviço detecta evento aberto
const admin = require('firebase-admin');

async function notificarEvento(categoria, titulo, corpo) {
  const tokens = await buscarTokensPorCategoria(categoria); // consulta ao banco
  await admin.messaging().sendEachForMulticast({
    tokens,
    notification: { title: titulo, body: corpo },
  });
}

// exemplo de chamada quando o serviço detecta Devil Square aberto
notificarEvento('eventos_pve', 'Devil Square está aberto!', 'Corra para participar antes que feche.');

Testando em diferentes plataformas

Antes de lançar para todos os jogadores, teste o fluxo completo em cada ambiente-alvo:

• Android (Chrome): suporte completo, teste com o app/PWA em segundo plano e totalmente fechado.
• iOS (Safari): exige que o jogador tenha instalado o PWA na tela inicial (Adicionar à Tela de Início); push não funciona apenas pelo navegador aberto normalmente.
• Desktop (Chrome/Edge/Firefox): suporte completo, útil para jogadores que acompanham pelo computador.

Documente as limitações do iOS claramente para os jogadores no próprio site, evitando tickets de suporte de quem não conseguiu ativar por não ter instalado o PWA corretamente.

Erros comuns e soluções

Checklist de notificações push

• Decisão tomada entre PWA e app nativo, conforme base de jogadores.
• Projeto Firebase configurado com chaves VAPID geradas.
• Service Worker registrado e acessível na raiz pública do site.
• Fluxo de solicitação de permissão contextual implementado.
• Categorias de notificação definidas e preferências salvas por jogador.
• Integração entre eventos reais do GameServer e o disparo de push.
• Testes realizados em Android, iOS (PWA instalado) e desktop.

Com o push funcionando de ponta a ponta, o servidor ganha um canal de comunicação em tempo real que complementa e-mail e Discord — vale revisar o tutorial de como criar um servidor de MU Online para garantir que a infraestrutura de backend suporta essa integração com o GameServer sem gargalos de performance.

Perguntas frequentes