Comece com um ciclo funcional e torne seu progresso confiável
Um jogo idle precisa de mais do que um contador que aumenta enquanto a página está aberta. Jogadores esperam que melhorias compradas sobrevivam a uma atualização, que a volta ao jogo conceda progresso razoável e que atualizações posteriores não apaguem seu trabalho. Trate salvamento, cálculo offline e compatibilidade como comportamentos separados, com verificações próprias.
Este fluxo continua um design ilustrativo de estufa, não um projeto existente gerado ou testado. Clicar rende moedas fictícias; cada jardineiro comprado produz uma moeda por segundo. O próximo jardineiro custa ceil(10 × 1.15^n), em que n é a quantidade já adquirida. Comece com um ciclo funcional de ganhos e compras. Você definirá um contrato de salvamento, calculará uma recompensa de retorno limitada e preservará o progresso durante uma alteração posterior, sem confundir armazenamento local com salvamento na nuvem.
Especifique o que o jogo precisa lembrar
Escreva o contrato de salvamento antes de solicitar código. Uma versão mínima inclui versão do esquema, saldo atual de moedas, número de jardineiros, melhorias compradas e o horário até o qual os ganhos já foram calculados. Mantenha as regras de taxa de produção junto das definições de melhorias. Salve as compras que sustentam o saldo exibido, não cópias contraditórias de estado derivado.
Peça um resumo legível do salvamento durante o desenvolvimento para comparar o estado do jogo com o estado armazenado. Evite expor informações privadas na saída de diagnóstico. Diferencie também um salvamento local de um associado à conta. O armazenamento do navegador pertence a um perfil e pode ser apagado. Ele não promete progresso entre dispositivos, saldos competitivos seguros ou recuperação após o jogador excluir os dados do site.
Use esta solicitação limitada:
Adicione um salvamento local versionado para moedas, jardineiros, melhorias compradas e horário do último cálculo. Restaure o estado antes de mostrar uma tela jogável. Valide os valores carregados. Se não houver salvamento, inicie um novo jogo. Se um salvamento for inválido, explique o comportamento de recuperação em vez de produzir silenciosamente saldos impossíveis. Mantenha inalteradas a arte e as regras de ganho existentes.
Salve após compras significativas e defina salvamentos periódicos se o jogo precisar. Não dependa exclusivamente de um evento de fechamento da página: o navegador ou dispositivo pode parar sem enviar o último evento esperado.
Calcule recompensas de ausência uma vez, com um limite claro
Progresso offline geralmente significa calcular uma recompensa quando o jogador retorna. Não exige que o script do jogo continue executando depois que o navegador fecha. Uma regra transparente é:
recompensa = taxa de produção salva elegível × min(max(horário de retorno − horário do último cálculo, 0), oito horas)
Decida o que significa a taxa elegível antes de implementar. Neste design simples, ela é a taxa de produção dos jardineiros e melhorias salvos no momento da saída. Adie simulações complexas até o cálculo básico funcionar.
Para verificar o valor esperado, dois jardineiros produzindo uma moeda cada por segundo renderiam 1.200 moedas em um intervalo controlado de dez minutos. Dez horas de ausência usariam apenas oito horas sob o limite do exemplo. Use o cálculo como valor esperado no registro de execução.
Após conceder o progresso, o jogo deve atualizar o estado do cálculo para que uma atualização não recompense novamente a mesma ausência. Peça uma mensagem de retorno mostrando a duração usada e a recompensa concedida. Descreva a recompensa calculada sem sugerir um servidor em execução contínua.
Exemplos detalhados: recompensas offline
Estes exemplos supõem uma taxa de produção fixa, moedas fictícias e um limite de duas horas onde indicado. Descrevem cálculos esperados, não resultados medidos em um jogo testado.
| Cenário | Cálculo | Recompensa esperada |
|---|---|---|
| 1 jardineiro, ausência de 10 minutos | 1 moeda/segundo × 600 segundos | 600 moedas fictícias |
| 2 jardineiros, ausência de 30 minutos | 2 moedas/segundo × 1.800 segundos | 3.600 moedas fictícias |
| 1 jardineiro, ausência de 3 horas, limite de 2 horas | 1 moeda/segundo × min(10.800, 7.200) segundos | 7.200 moedas fictícias |
| Recarregar imediatamente após o cálculo | O intervalo já calculado não é contado novamente. | 0 moedas adicionais por esse intervalo |
Teste o salvamento separadamente do cálculo de tempo
Primeiro obtenha um saldo conhecido, compre um jardineiro e atualize a página. Confirme que o saldo e a compra permanecem. Depois feche o navegador, espere um intervalo medido e retorne. Registre o estado inicial, o tempo real decorrido, a recompensa observada e o estado final. Atualize imediatamente e verifique se a mesma recompensa não é repetida.
Use um relógio de teste controlado para intervalos longos e uma verificação real de fechamento e retorno para o caminho normal. Teste um intervalo decorrido negativo, um intervalo implausivelmente grande, um salvamento vazio e um salvamento danificado. Defina como cada um deve se comportar antes de observar o resultado. Um intervalo negativo não deve subtrair moedas já ganhas. Um intervalo grande não deve ultrapassar o limite.
O horário local do dispositivo pode ser alterado pelo jogador. Limitar o tempo decorrido ajuda a evitar erros óbvios, mas não torna uma economia local resistente a adulterações. Economias competitivas ou pagas precisam de um projeto separado de cálculo por uma autoridade confiável e segurança.
Tabela de testes da visita de retorno
| Ação | Comportamento esperado | Se a verificação falhar |
|---|---|---|
| Comprar uma melhoria e atualizar | O saldo salvo e a melhoria comprada retornam juntos. | Inspecione quais campos foram salvos e quando o salvamento ocorreu. |
| Retornar após um intervalo medido | A recompensa segue a taxa e o limite de tempo documentados. | Compare o horário de cálculo armazenado, a taxa e o tempo decorrido. |
| Recarregar imediatamente após a recompensa de retorno | O mesmo intervalo não é recompensado duas vezes. | Verifique se o horário de cálculo avança junto com a recompensa. |
| Abrir outro navegador ou dispositivo | O comportamento corresponde ao modelo declarado, local ou baseado em conta. | Verifique se existe mecanismo de sincronização entre dispositivos. |
| Carregar um salvamento antigo após mudança de regra | Compras e saldo seguem a migração documentada. | Inspecione a versão do salvamento e o caminho de migração ou recuperação. |
Faça uma melhoria posterior sem reiniciar o jogador
Quando o salvamento funcionar, solicite uma pequena alteração de conteúdo:
Altere o preço-base do jardineiro de dez para oito moedas nas compras futuras, mantendo o fator de crescimento 1.15. Preserve moedas, jardineiros, melhorias adquiridas, elementos visuais e cálculo offline existentes. Dê suporte à versão atual dos dados salvos. Mostre como um salvamento antigo é migrado caso o novo estado exija campos adicionais.
Guarde um salvamento real anterior à mudança e um build funcional antes de fazer essa solicitação. Carregue esse salvamento na versão revisada e compare o saldo, as compras e a taxa de produção resultantes. Adicionar um campo não deve descartar todo o estado apenas porque o salvamento antigo não o possui. Decida se compras anteriores mantêm seus benefícios antes de alterar a economia.
Se melhorias desaparecerem, inspecione a migração e o carregamento antes de adicionar recursos. Um novo botão não é evidência de compatibilidade de salvamento.
Use o SEELE para alterações limitadas de persistência
O SEELE oferece um fluxo guiado por prompts para criar jogos e solicitar alterações posteriores. Aqui, a entrada relevante é a economia funcional mais um contrato específico de salvamento; o resultado desejado é uma revisão candidata cujo carregamento e cálculo você possa inspecionar. Peça a menor alteração de persistência antes de solicitar migração ou novas melhorias.
Mantenha um build funcional e um salvamento de referência fora da alteração que está avaliando. Quando uma verificação falhar, relate as diferenças exatas de estado, incluindo se o problema ocorreu ao carregar, retornar ou comprar. O posicionamento do produto, sozinho, não comprova salvamentos na nuvem, relógios seguros, garantias de migração nem a confiabilidade de uma implementação específica de armazenamento local.
Continue apenas quando a visita de retorno fizer sentido
Um jogo idle confiável deve explicar de onde vêm seus números: o que produziu a recompensa, qual intervalo de ausência contou e quais compras continuam adquiridas. Use a ajuda da IA para mudanças limitadas nessas regras e depois avalie cada alteração no jogo em execução. Não troque um salvamento funcional por uma lista maior de recursos.
Use o SEELE para solicitar um salvamento local e uma recompensa de retorno limitada no projeto existente. Preserve uma versão comprovadamente funcional antes de pedir outra mudança na economia. O próximo marco não é uma promessa maior; é uma visita de retorno verificada com o progresso anterior do jogador intacto.
Perguntas frequentes
Progresso offline significa que o jogo roda enquanto meu navegador está fechado?
Não necessariamente. Uma abordagem comum armazena o estado e o horário do cálculo e calcula uma recompensa na próxima visita. Isso pode permitir recompensas offline sem um processo de navegador em execução contínua. Verifique a implementação real antes de descrevê-la. Simulação no servidor é uma arquitetura diferente e não deve ser sugerida por uma recompensa calculada localmente.
Um salvamento do navegador passa para outro dispositivo?
Não presuma que sim. O armazenamento local do navegador normalmente permanece vinculado ao perfil e aos dados do site. Salvamentos entre dispositivos precisam de sincronização explícita ou de um sistema de contas, além de decisões sobre conflitos e privacidade. Informe o que a demonstração testada realmente usa, em vez de apresentar um exemplo de persistência local como recurso de salvamento na nuvem.
Posso alterar preços de melhorias depois que pessoas já jogaram?
Sim, se o design revisado definir como compras existentes e estado salvo serão tratados. Preserve um salvamento de referência, decida quais benefícios permanecem adquiridos e teste a migração antes de lançar a alteração. Simplesmente substituir a lista de preços não prova que o progresso antigo continua válido. Se o comportamento ainda não foi testado, descreva-o como requisito, não como atualização bem-sucedida.
