O que acontece com o progresso de um jogador quando ele troca de celular?
Um jogador passa seis meses no seu jogo, compra o passe de temporada, chega ao nível 400 —aí troca de celular e o progresso some. Os tickets de suporte se acumulam, as avaliações da loja ficam violentas, e a causa raiz é uma decisão de design que você tomou no dia um sem perceber a consequência. Isto é o que tem que ser verdade para "trocar de celular" significar "continuar jogando".
Q: Por que um ID de dispositivo não é um sistema de save?
Porque um ID de dispositivo —IDFA, GAID, Android ID— é um token de atribuição, não uma identidade. some com o reset de fábrica, desaparece com o aparelho novo e cada vez mais é bloqueado por avisos de privacidade (ATT, GDPR, defaults de plataforma). No instante em que um jogador troca de hardware, aquele ID vai embora, e se o seu progresso depende dele, a conta também. A identidade tem que vir de algo que o jogador carrega: um e-mail, um telefone ou um SSO. Qualquer outra coisa transforma em silêncio uma troca de celular em perda de dados, e o jogador culpa seu jogo, não o sistema dele.
Q: Como você resolve um conflito de save na nuvem sem apagar o do jogador?
O último a escrever ganha (last-write-wins) é a armadilha: o jogador joga offline três dias, conecta, e o progresso local fresco é pisado por um arquivo de nuvem velho de terça. Vetores de versão e registros de operação (CRDT) fundem limpo, mas custam armazenamento e engenharia que talvez você não precise. Para um jogo casual, a fusão otimista por campos é o ponto doce —funde moedas, níveis e cosméticos como campos separados, pegando o valor mais alto ou mais novo por campo—, com baixa taxa de conflito e quase nada perdido. A armadilha: decida o que conta como verdade. Campos de autoridade do servidor (moedas, desbloqueios) devem ser validados no servidor, não confiar no timestamp do cliente.
Q: Offline-first ou cloud-first?
Offline-first: joga local e sincroniza em segundo plano —suave em rede ruim, mas maior taxa de conflito e mais superfície de trapaça. Cloud-first: cada ação consulta o servidor —limpo, mas inútil assim que a conexão cai, fatal em mercados onde a conectividade é a exceção. A resposta pragmática para casual é offline-first com fusão em segundo plano mais validação de servidor nos poucos campos que importam. Você troca um pouco de tratamento de conflito por uma experiência que funciona em todo lugar.
Q: Como você impede trapaceiros de forjar um save?
Um save local é um JSON de texto puro que um jogador edita com um editor ou um editor de memória —põe as moedas em nove bilhões, desbloqueia tudo. A defesa começa no protocolo: não deixe o cliente ter a verdade de nada valioso. Moedas e desbloqueios assinados ou guardados pelo servidor, validados em cada sincronização, e detecção de anomalias (um jogador que ganha dez anos de moedas num dia não é um bug, é uma bandeira). O anti-trapaça não é só um martelo de ban depois; o formato do save em si deve tornar forjar inútil.
| Estratégia | Perda por conflito | Custo | Para |
|---|---|---|---|
| Último a escrever ganha | alta | minúsculo | dados descartáveis |
| Vetores de versão / CRDT | nenhuma | alto | estado colaborativo |
| Fusão por campos | baixa | médio | jogos casuais |
