Segundo Plano
Resumo
Define o que acontece quando o jogador manda o app do Conduta para segundo plano (Android/iOS) durante uma partida. O caso é distinto da Reconexão — aqui o app continua vivo no device, só foi deprioritizado pelo SO — então a política aproveita isso para entregar uma volta mais rica: fast-forward das ações que o jogador perdeu, em vez de cair direto no estado atual. O timeout de tolerância é o mesmo do AFK (3 minutos); passado isso, o jogador é tratado como AFK confirmado.
Esta nota registra o que foi decidido na reunião de design do card Definir comportamento em background no mobile (2026-05-06).
Quando o app vai para segundo plano
- O cliente detecta a transição para segundo plano via APIs do SO (Android
onPause/onStop, iOSapplicationDidEnterBackground). - A partida não pausa. Para os outros jogadores, a mesa segue normalmente — fases avançam, votos são apurados, habilidades resolvem.
- O cliente entra em modo de baixo consumo (ver Economia de bateria abaixo) e mantém uma conexão mínima com o servidor para receber os eventos de jogo enquanto puder.
- Visualmente, para os demais jogadores, o jogador em segundo plano não recebe um indicador específico no V1 — ele só aparece como ausente se o timeout estourar e ele cair no fluxo de AFK (carta com ícone de Wi-Fi cortado, ver Reconexão).
Timeout antes de considerar desconexão
- O tempo tolerado em segundo plano é o mesmo do AFK: 3 minutos.
- Se o jogador volta para primeiro plano dentro de 3 min, é recebido com fast-forward (próxima seção). A partida continua para ele.
- Se o jogador não volta dentro de 3 min, ele cai no fluxo de AFK confirmado: kick + reposição por bot, sem ganho de Reputação/XP da partida e +1 report automático em Denúncias (categoria AFK intencional).
- O cronômetro não pausa entre fases (Turnos) — 3 minutos corridos a partir da entrada em segundo plano.
Manter o mesmo timeout do AFK foi uma escolha deliberada: o impacto na mesa é equivalente (jogador não interage), então o limite de tolerância é o mesmo. A janela mais curta de 60s usada em Reconexão vale só para queda de conexão real, onde o cliente não consegue mais conversar com o servidor.
Fast-forward ao voltar
- Ao trazer o app de volta para primeiro plano dentro do timeout, o jogo reproduz as ações perdidas em sequência acelerada, do ponto da saída até o estado atual.
- O fast-forward cobre: animações de fase, mensagens de chat, eventos de votação, mortes, revelações, mensagens de habilidade — toda a narrativa de mesa que o jogador teria visto se estivesse em primeiro plano.
- Quando o fast-forward alcança o presente, o cliente entra na fase corrente normalmente, com o estado atual já refletido na UI.
- Esse comportamento é o oposto deliberado da reconexão por queda, onde o cliente entra direto no estado atual sem rebobinar. Em segundo plano o app esteve sempre vivo no device — o cliente pode acumular o stream de eventos vindos do servidor e só apresentá-los visualmente ao voltar para o primeiro plano. Em queda real, esse stream é perdido por definição.
Ainda a definir: velocidade do fast-forward, se é skipável (botão “ir para o agora”), se eventos longos são compactados (ex.: minuto inteiro de chat público) ou só rodam mais rápido, e como tratar fases inteiras perdidas.
Estado preservado
A regra é a mesma de Reconexão: tudo que o jogador fez antes de mandar para o segundo plano continua valendo.
- Voto pendente já registrado na fase corrente continua contabilizado normalmente. Se o jogador sai durante a votação sem ter votado, a abstenção segue o mesmo critério pass-through descrito em Reconexão.
- Anotações (Anotações), mute local (Mute), cooldown de chat em curso (Sanções), cargas/cooldowns de habilidade, identidade (time/conduta/função) — tudo permanece.
- Histórico de chat e resultados de habilidade já recebidos voltam preenchidos.
A diferença em relação a Reconexão não está no que é preservado (em ambos os casos a preservação é total) — está apenas em como o jogador é reapresentado ao estado: fast-forward visual aqui, salto direto lá.
Push notification
- Enquanto o jogador está em segundo plano com partida em andamento, o jogo dispara push notification convidando a voltar (formato genérico tipo “Sua partida ainda está rolando — volte antes que assumam o seu lugar”).
- O push é a forma de chamar a atenção do jogador para que ele volte antes do timeout e ainda receba o fast-forward em vez de ser substituído por bot.
- Tocar/abrir a notificação deve trazer o app de volta direto na partida em andamento, sem tela intermediária de menu.
Ainda a definir: copy final, se há mais de um disparo (ex.: aviso aos 1 min e aviso final perto dos 3 min), comportamento em iOS quando o jogador desabilitou push, e fallback (tray persistente do Android, badge de ícone, etc.). Definição precisa também depende da estrutura de notificações que o cliente vai adotar.
Economia de bateria
Em segundo plano, o cliente reduz consumo de recursos sem comprometer a recepção dos eventos críticos da partida:
- Animações pausadas: nenhuma animação de UI roda enquanto o app não está em primeiro plano. Vale para feedback visual de fase, transições, partículas e qualquer loop ocioso.
- Polling reduzido: a frequência com que o cliente consulta o servidor cai no segundo plano. A intenção é manter o cliente atualizado o suficiente para não perder eventos relevantes (chat, voto, fase) sem queimar bateria com requisições constantes.
- Áudio: comportamento padrão do SO já interrompe áudio quando o app perde foco; o cliente não precisa de tratamento especial além de respeitar isso.
Frequência exata de polling em primeiro vs. segundo plano, comportamento do canal em tempo real (websocket/transporte usado pelo Cloud Code), e quais eventos forçam um pull imediato ao voltar ficam pendentes com o time técnico.
Pendências (a definir em rodadas futuras)
- Velocidade e UX do fast-forward — taxa de aceleração, possibilidade de pular para o presente, compactação de eventos longos.
- Indicador para os demais jogadores quando alguém entra em segundo plano antes de virar AFK confirmado (V1 não distingue; revisitar se o feedback social pedir).
- Copy e cadência de push notifications, comportamento quando o jogador bloqueou push.
- Frequência de polling em primeiro plano vs. segundo plano e tratamento do canal em tempo real.
- App killed pelo SO (não é apenas background — o processo morre): como diferenciar do segundo plano normal e como reabrir cai em Reconexão vs. fast-forward.
- Habilidades com prompt aberto quando o jogador manda para segundo plano (mesma pendência aberta em Reconexão).
- Comportamento em chamadas telefônicas / interrupções rápidas (< 30s) — vale a pena tratar como caso especial sem fast-forward, ou seguir o fluxo padrão?