Um jogo de sobrevivência e defesa de base fica mais fácil de planejar quando é reduzido a um abrigo, uma janela de preparação e uma noite de pressão. Antes de pedir um mundo a uma ferramenta de criação, anote o que o jogador pode fazer, o custo de cada ação, o que os atacantes alteram e o que conta como sobreviver. Depois use prompts separados para as regras, a interação jogável e um caso de validação repetível.
O exemplo desenvolvido a seguir é uma simulação didática original para um refúgio em uma floresta de pinheiros. Os números são premissas calculadas a partir das regras desta página. Não vêm de um jogo real, de uma geração da SEELE ou de um teste de jogo.
Comece com uma noite, não com um mundo inteiro
Para um primeiro prompt de defesa de base, defina um abrigo e um ciclo curto: preparar, enfrentar uma ameaça, observar a consequência e reiniciar. O jogador deve conseguir ligar uma escolha feita antes de anoitecer a um estado que possa conferir ao amanhecer. Se o briefing começar com um mapa cheio de edifícios, árvores de criação, clima e várias classes inimigas, pode ser difícil descobrir qual regra fez a primeira tentativa funcionar ou falhar.
Mantenha o primeiro recorte pequeno o bastante para ser analisado no papel. Nomeie o estado inicial, as ações disponíveis antes do ataque, o custo e efeito de cada ação, a resposta inimiga e a condição final. Isso fornece um alvo para o primeiro build e uma forma de encontrar uma transição quebrada sem presumir que o resultado gerado seguirá todos os detalhes.
Escreva um contrato de regras que o build possa mostrar
Use um estado inicial fixo para que cada ação tenha um efeito visível. Neste caso hipotético, o anoitecer começa com o portão em 2/4, quatro madeiras, três pontos de vida da pessoa sobrevivente, dois atacantes e duas ações de preparação. As regras abaixo são premissas criadas para a explicação, não uma recomendação de balanceamento.
| Campo da regra | Premissa didática | O primeiro build deve deixar visível |
|---|---|---|
| Estado inicial | Portão 2/4; madeira 4; vida 3; dois atacantes; duas ações | Resistência do portão, madeira, vida, fase e ações restantes |
| Reparar | Gaste 1 madeira e 1 ação para recuperar 2 pontos de resistência do portão, até o máximo de 4 | Após um reparo: portão 2→4 e madeira 4→3 |
| Armar uma armadilha | Gaste 2 madeiras e 1 ação; remova o primeiro atacante da sequência desta noite | Madeira diminui em 2 e um atacante é ignorado |
| Recolher | Gaste 1 ação para ganhar 2 madeiras | Madeira aumenta em 2; o portão não se repara automaticamente |
| Ataque noturno | Cada atacante que continuar na sequência causa 1 de dano ao portão | Um segmento muda para cada ataque resolvido |
| Falha do portão | Se o portão chegar a 0, um atacante entra no abrigo e tira 1 ponto de vida; vida 0 encerra a tentativa | A invasão e a perda de vida ocorrem somente no limite definido |
Agora compare dois usos legais das duas ações. Depois de reparar, resta uma ação e três madeiras. O jogador pode gastar duas madeiras na armadilha ou usar essa ação para recolher mais duas. Não há uma segunda ação para fazer as duas coisas. A restrição deixa a escolha clara: proteção imediata em troca de uma reserva maior.
| Linha hipotética | Mudanças na preparação | Ataques resolvidos | Estado ao amanhecer |
|---|---|---|---|
| Reparar e depois armar | Portão 2→4; madeira 4→3→1 | A armadilha remove o primeiro atacante; o outro causa 1 de dano ao portão | Portão 3/4; madeira 1; vida 3 |
| Recolher e depois reparar | Madeira 4→6→5; portão 2→4 | Os dois atacantes causam 1 de dano ao portão | Portão 2/4; madeira 5; vida 3 |
As duas linhas sobrevivem sob essas regras. A primeira termina com maior resistência no portão; a segunda, com mais madeira. Isso decorre deste pequeno conjunto de regras, não prova que uma estratégia seja equilibrada ou melhor. Se mudar o custo de uma ação, o dano do atacante ou o número de ações, recalcule as duas linhas antes de compará-las.
Dê uma função a cada prompt
Separe o pedido para que um erro de regra não seja escondido por uma cena atraente. Estes são modelos reutilizáveis, não prompts registrados durante uma execução. Substitua os detalhes do abrigo, mantenha o contrato de regras e inspecione o resultado devolvido antes de adicionar outro sistema.
Prompt 1: pedir o modelo de regras
Planeje um jogo de sobrevivência e defesa de base de uma noite usando somente este contrato de regras: Comece ao anoitecer com resistência do portão 2/4, madeira 4, vida da pessoa sobrevivente 3, dois atacantes se aproximando e duas ações de preparação. Reparar custa 1 madeira e 1 ação, recupera 2 pontos de resistência até o máximo de 4. Armar uma armadilha custa 2 madeiras e 1 ação e remove o primeiro atacante da sequência de ataques desta noite. Recolher custa 1 ação e acrescenta 2 madeiras. Cada atacante que continua na sequência causa 1 de dano ao portão. Se o portão chegar a 0, um atacante entra no abrigo e causa 1 de dano à vida; vida 0 encerra a tentativa. Não acrescente ações, recursos, inimigos ou regras. Entregue uma tabela de estados para o início, cada ação, cada ataque, o amanhecer e a falha. Percorra reparar e depois armar, e recolher e depois reparar. Mostre toda mudança de recurso e resistência do portão. Sinalize qualquer transição não definida pelas regras.
Este primeiro pedido solicita um contrato e cálculos, não um jogo pronto. Confirme que reparar para no valor 4, que a armadilha remove exatamente um ataque e que recolher altera a madeira sem consertar o portão silenciosamente. Se a resposta inventar uma terceira ação ou outro efeito para a armadilha, corrija as regras antes de pedir uma cena.
Prompt 2: pedir uma interação jogável
Crie uma pequena cena de sobrevivência e defesa de base usando a tabela de regras abaixo. Mostre um refúgio de pedra e madeira, um portão, uma área de preparação acessível e um caminho claro para dois atacantes. Comece ao anoitecer com portão 2/4, madeira 4, vida 3 e duas ações de preparação. As únicas escolhas de preparação são: reparar (1 madeira, 1 ação, +2 de resistência do portão até 4); armar uma armadilha (2 madeiras, 1 ação, ignorar o primeiro atacante desta noite); recolher (1 ação, +2 madeiras). À noite, cada atacante restante na sequência causa 1 de dano ao portão. Uma invasão com resistência 0 custa 1 ponto de vida; vida 0 encerra a tentativa. Deixe legíveis a fase atual, o portão, a madeira, a vida, o número de ações e a rota dos inimigos. Mostre feedback imediato depois de cada escolha. Mantenha disponível o reinício. Não acrescente armas de combate, recursos, ações ou tipos de inimigo extras. Mantenha a primeira cena pequena o bastante para inspecionar cada mudança de estado.
O pedido se limita deliberadamente a um abrigo e uma rota inimiga. Ele solicita estado e feedback visíveis, mas não promete que uma ferramenta específica implemente todas as regras. Quando houver um primeiro resultado, inspecione as interações e o inventário em vez de tratar o prompt como prova.
Prompt 3: verificar uma sequência fixa
Valide o build existente contra este caso exato no papel; não altere as regras. Começo ao anoitecer: portão 2/4, madeira 4, vida 3, dois atacantes e duas ações. Caminho A: reparar e depois armar uma armadilha. Esperado: após reparar, portão 4/4 e madeira 3; após a armadilha, madeira 1 e um atacante removido; o ataque restante deixa o portão em 3/4 ao amanhecer; a vida permanece em 3. Caminho B: recolher e depois reparar. Esperado: madeira 6 após recolher e 5 após reparar; o portão chega a 4/4 antes da noite; dois ataques deixam o portão em 2/4 ao amanhecer; a vida permanece em 3. Para cada caminho, informe o estado antes e depois de cada ação e ataque. Identifique somente a primeira divergência. Não diga que um caminho passou a menos que tenha sido realmente jogado neste build. Se não puder observar um estado, diga isso.
| Função do prompt | Resultado esperado | Critério de aceitação |
|---|---|---|
| Modelo de regras | Transições de estado e as duas linhas calculadas | Cada mudança de madeira e portão segue custos e limites escritos |
| Interação jogável | Cena compacta com fase, escolhas, rotas e feedback | Somente as ações listadas aparecem e cada uma atualiza o estado visível |
| Validação | Comparação estado a estado com o Caminho A ou B | A primeira divergência é nomeada; resultado não observado não é chamado de aprovação |
Diagnostique a primeira mudança de estado errada
Quando um resultado divergir do contrato de regras, não reescreva o pedido inteiro. Encontre o primeiro estado que divergiu e confira a menor regra que o controla. Um valor errado ao amanhecer pode ser consequência de custo ou ataque anterior; por isso compare cada ação em ordem.
| Sintoma observado | Primeiro campo a inspecionar | Próxima verificação |
|---|---|---|
| Reparar gasta madeira, mas o portão continua em 2/4. | Transição e feedback de reparo. | Confirme que uma ação recupera dois segmentos até o máximo de 4. |
| A armadilha custa uma ou três madeiras. | Custo da armadilha e atualização do inventário. | Mantenha o custo em duas e confirme que resta 1 madeira após reparar. |
| Os dois atacantes atingem depois de armar a armadilha. | Alvo da armadilha e sequência de ataques. | Verifique se o primeiro atacante é removido antes dos ataques serem resolvidos. |
| A vida diminui enquanto o portão ainda está acima de 0. | Limite da invasão. | Aplique perda de vida somente depois que o portão chega a 0 e um atacante entra. |
Repita o mesmo estado inicial depois de mudar uma regra. Mantenha os outros valores fixos para que a comparação seguinte indique se a mudança corrigiu a transição pretendida. Abaixo está um resultado conceitual do Caminho A; a cena não é uma execução real de produto.
Leve o contrato de regras a um primeiro build
Quando o caso escrito estiver coerente, ele pode virar um pedido de criação focado. A página atual do Criador de jogos com IA grátis da SEELE descreve informar uma ideia em linguagem simples, revisar um resultado jogável em 2D ou 3D e iterar no Workspace. Isso oferece um fluxo para experimentar um conceito definido, mas não comprova que este design hipotético tenha sido gerado nem que suas regras funcionarão sem alterações. Revise você mesmo o resultado, as interações pedidas e o custo de geração exibido.
Forneça ao criador a primeira decisão do jogador, a cena pequena, o estado a exibir e a sequência de aceitação. Se o primeiro resultado não seguir uma regra, peça uma correção específica, por exemplo: “depois do reparo, aumente o portão em dois, mas nunca acima de quatro”. Em seguida compare novamente o mesmo estado inicial. Mantenha o contrato original ao lado do build para que pedidos visuais ou de conteúdo não confundam as mecânicas avaliadas.
Escolha o próximo recorte com base no que observar
Mantenha a primeira noite se o jogador conseguir explicar por que o portão mudou e o que a armadilha ou a coleta fez. Simplifique se não conseguir relacionar uma divergência a uma regra. Só amplie quando o primeiro ciclo estiver legível: um segundo tipo de inimigo, outra fase de preparação ou um refúgio maior devem introduzir cada um uma decisão que possa ser inspecionada. Os dois caminhos no papel são alvos escritos úteis; ainda é preciso observar seu próprio build antes de afirmar que funcionam.
Quando o briefing de uma noite estiver pronto, use o Criador de jogos com IA grátis, inspecione o resultado e revise uma mudança de estado por vez. Criador de jogos com IA grátis
Perguntas frequentes
O que um primeiro prompt de defesa de base deve incluir?
Estado inicial, ações disponíveis, custo e efeito, resposta inimiga e condição de falha. Inclua uma sequência curta que combine as regras e deixe elementos visuais para depois.
Preciso construir a base inteira primeiro?
Não. Comece com abrigo, portão, preparação e uma rota inimiga clara. Amplie quando uma sala ou sistema criar uma decisão que o ciclo inicial não responde.
Quando devo adicionar um segundo tipo de inimigo?
Depois de verificar a rota do primeiro e seu efeito no portão. Dê ao novo tipo um comportamento e sinal distintos e teste em um caso repetível.
Como separar uma regra quebrada de um balanceamento ruim?
Confira primeiro custos, limites, ações e ordem dos ataques. Corrija divergências antes de avaliar estratégia. Se as regras estiverem corretas, compare uma mudança de custo ou efeito por vez.
Este exemplo foi testado?
Não. O refúgio, custos e resultados são uma simulação didática fictícia calculada pelas regras declaradas. Não houve build jogável, resultado da SEELE nem teste medido.
