Comece com um ciclo que você consegue calcular
Um criador de jogos idle é mais útil quando ajuda a criar um ciclo que pode ser inspecionado: clicar para obter um recurso, comprar uma melhoria e observar essa melhoria produzir recursos automaticamente. Comece com uma moeda e um gerador. Reinícios de prestígio, várias fábricas e números enormes podem esperar até que a pequena economia se comporte de maneira previsível.
Este tutorial usa um jogo de estufa ilustrativo, não um projeto gerado ou testado. Suas moedas são uma moeda fictícia do jogo, não dinheiro real nem receita para criadores. Você definirá o ciclo, calculará as primeiras compras, verificará a produção automática e fará uma alteração mensurável de balanceamento. O objetivo é um protótipo completo de ganhos e melhorias que possa ser avaliado em uma única sessão. Salvamento e recompensas offline pertencem à próxima etapa, depois que essa base funcionar.
Escolha sua abordagem inicial
O ponto de partida certo depende do controle necessário e do trabalho que você está disposto a verificar.
| Abordagem | Útil quando | Verifique antes de se comprometer |
|---|---|---|
| Ambiente de trabalho com ajuda de IA | Você quer descrever um pequeno ciclo e iterar sobre um resultado gerado. | Inspecione as regras geradas e verifique as opções de publicação suportadas. |
| Modelo de jogo idle | Você quer personalizar um ciclo existente. | Verifique quais mecânicas, recursos e termos de licença podem ser alterados. |
| Motor de jogos de uso geral | Você precisa de controle detalhado sobre sistemas e apresentação. | Planeje o esforço de implementação, testes e manutenção. |
Copie este pequeno briefing de jogo idle
Crie um jogo idle de estufa para navegador em uma única tela, com uma planta, contador de moedas, número de jardineiros, exibição de moedas por segundo e botão Comprar Jardineiro. Clicar na planta concede uma moeda fictícia. Cada jardineiro adquirido produz uma moeda por segundo. O próximo jardineiro custa ceil(10 × 1.15^n), em que n é a quantidade já adquirida. Uma compra desconta esse preço uma vez e adiciona um jardineiro. Rejeite compras quando os fundos forem insuficientes. Comece com zero moedas e nenhum jardineiro. Mostre uma confirmação antes de reiniciar a sessão. Nesta primeira versão, recarregar inicia uma nova sessão; explique isso claramente. Sem recompensas offline, anúncios, pagamentos reais, prestígio, modo multijogador ou moedas adicionais.
Etapa 1: estabeleça um estado inicial limpo
Solicite o contador e a ação de clique antes da produção automática. Em uma sessão nova, a tela deve mostrar zero moedas, zero jardineiros e zero moedas por segundo. Clique dez vezes na planta e verifique se há dez moedas. Clicar em áreas decorativas não deve conceder nada. Manter o ponteiro pressionado não deve virar silenciosamente uma sequência de cliques, a menos que você especifique esse comportamento deliberadamente.
Anote o estado inicial e o resultado real em um breve registro de execução. Se uma entrada conceder duas moedas, peça uma correção para o manipulador de entrada duplicado em vez de alterar o valor da recompensa. Mantenha a verificação de início limpo disponível durante o desenvolvimento: ela oferece a mesma referência para cada comparação posterior.
Etapa 2: adicione compras com uma regra de preço visível
Com dez moedas e nenhum jardineiro, compre uma vez. O saldo esperado é zero, o número de jardineiros é um e a taxa de produção é uma moeda por segundo. O próximo preço é de doze moedas porque ceil(10 × 1.15) arredonda 11,5 para cima. Depois de dois jardineiros, o preço seguinte é de quatorze moedas. Esses números pequenos facilitam reconhecer discrepâncias.
Tente comprar com fundos insuficientes, clicar rapidamente e pressionar o botão repetidas vezes. Cada compra bem-sucedida deve usar o preço exibido para aquela compra, descontá-lo uma vez e conceder um jardineiro. Um botão que parece desativado não basta; a lógica de compra também deve rejeitar solicitações inválidas. Se o custo exibido e o descontado forem diferentes, corrija o cálculo compartilhado antes de adicionar compras em lote.
Etapa 3: verifique a produção automática em relação ao tempo decorrido
Peça produção baseada no tempo decorrido, em vez de uma recompensa fixa por quadro renderizado. Caso contrário, a taxa de atualização da tela ou a limitação em segundo plano pode alterar a economia. Com um jardineiro e sem cliques manuais, dez segundos medidos devem adicionar aproximadamente dez moedas. Informe uma pequena tolerância de observação, pois ler um contador em mudança não é uma cronometragem exata.
Repita com dois jardineiros: a taxa esperada é de duas moedas por segundo. Escolha como o progresso fracionário será mantido internamente e como as moedas inteiras serão exibidas. Arredondar para baixo cada pequena atualização de produção pode apagar ganhos; arredondar apenas a exibição não deve alterar o total armazenado. Mantenha visíveis o número de jardineiros, a taxa e o preço para que o jogador entenda o que uma compra muda.
Etapa 4: examine o ritmo antes de alterar a economia
Jogue a partir do mesmo início limpo e anote o tempo até a primeira e a segunda compras. Decida se a experiência desejada é clicar ativamente, esperar de forma passiva ou combinar os dois. Se a primeira espera parecer longa demais, altere uma variável em vez de aumentar ao mesmo tempo recompensas por clique, produção e descontos.
Para uma revisão limitada, reduza o preço-base do jardineiro de dez para oito, mantendo o fator de crescimento 1.15 e a taxa de produção de uma moeda. Os três primeiros preços novos devem ser oito, dez e onze. Peça essa alteração exata e repita as verificações de clique, fundos insuficientes, compra e produção cronometrada. Uma nova etiqueta de preço, sozinha, não comprova que a lógica de compra mudou corretamente.
Etapa 5: conclua o ciclo da sessão e defina o próximo limite
Adicione uma confirmação de reinício e teste as duas opções. Cancelar deve preservar a sessão; confirmar deve restaurar zero moedas, zero jardineiros, o preço inicial e produção zero. Verifique se um reinício cancelado não para o cronômetro de produção e se um reinício confirmado não deixa um cronômetro antigo funcionando.
Antes de compartilhar, explique que essa versão recomeça ao recarregar. Não esconda esse limite atrás de um rótulo genérico “Salvar”. Quando o ciclo completo da sessão passar nos testes, preserve a versão funcional e adicione persistência e recompensas offline como uma alteração separada. Assim, um futuro erro de salvamento poderá ser distinguido de uma falha de compra ou produção.
Tabela de testes do primeiro ciclo
Estas são expectativas calculadas para o briefing ilustrativo, não resultados de um build testado.
| Ação ou estado | Resultado esperado | Como verificar |
|---|---|---|
| Iniciar uma nova sessão | 0 moedas e 0 jardineiros. | Leia os dois contadores antes de clicar. |
| Clicar uma vez na planta | O saldo aumenta em 1 moeda fictícia. | Compare o saldo antes e depois de um clique. |
| Comprar o primeiro jardineiro | 10 moedas são descontadas e a contagem passa a 1. | Tente com menos de 10 moedas e depois com exatamente 10. |
| Verificar o segundo preço | ceil(10 × 1.15) = 12 moedas. | Compare o preço visível com o valor realmente descontado. |
| Esperar 10 segundos com um jardineiro | Aproximadamente 10 moedas são produzidas. | Meça o tempo decorrido e considere a precisão da exibição e da medição. |
| Recarregar o primeiro protótipo | A sessão começa novamente. | Confirme que a página explica esse comportamento antes de recarregar. |
Onde o SEELE se encaixa no fluxo
O SEELE oferece criação de jogos guiada por prompts e solicitações iterativas envolvendo cenas, recursos e código de jogabilidade. Use o briefing da estufa como entrada para um pequeno protótipo candidato e depois informe a discrepância observada, o valor esperado e a regra que deve permanecer inalterada. Por exemplo, descreva uma compra que desconta doze moedas, mas concede dois jardineiros, em vez de pedir uma melhoria geral.
O resultado útil é um build que você possa inspecionar com suas próprias verificações. Não presuma que o briefing garante uma implementação, formato de exportação, compatibilidade de dispositivo ou economia segura específicos. Separe alterações visuais das alterações na economia para que o próximo teste continue respondendo a uma pergunta clara.
Conclua a pequena economia antes de adicionar outros sistemas
Um primeiro jogo idle útil tem ganhos compreensíveis, compras previsíveis, produção visível e um reinício limpo. O briefing da estufa mantém essas decisões pequenas o suficiente para verificar à mão. Mais moedas não corrigirão uma compra que pode cobrar duas vezes, e prestígio não consertará produção ligada à taxa de quadros.
Leve o briefing ao SEELE e solicite primeiro a parte de clique e compra. Salve suas observações com o projeto e faça uma alteração por vez. Depois que o ciclo completo da sessão passar nos testes, avance para salvamentos versionados e progresso offline limitado sem substituir a economia funcional.
Perguntas frequentes
Um jogo idle pode funcionar sem ficar em execução continuamente?
Sim. Uma versão posterior pode calcular a produção quando o jogador retorna, em vez de executar uma simulação enquanto o jogo está fechado. Isso exige estado salvo, um registro de tempo para o crédito e uma regra explícita de cálculo. Primeiro verifique a economia da sessão ativa; recompensas offline introduzem problemas separados de persistência e tempo que este build introdutório deixa de fora deliberadamente.
A primeira versão deve usar números enormes?
Não. Valores pequenos facilitam encontrar erros de arredondamento e recompensas duplicadas. Se mais tarde a progressão exceder a precisão numérica comum, escolha uma representação adequada para números grandes e teste juntos os cálculos, a formatação e a compatibilidade dos salvamentos. Adicionar uma biblioteca numérica não substitui a verificação das regras de compra e cálculo.
Ganhar moedas significa que o jogo gera dinheiro real?
Não. Neste exemplo, moedas são apenas um recurso de jogo. Publicidade, compras, pagamentos a criadores e distribuição envolvem sistemas técnicos, políticas e decisões comerciais separados. Confirme independentemente as capacidades e condições atuais do produto; um ciclo idle funcional não comprova receita, retenção ou prontidão comercial.
