Os jogadores voltam para o próximo episódio com rotas escolhidas, cenas desbloqueadas e tempo investido. Trate a compatibilidade dos salvamentos como um recurso que você mantém a cada lançamento. Renomear elementos do estado, remover cenas ou alterar objetos serializados pode inutilizar salvamentos antigos mesmo quando uma nova partida funciona corretamente.
Os sistemas de salvamento variam entre os motores. Consulte a documentação da versão exata do seu motor e registre as versões envolvidas. Use este guia para definir e testar seu compromisso de compatibilidade; não presuma que um script de migração universal possa tornar compatível toda atualização do motor.
Defina o contrato de compatibilidade
Decida a quais versões lançadas a próxima build vai oferecer suporte antes de alterar o estado que ela salva. Estabeleça políticas explícitas para salvamentos comuns, desbloqueios persistentes, configurações e salvamentos exportados do navegador; eles podem precisar de tratamentos diferentes. Avise os jogadores com antecedência quando for possível que precisem recomeçar.
Mantenha um identificador de lançamento e, quando você controlar o formato de salvamento, uma versão do esquema. Separe o progresso no conteúdo das configurações de apresentação e dos dados derivados. Antes de alterar um campo persistente, registre seu significado e seu valor padrão.
Prefira identificadores estáveis
Dê às rotas e cenas identificadores estáveis que permaneçam válidos após reescritas e traduções. Mantenha esses identificadores intactos enquanto prometer compatibilidade. Se algum deles precisar mudar, planeje uma migração ou indique claramente o limite a partir do qual os salvamentos antigos deixam de ser suportados.
Se você gerencia um formato de salvamento personalizado, armazene dados simples, documente o esquema e valide os dados recebidos antes de usá-los. Os salvamentos nativos do motor podem depender de outras regras de serialização. Siga as orientações do motor antes de substituir um sistema de salvamento confiável por um serializador caseiro.
Planeje uma migração antes de alterar o estado
Escreva o plano de migração antes de alterar um campo: o campo antigo, o novo campo, a regra de conversão e a alternativa para dados ausentes ou inesperados. Faça migrações determinísticas e repetíveis quando o formato permitir. A ausência de um campo não relacionado nunca deve conceder progresso.
Para Ren'Py, siga as orientações sobre salvamento e rollback e as notas de compatibilidade aplicáveis às suas versões. Para SugarCube, confira a versão exata do formato e as APIs de salvamento. Para um estado personalizado no Godot, implemente e teste o esquema que você gerencia. Uma regra que funciona em um sistema pode não se aplicar a outro.
Mantenha uma biblioteca de salvamentos representativos
Monte uma biblioteca de salvamentos que cubra o início, os momentos logo antes de escolhas importantes, cada rota principal e a aproximação do final. Inclua diferentes desbloqueios, configurações e versões antigas às quais você ainda oferece suporte. Use estados de desenvolvimento anonimizados e evite coletar dados dos jogadores de que você não precisa.
Teste com cópias e deixe os originais intactos. Registre de qual lançamento veio cada salvamento e o estado esperado após carregá-lo. Carregar sem uma exceção é apenas a primeira verificação: um salvamento ainda pode colocar o jogador na rota errada, duplicar uma recompensa ou perder uma configuração.
Teste uma atualização real
Teste a build empacotada pelo caminho de atualização que os jogadores realmente vão usar: instale-a ou disponibilize-a por um servidor, conforme o caso. Carregue um salvamento antigo, continue por uma cena significativa, salve novamente e recarregue. Verifique o progresso persistente e as configurações separadamente.
Nas builds para navegador, verifique a origem, o comportamento do armazenamento e o contexto de hospedagem quando o jogo está incorporado. Uma mudança de URL ou de contexto de armazenamento pode afetar o acesso aos dados existentes mesmo quando a lógica do jogo não muda. Se você oferece exportação e importação, verifique esse caminho de recuperação e explique seus limites.
Publique informações claras sobre recuperação
Publique o caminho de atualização suportado, o método de backup e os limites de compatibilidade conhecidos onde os jogadores possam encontrá-los. Faça o formulário de relato de bugs pedir detalhes úteis sobre as versões. Se um lançamento não puder preservar com segurança uma categoria de salvamentos, explique esse limite antes que um jogador sobrescreva sua última cópia funcional.
Arquive a build testada, as notas do esquema e a matriz de salvamentos junto com cada lançamento. Mantenha as decisões de migração vinculadas às revisões do código-fonte. Verificações regulares de compatibilidade facilitam a manutenção do trabalho e permitem detectar falhas antes dos jogadores.
Decisões-chave
- Indique os lançamentos suportados e estabeleça uma política para cada categoria de salvamentos.
- Mantenha IDs estáveis e documente o significado e o valor padrão de cada campo.
- Após a migração, verifique o progresso, depois salve e recarregue.
- Proteja os salvamentos originais e explique aos jogadores como recuperá-los.
Arquivos do guia
Matriz de testes ↓Comunidades externas dedicadas a modelos e sites externos de publicação podem conter material explícito. Os links para as fontes abrem em uma nova aba; este guia não carrega suas prévias.
Fontes e leituras adicionais +
- Referência de salvamento e rollback do Ren'Py ↗
- Mudanças incompatíveis do Ren'Py ↗
- Salvando jogos no Godot ↗
- Referência do SugarCube ↗
Última verificação 5 de outubro de 2026.