A recomendação padrão para lancamento de jogo e ligar a proteção no maximo alguns dias antes. Faz sentido no papel: vai entrar muita gente de uma vez, e muita gente entrando de uma vez e o que um sistema anti invasão existe para barrar.
O problema é que pico de lancamento e invasão coordenada são, para qualquer proteção automática, a mesma coisa: várias contas novas entrando no mesmo minuto. Com a proteção rigida, o servidor começa a expulsar jogador de verdade no dia em que mais gente quis entrar — e isso falha em silêncio, porque quem foi barrado não esta la para reclamar.
Daí sai a regra que organiza o resto do preparo: quase todo trabalho de lancamento e feito antes, escrevendo. Quem digita no dia, perde.
O que se prepara antes e o que se paga depois
| Decisão | Consequencia no dia |
|---|---|
| Proteção no nível maximo | jogador legítimo barrado, e ninguém fica sabendo |
| Verificação com formulário longo | desistencia no pico, quando a paciência e menor |
| Cargo dado na mão | a equipe passa o lancamento distribuindo cargo |
| Respostas prontas escritas antes | a mesma dúvida vira um link em vez de cem respostas |
| Canal de status separado | queda do jogo não transforma o bate-papo em revolta |
Vale repetir o item mais ignorado: a maior parte das mensagens do dia do lancamento e a mesma pergunta. Se ela já tem resposta escrita, a moderação responde com um link e sobrevive. Se não tem, três pessoas digitam a mesma coisa por doze horas e param de conseguir olhar o resto.
As duas semanas antes
- 1
Escreva o canal de dúvidas frequentes antes de precisar dele
Requisito de maquina, onde comprar, como resgatar a chave, o que fazer se o jogo não abre, quando sai a versão de outra plataforma. Dez perguntas cobrem a maioria esmagadora do volume, e cada uma escrita antes vale por horas de moderação no dia.
- 2
Calibre a proteção com folga, não no maximo
Deixe a proteção pegando o comportamento claramente automatizado — conta criada no dia, mesma mensagem repetida, link em massa — e não o simples volume de entradas. E confira se existe registro de quem foi barrado, senao você não tera como saber se ela errou.
- 3
Troque a verificação longa por uma de um clique
Um botão de concordo com as regras filtra quase tudo que é automatizado e custa três segundos para uma pessoa. Formulário com perguntas abertas no dia do pico filtra principalmente gente com pressa, que e a maioria de quem chega pelo lancamento.
- 4
Deixe o cargo de entrada automático
Cargo na entrada, sem ninguém no meio. E o que impede a equipe de virar linha de produção de cargo justamente no dia em que ela precisa estar lendo o canal de bugs e o de suporte.
- 5
Monte a escala de moderação por hora, com nome
Lancamento não tem hora comercial: ele começa em um fuso e continua no outro. Duas pessoas por turno, com turno definido, evita o cenário mais comum, que e todo mundo estar acordado nas primeiras seis horas e ninguém nas dezoito seguintes.
- 6
Crie os canais de bug, de status e de suporte individual
Bug no bate-papo se perde e chega na equipe como boato. Bug em canal próprio, com um formato pedido, chega utilizável. Status separado permite avisar queda sem competir com a conversa, e o caso individual, como compra e chave, pede atendimento fechado e não canal público.
Contagem regressiva no nome do canal não funciona bem
A ideia aparece em todo guia: um canal de voz chamado Faltam 3 dias, atualizando sozinho. Na pratica o Discord limita quantas vezes um canal pode ser renomeado num intervalo curto — hoje, poucas vezes a cada dez minutos —, então um contador de minutos simplesmente para de atualizar e fica exibindo um número errado. Para dias, funciona. Para a contagem final, prefira uma mensagem fixa que você edita, ou o evento agendado do próprio Discord, que já mostra o tempo restante e avisa quem marcou interesse.
As primeiras quarenta e oito horas
- 1Uma pessoa só olhando o canal de bugs, sem responder bate-papo. Triagem e trabalho de foco, e some quando a mesma pessoa esta apagando incendio.
- 2Mensagem fixa de status atualizada de hora em hora, mesmo quando não há novidade. O silêncio e lido como descaso, e o boato preenche o espaço vazio.
- 3Resposta pronta para o caso de compra e chave, e ticket para o resto. Assunto de dinheiro em canal público vira discussão publica em minutos.
- 4Limite de link e de mensagem repetida ligado. Lancamento atrai divulgação de terceiro e golpe de chave falsa, sempre.
- 5Registro do que for apagado e de quem for expulso. No dia seguinte alguém vai perguntar, e memoria de moderador cansado não serve de resposta.
Depois do pico
Boa parte vai embora, e isso e normal — não é sinal de que o servidor falhou. O erro e olhar o número de entradas do primeiro dia e concluir qualquer coisa a partir dele. O número que diz algo e quantas pessoas ainda estavam conversando na segunda semana, quando a curiosidade acabou e sobrou quem realmente joga.
E esse grupo menor que sustenta o servidor até a próxima atualização. O que segura são motivos de voltar: nota de versão comentada, evento com hora marcada, um canal onde a equipe responde de verdade. Servidor de lancamento que vira mural de nota de atualização esvazia antes do primeiro patch grande.
O que não fazer
- ●Não abra canal por plataforma, por idioma e por região antes de saber se há gente para todos. Dividir cedo transforma um servidor movimentado em dez canais parados.
- ●Não prometa prazo de correção no calor do dia. Prazo dado por moderação vira promessa da empresa, e não cumprir custa mais que não responder.
- ●Não apague reclamação só por ser negativa. Apagar critica valida cria um assunto novo e pior, que e a moderação censurando.
- ●Não deixe a proteção no maximo depois que o pico passar sem revisar. Ajuste feito as pressas no dia do lancamento costuma ficar ligado por meses.
- ●Não dependa de uma pessoa que sabe tudo. No lancamento, alguém sempre dorme, e o conhecimento precisa estar escrito em algum lugar.
No lancamento, a maior parte das mensagens e a mesma pergunta. Quem prepara resposta pronta sobrevive; quem responde tudo na hora, não.
Perguntas frequentes
Devo ligar a proteção no maximo no dia do lancamento?
Não. Pico de entrada e invasão se parecem demais para qualquer proteção automática, e no maximo ela começa a barrar jogador de verdade. O ajuste útil pega comportamento, como conta criada no dia mandando link ou mensagem repetida, e não o volume de entradas. E precisa deixar registro de quem foi barrado.
Qual verificação usar quando entram centenas de pessoas?
A mais curta que resolva. Um botão de concordar com as regras barra quase todo processo automatizado e custa segundos. Formulário com pergunta aberta e bom para comunidade fechada e ruim no pico, porque filtra principalmente quem tem pressa, que e a maior parte de quem chega no lancamento.
Preciso de um canal separado só para bugs?
Precisa, e de preferencia com um formato pedido na descrição: o que aconteceu, o que você esperava, e a maquina ou console. Bug relatado no bate-papo chega na equipe como boato, sem passo para reproduzir, e some em minutos no volume do dia.
Como avisar que o jogo caiu sem virar tumulto?
Com um canal de status só de leitura e uma mensagem fixa atualizada de hora em hora, mesmo sem novidade. Sem esse canal, o aviso compete com a conversa e o bate-papo vira reclamação. A parte que mais importa e a frequência: silêncio longo produz boato mais rápido que qualquer noticia ruim.
Quantos moderadores um lancamento precisa?
Menos do que o número de membros sugere e mais turnos do que se costuma planejar. Duas pessoas acordadas a qualquer hora resolvem mais que dez todas no mesmo fuso. Monte a escala por hora, com nome, antes do dia — no dia ninguém tem cabeca para combinar isso.
Sorteio de chave vale a pena antes do lancamento?
Traz gente rápido e traz o público errado se for a única coisa acontecendo. Boa parte entra pelo sorteio e sai no dia do resultado. Funciona melhor como acrescimo a um servidor que já tem conversa, e vem acompanhado de aviso: sorteio e alvo preferido de golpe de chave falsa nas mensagens privadas.