Um shooter cooperativo de zumbis precisa de mais do que dois jogadores e uma quantidade crescente de inimigos. Precisa de objetivo comum, funções claras para cada pessoa e uma janela curta de decisão em que munição, reparos e progresso competem. Este guia transforma a premissa em uma sequência compacta de prompts e uma rota calculada manualmente para três ondas.
O exemplo, Dead Air at Beacon Four, é um exercício de design fictício. Nenhum prompt foi executado; não foi fornecido protótipo jogável ou sessão cooperativa, e os números abaixo não são dados de balanceamento testados. Use-os como contrato em papel a adaptar e verifique-os em um protótipo real antes de relatar resultados.
Comece com um objetivo compartilhado
“Dois jogadores atiram em zumbis” deixa o gerador inventar por que deveriam permanecer juntos. Dê a eles uma tarefa comum que conecte o combate a um resultado visível: carregar um sinalizador de emergência, manter um portão de pé e chegar juntos a um único ponto de extração. Isso cria três perguntas ligadas para o primeiro protótipo: quem gasta munição contra cada ameaça, o que a dupla pode fazer entre as ondas e qual estado conta como vitória da equipe?
Mantenha a primeira versão proposta deliberadamente pequena: um pátio de retransmissão encharcado pela chuva, uma carabina fixa por sobrevivente, três ondas curtas, um sinalizador, um portão e um caminhão de resgate. No pressuposto do design, ambos compartilham a tela e usam controles genéricos separados. O analógico esquerdo move, o direito mira, o gatilho dispara e Interagir opera o sinalizador ou reanima. Esta é uma proposta fictícia de controles; não afirma que uma ferramenta específica ofereça cooperativo local ou rede.
Defina as regras centrais antes de descrever a horda
Anote estado inicial, custos, tempo e reinício antes de pedir cenário. Uma tabela pequena revela regras que adjetivos como “tenso” ou “cooperativo” não resolvem.
| Sistema | Regra proposta para a primeira versão | O que pedir ao prompt |
|---|---|---|
| Sobreviventes e arma | A e B começam cada um com 3 de vida, 2 balas no carregador e 4 na reserva. Cada um leva a mesma carabina semiautomática. Um disparo consome uma bala carregada; um acerto derrota um caminhante com 1 de vida. | Mostrar vida e munição dos dois jogadores e manter a arma fixa. Um tiro errado ainda gasta a bala, mas não causa dano. |
| Ondas e pressão | Três ondas de 20 segundos geram 2, depois 3 e depois 4 caminhantes básicos. Cada caminhante que sobreviva causa 1 de dano ao portão quando a onda termina e então sai daquele encontro. | Tornar legíveis o cronômetro da onda e os alvos restantes. Em empate de caminho mais curto até um sobrevivente, o alvo é A. |
| Objetivo compartilhado | O portão de aço começa em 5/5. O sinalizador começa em 0/3. A equipe só vence após a Onda 3, sinalizador em 3/3 e ambos os sobreviventes na zona do caminhão. | Manter integridade do portão e carga do sinalizador como valores separados e visíveis. Só uma pessoa no caminhão não é vitória. |
| Intervalo | Cada intervalo seguro de 8 segundos dá a cada sobrevivente uma ação: carregar, recarregar até 2 balas da reserva ou reparar 1 ponto do portão até 5. No máximo uma carga de sinalizador é obtida por intervalo, mesmo que ambos escolham Carregar. As escolhas são resolvidas simultaneamente. | Especificar resolução simultânea e limite de uma carga. Uma segunda escolha de Carregar não tem efeito. |
| Queda e recuperação | Com 0 de vida, um sobrevivente fica caído por 10 segundos. Uma pessoa parceira a até 2 metros pode manter Interagir pressionado por 2 segundos para restaurar exatamente 1 de vida e limpar o cronômetro. Cada sobrevivente pode ser reanimado uma vez por partida; uma queda posterior depois de usar essa permissão encerra a partida. | Solicitar explicitamente alcance, duração do comando, vida restaurada, efeito no cronômetro, limite por pessoa e condição de falha. |
| Reinício | Reiniciar retorna à Onda 1 com 3 de vida para cada pessoa, portão 5, sinalizador 0, carregadores 2 para ambos, reservas 4 para ambos, sem cronômetros de queda e com as duas reanimações disponíveis. | Pedir reinício completo. Munição, dano ao portão, carga do sinalizador e indicadores de reanimação não podem vazar para a próxima partida. |
Esses números tornam o prompt inspecionável; não provam que o jogo pareceria justo. Por exemplo, uma onda de 20 segundos exige alvos legíveis e tempo suficiente para decidir, mas somente um protótipo real pode revelar se velocidade de movimento, espaçamento dos surgimentos e resposta dos disparos sustentam esse ritmo.
Acompanhe carga, recarga e reparo ao longo do ciclo de ondas
O intervalo é onde o objetivo compartilhado vira uma decisão de equipe. Carregar avança a extração, recarregar restaura disparos futuros e reparar protege o portão. O design limita o progresso do sinalizador a uma carga por intervalo para que ambos não concluam o objetivo com uma ação duplicada.
| Etapa | Ações e resultado | Munição A / B | Portão | Sinalizador | Vida A / B |
|---|---|---|---|---|---|
| Início | Dois jogadores entram no pátio; nenhum disparo foi feito. | 2+4 / 2+4 | 5/5 | 0/3 | 3 / 3 |
| Onda 1 | Surgem dois caminhantes. A e B acertam um cada; ambos são derrotados. | 1+4 / 1+4 | 5/5 | 0/3 | 3 / 3 |
| Intervalo 1 | A carrega uma vez. B recarrega uma bala. | 1+4 / 2+3 | 5/5 | 1/3 | 3 / 3 |
| Onda 2 | Surgem três caminhantes. A e B acertam um cada; resta um, que causa 1 de dano ao portão quando o tempo acaba. | 0+4 / 1+3 | 4/5 | 1/3 | 3 / 3 |
| Intervalo 2 | B carrega uma vez. A recarrega duas balas. | 2+2 / 1+3 | 4/5 | 2/3 | 3 / 3 |
| Onda 3 | Surgem quatro caminhantes. Cada sobrevivente derrota um; restam dois e causam 2 de dano ao portão. | 1+2 / 0+3 | 2/5 | 2/3 | 3 / 3 |
| Intervalo 3 e extração | A carrega uma vez. B repara 1 ponto do portão. Depois, ambos entram na zona do caminhão. | 1+2 / 0+3 | 3/5 | 3/3 | 3 / 3 |
A aritmética é fácil de auditar: cada disparo remove uma bala carregada; o único caminhante restante na Onda 2 remove um ponto do portão; os dois restantes na Onda 3 removem dois; o reparo final acrescenta um. O sinalizador ganha um ponto em cada um dos três intervalos. Nenhum sobrevivente é atingido nesta rota escrita, então a vida continua em 3/3 e nenhuma permissão de reanimação é usada. Este percurso em papel não simula busca de caminho nem mira em tempo real; essas partes precisam de implementação e observação antes de qualquer alegação de funcionamento.
Use uma sequência de prompts em etapas
Não peça a um único prompt enorme para inventar regras, construir a arena, balancear ondas e polir o resultado de uma só vez. Separe as etapas para que uma regra ausente possa ser corrigida antes de virar uma interação ou visual confuso.
1. Peça um contrato de regras e estado
Projete um shooter fictício cooperativo local, visto de cima, de dois analógicos e na mesma tela, chamado Dead Air at Beacon Four. Antes de acrescentar arte, retorne uma tabela de estado compacta para dois sobreviventes, um pátio de retransmissão, três ondas de 20 segundos (2/3/4 caminhantes com 1 de vida), uma carabina fixa para cada pessoa, vida 3, carregador 2, reserva 4, portão 5, sinalizador 0/3 e um intervalo seguro de 8 segundos. Cada disparo consome sempre uma bala; um acerto derrota um caminhante; cada caminhante restante no limite da onda causa dano uma vez ao portão e vai embora. Em cada intervalo, cada pessoa pode carregar, recarregar até duas balas ou reparar um ponto do portão; as escolhas simultâneas são resolvidas juntas e a equipe ganha no máximo uma carga do sinalizador. Inclua regras de queda e reanimação, extração dos dois jogadores, derrota e reinício completo. Liste ambiguidades em vez de inventar mecânicas silenciosamente. Isto é uma solicitação de design, não alegação de que existe um protótipo.
Este prompt pede primeiro um modelo de estado explícito. Se a resposta mudar o limite de uma carga, tornar a reserva compartilhada ou permitir reiniciar com a reanimação já usada, resolva o conflito antes de pedir a cena.
2. Peça somente o primeiro trecho jogável
Com base na tabela acordada, solicite uma arena jogável com dois jogadores na mesma tela, uma carabina idêntica para cada um, portão, sinalizador âmbar, três ondas crescentes, intervalo de 8 segundos e uma zona de extração. Mostre vida, munição carregada e reserva, integridade do portão, carga do sinalizador, onda atual e tempo restante com retorno legível. Implemente as escolhas simultâneas do intervalo especificadas, cronômetro de queda de 10 segundos, reanimação de 2 segundos a até 2 metros que restaura 1 de vida, uma reanimação por sobrevivente, derrota com portão zero e reinício que redefina cada valor listado. Exclua campanhas, chefes, melhorias de armas, desvios, arenas extras e jogo on-line. Retorne os controles e uma lista breve para inspecionar os estados; não declare concluído um teste não observado.
Um pedido focado limita as variáveis, mas um resultado gerado ainda precisa ser inspecionado. Se o fluxo real oferecer um resultado jogável, compare controles e estado visíveis com o contrato, em vez de presumir que toda mecânica solicitada foi implementada.
3. Revise uma divergência após uma observação real
Depois que eu fornecer uma ação real e o estado observado, compare-o com este estado esperado: [cole a linha exata da onda/intervalo]. Altere somente a regra ou o retorno responsável pela divergência. Preserve o estado da outra pessoa, portão, sinalizador, munição e tempo. Retorne a regra alterada, valores esperados antes/depois e uma verificação repetível. Se não houver execução observada anexada, não invente uma falha nem diga que esta verificação passou.
Este terceiro prompt é intencionalmente condicional. Neste pacote não há execução observada para colar, então ele continua sendo um modelo, não uma iteração concluída. Mantenha a distinção ao publicar um tutorial: um exemplo resolvido à mão pode ensinar o que inspecionar, mas não substitui um resultado de teste.
Confira a interação, não apenas a quantidade de inimigos
Quando houver um protótipo real, confira um estado observável por vez. São verificações de aceitação planejadas, não resultados. Registre a entrada, a mudança esperada e o valor observado para manter delimitada qualquer correção.
| Verificação planejada | Resultado esperado | O que uma divergência indicaria |
|---|---|---|
| Ambos escolhem Carregar em um intervalo. | Sinalizador aumenta somente um ponto. | Falta limite de carga da equipe ou resolução simultânea. |
| Disparar com carregador vazio. | Nenhum disparo é criado; munição continua em zero. | Retorno de entrada ou regra de custo do disparo não está clara. |
| Recarregar com 1 carregada / 4 na reserva. | No máximo duas balas são transferidas, ficando 2 carregadas / 3 na reserva. | Quantidade transferida ou limite da reserva diverge. |
| Deixar um caminhante na onda quando o tempo acaba. | Portão perde exatamente um ponto e o caminhante daquele encontro sai. | Limpeza ou dano no limite da onda está sendo aplicado duas vezes. |
| Derrubar um sobrevivente e reanimá-lo dentro de alcance e tempo. | Manter Interagir por 2 segundos a até 2 metros; restaurar 1 de vida e limpar o cronômetro de 10 segundos. | Alvo, alcance, duração ou estado de recuperação precisa de correção. |
| Derrubar de novo a mesma pessoa após usar sua permissão. | A partida termina imediatamente. | Indicador de reanimação por sobrevivente não é persistente. |
| Terminar Onda 3 com sinalizador carregado, mas um jogador fora da extração. | Não há vitória até ambos entrarem na zona do caminhão. | Condição de conclusão compartilhada está incompleta. |
| Reiniciar após dano e reanimação. | Onda 1, vida 3 para cada pessoa, portão 5, sinalizador 0, carregadores 2, reservas 4 e as duas permissões de reanimação disponíveis. | Algum estado da partida vazou pelo reinício. |
Não chame uma interação de “testada” porque o prompt a menciona ou porque uma imagem conceitual mostra seu retorno. Um teste precisa de protótipo real, entrada repetível e saída observada. Até lá, identifique a tabela como plano.
Use a página geral de sobrevivência como ponto de partida delimitado
A página oficial atual do AI Survival Game Generator descreve um fluxo amplo de planejamento de sobrevivência: suprimentos limitados, pressão ambiental legível, objetivo seguro e recuperação de erros. Esses elementos ajudam a estruturar um primeiro briefing de sobrevivência. A página não comprova regras específicas de zumbis, controles para dois jogadores, cooperativo local na mesma tela ou rede. Mantenha essas mecânicas no seu contrato de design e inspecione o que um resultado atual realmente oferece.
Como ponto de partida geral de produto, use a página de jogo de sobrevivência com IA. A rota da fonte está atual, mas o caminho candidato deste Blog é provisório e o slug de origem só serve como atribuição local. Confirme a URL de Blog aceita e reconcilie o slug antes da publicação. Não infira que a página criou este exemplo nem oferece seus sistemas cooperativos. Crie jogos com IA grátis
Faça uma revisão com base em uma observação
Quando houver um resultado jogável, compare a primeira divergência de estado com a tabela de regras. Se uma onda deixar dois caminhantes, mas causar três danos ao portão, inspecione o evento do limite da onda antes de mudar ao mesmo tempo velocidade dos inimigos, vida dos jogadores e sinalizador. Altere uma causa, repita o mesmo caso e registre o novo estado. Assim, uma iteração útil fica ligada a evidências.
Como nenhum resultado jogável foi fornecido, o próximo passo responsável é tratar o ciclo fictício como especificação pronta para papel e as verificações como não executadas. Adapte os valores, peça um primeiro trecho focado e só então substitua o modelo por observações medidas. Acrescente chefe, mapa de campanha ou conjunto de armas depois que o ciclo básico para dois jogadores estiver visível e inspecionável.
Perguntas frequentes
O que torna cooperativa a primeira onda?
Dê aos dois jogadores um objetivo compartilhado e escolhas simultâneas suficientes para que suas decisões importem. Neste exemplo fictício, defendem um portão e carregam um sinalizador, enquanto cada pessoa pode mirar em um caminhante diferente. O design não presume a implementação exata dos controles; controles e comportamento da equipe precisam ser inspecionados em um protótipo real.
Como as três primeiras ondas devem crescer?
Altere um valor de pressão legível por vez. O exemplo começa com 2 caminhantes, depois 3 e depois 4, mantendo cada inimigo com 1 ponto de vida e cada onda em 20 segundos. São valores propostos em papel, não dificuldade medida. Um protótipo real precisaria de verificações repetidas do espaçamento de surgimento, tempo para mirar e pressão no portão.
Os dois jogadores devem compartilhar munição?
Este design dá a cada sobrevivente um carregador e reserva separados para que os disparos de uma pessoa não gastem silenciosamente o recurso da outra. Cada disparo custa uma bala carregada, e a recarga transfere no máximo duas balas. Munição compartilhada é outra opção, mas o primeiro prompt deve escolher um modelo e mostrar seus valores antes e depois.
O que acontece quando um sobrevivente cai?
Nesta regra proposta, vida zero inicia um cronômetro de 10 segundos. Uma pessoa parceira a até 2 metros mantém Interagir pressionado por 2 segundos; o sucesso restaura exatamente 1 ponto de vida e limpa o cronômetro. Cada sobrevivente só pode ser reanimado uma vez por partida; uma queda posterior depois de usar essa permissão encerra a partida. É uma regra de design fictícia, não um recurso testado.
Um prompt garante cooperativo on-line?
Não. Um prompt é uma solicitação, não prova de implementação. A página oficial do produto oferece apenas um contexto geral de planejamento de sobrevivência; não comprova jogabilidade específica de zumbis, controles cooperativos locais nem rede on-line. Inspecione um resultado atual real antes de descrever recursos e não afirme que este exemplo fictício foi gerado ou testado.
