Torne as ondas de inimigos legíveis antes de acrescentar movimentos
Para criar um beat ’em up lateral com IA, comece com uma sala em que a pessoa possa ler um ataque, evitar sua faixa e se recuperar antes de o próximo inimigo verificar um acerto. Um encontro com poucos inimigos não é justo só porque tem dois adversários; avisos, tempo de acerto, espaçamento e recuperação precisam oferecer uma escolha significativa. Este guia usa um Avançador e um Guarda para mostrar como transformar a ideia num briefing preciso para a primeira sala.
Sala e tempos abaixo são parâmetros de design fictícios, não resultado de prompt, jogo construído, teste com jogadores nem saída observada da SEELE. A comparação é um ensaio de tempo calculado à mão, pois não foi fornecida execução real ou versão jogável. Pode verificar se a programação escrita faz sentido, mas não provar que a versão funciona ou que as pessoas entendem as pistas.
Mantenha estreito o primeiro ciclo: ler o aviso → esquivar da faixa → recuperar a ação → punir a recuperação → derrotar o grupo → abrir a próxima sala. A decisão principal é quando o próximo inimigo entra em relação ao tempo de recarga da esquiva. Este é um tutorial de tempo de grupo, não de recuo nem de ricochete.
Defina os dois papéis inimigos e a ordem das ações
Chame a sala de Fundição em Marcha. Ela vai da posição horizontal 0 à 12 e tem faixa próxima e distante. A pessoa começa em x=2 na faixa próxima; o portão de saída fica em x=11. Em cada marca de tempo, o comando da pessoa é resolvido antes das verificações de acerto inimigas. Trocar de faixa leva 0,25 segundo. Esquivar desloca uma unidade horizontal e troca de faixa em 0,25 segundo, evita acertos verificados nesse intervalo e depois entra em recarga de 0,75 segundo. Um golpe leve atinge o inimigo mais próximo a até 1,5 unidade na mesma faixa; um inimigo em recuperação pode receber um acerto.
| Ator ou estado | Regra fixa da primeira sala | O que a pessoa consegue ler |
|---|---|---|
| Avançador | Começa em x=0 na faixa próxima; avisa por 0,75 s; avança +3 pela faixa próxima; verifica o acerto depois da ação da pessoa; recupera de t=1,0 a 1,75. | Uma pista clara na faixa próxima marca o caminho do avanço antes do movimento. |
| Guarda | Entra em x=2,5 na faixa próxima após atraso d; telegrafa varredura de 0,75 s; verifica um retângulo fixo x=1,5 a 3,5 nas duas faixas; depois recupera por 0,75 s. | Uma pista ampla mostra que apenas trocar de faixa não evita o retângulo de acerto. |
| Pessoa | Começa em x=2 na faixa próxima. A esquiva vai a x=3 na outra faixa e fica pronta outra vez 0,75 s após terminar. | Estado da ação e recarga devem se distinguir da recuperação do ataque. |
| Grupo e portão | Derrote Avançador e Guarda para levantar o portão. Alcançá-lo carrega uma segunda sala com as mesmas regras. Reiniciar restaura vida, posições, atraso e portão. | Derrota e portão aberto recebem retornos visuais separados. |
O caminho do Avançador na faixa próxima cruza o x=2 inicial da pessoa. Em t=0,75, o comando de esquiva é resolvido antes da verificação do golpe, movendo-a de (2, próxima) para (3, distante). O Avançador continua pela faixa próxima. A esquiva termina em t=1,0 e a recarga em t=1,75. O Guarda precisa ser programado em relação a essa disponibilidade, não inserido apenas quando a sala parece vazia.
Escapar para outra faixa ajuda contra o Avançador, mas não é uma condição universal de segurança: o retângulo definido para o Guarda cobre as duas faixas. Essa distinção evita um erro comum de legibilidade. Se a arte mostra varredura entre faixas, mas as regras só atingem a próxima, a pessoa não consegue deduzir o perigo real. Mantenha imagem, aviso e área de colisão coerentes.
Peça um encontro pequeno com retorno observável
Um bom prompt nomeia arena, controles, mudanças de estado dos inimigos, ordem das ações, falha e reinício. Também informa o que ainda não deve ser incluído. O prompt abaixo é artefato de design para um jogo hipotético; não foi executado e cada mecânica precisa ser inspecionada numa futura versão jogável.
Crie uma sala compacta de beat ’em up 2.5D com vista lateral chamada Fundição em Marcha. Use arena horizontal de 0 a 12 com faixas próxima e distante. Comece a pessoa em x=2 na faixa próxima e coloque um portão de saída fechado em x=11. Dê à pessoa um golpe leve que alcance o inimigo mais próximo a até 1,5 unidade na mesma faixa, troca de faixa em 0,25 s e esquiva que percorra uma unidade horizontal e troque de faixa em 0,25 s, evitando verificações de acerto nesse intervalo; após a esquiva, a recarga dura 0,75 s. Em cada instante, resolva o comando da pessoa antes da verificação de acerto dos inimigos. Coloque um Avançador em x=0 na faixa próxima. Mostre aviso claro de 0,75 s na faixa próxima, depois avance +3 unidades por ela e verifique o golpe após a ação da pessoa. Dê a ele recuperação de t=1,0 a t=1,75; durante ela, pode receber um golpe leve. Coloque um Guarda em x=2,5 na faixa próxima após atraso d. O aviso de 0,75 s mostra a área fixa de varredura x=1,5 a x=3,5 nas duas faixas. Verifique essa área depois da ação da pessoa; então dê ao Guarda recuperação de 0,75 s e vulnerabilidade a um golpe. Use d=0,5 no cenário inicial em papel; mantenha todos os outros valores fixos ao comparar d=1,5. Mostre retornos distintos para aviso, esquiva, acerto, recuperação, derrota e portão aberto. Só abra o portão após derrotar ambos. Inclua reinício que restaure vida, posições, atraso de entrada e estado do portão. Não acrescente armas de longo alcance, chefes, árvores de progressão, violência gráfica, tempos aleatórios ou outros inimigos. Facilite a inspeção de hitboxes, linha do tempo, recarga e reinício. É um briefing fictício, não evidência de que o jogo foi gerado ou testado.
Depois de qualquer geração futura, confira a primeira sala segundo esse contrato antes de acrescentar recursos. Verifique se há um Avançador e um Guarda, se os avisos precedem as verificações e se as áreas atingidas correspondem às faixas mostradas. Se a ferramenta devolver um protótipo jogável, trate-o como ponto de partida: ainda precisa ser testado, não presumido correto por causa do prompt.
Trace por que o surgimento após meio segundo coincide com a recarga
Use uma linha do tempo em vez de dizer que a onda é “rápida demais”. O atraso inicial do Guarda é d=0,5 s; seu aviso de 0,75 s termina e a verificação ocorre em t=1,25. A sequência inicial do Avançador já exigiu esquiva em t=0,75. A esquiva termina em t=1,0, e a pessoa só pode esquivar novamente em t=1,75. A verificação do Guarda ocorre meio segundo antes de a próxima esquiva ficar disponível.
| Horário | Estado da pessoa no traçado em papel | Evento e verificação do inimigo | Resultado definido |
|---|---|---|---|
| 0,00–0,75 | Em x=2, faixa próxima; pode ler o aviso do Avançador. | Avançador sinaliza avanço pela faixa próxima. | A resposta pretendida é esquiva cronometrada, não ataque às cegas. |
| 0,75 | Esquiva termina em x=3, faixa distante. | Avançador avança de x=0 a x=3 na faixa próxima e verifica o trajeto. | A mudança de faixa evita o golpe pela faixa próxima. |
| 1,00 | Animação da esquiva acaba; recarga até 1,75. | Avançador inicia sua recuperação. | A pessoa pode planejar um contra-ataque, mas deve considerar o horário do Guarda. |
| 1,25 | Esquiva indisponível; x=3 continua dentro do alcance do Guarda. | Com d=0,5, o Guarda verifica x=1,5–3,5 nas duas faixas. | A pessoa sofre um acerto neste cenário fictício em papel. |
O retângulo do Guarda cobre ambas as faixas, então a esquiva contra o Avançador não protege dessa varredura. Em x=3, a pessoa também está dentro do intervalo horizontal. O erro decorre da programação fixa, recarga e área de acerto; não de perseguição invisível nem de mudança de comportamento do inimigo. É um traçado fictício para conferir regras, não uma sessão de jogo registrada.
Confira no papel uma mudança de tempo
Altere somente o atraso do Guarda, de 0,5 para 1,5 s. Mantenha posição x, aviso de 0,75 s, área fixa nas duas faixas, dano, movimento da pessoa, percurso do Avançador e condição do portão. A verificação do Guarda passa de t=1,25 para t=2,25. A esquiva fica pronta em t=1,75. Em t=2,25, a pessoa esquiva de x=3 para x=4 antes da verificação; x=4 fica fora do intervalo fixo x=1,5–3,5, então evita o golpe.
É um cálculo em papel com uma variável alterada. Não demonstra que 1,5 segundo seja divertido, dê tempo confortável de reação ou que uma implementação siga a ordem pretendida. Mostra apenas que a programação revisada permite à esquiva definida sair da área fixa na hora de verificar. Uma versão futura deve testar se a pista é legível e se as ações disponíveis parecem justas.
O resultado completo vai além de uma esquiva segura. Avançador e Guarda precisam entrar em estados legíveis, oferecer uma janela de contra-ataque e depois mudar para um retorno claro de derrota. Só após derrotar ambos o portão deve abrir. A comparação isola a programação do Guarda para verificar uma decisão sem alterar silenciosamente dano, geometria ou comportamento inimigo.
Diagnostique a primeira sala antes de ampliá-la
Se uma versão futura falhar no encontro pretendido, identifique o primeiro ponto em que o estado visível diverge das regras. Evite alterar vários tempos juntos: novo atraso de entrada, preparação mais curta, esquiva maior e hitbox menor impediriam saber qual ajuste importou. A tabela vincula cada diagnóstico a uma verificação observável.
| Sintoma | Confira primeiro | Correção focada |
|---|---|---|
| O Avançador acerta antes do fim do aviso. | Compare fim do aviso, início do avanço e horário da verificação. | Restaure aviso de 0,75 s e confira que a ação ocorre antes do acerto. |
| O aviso do Guarda indica uma faixa, mas ele atinge as duas. | Compare a área visualizada com x=1,5–3,5 em ambas as faixas. | Faça prévia e colisão coincidirem; não reduza secretamente o retângulo definido. |
| A mesma esquiva fica indisponível em horários diferentes. | A recarga começa após terminar a esquiva de 0,25 s? | Mantenha disponibilidade em 1,75 após a esquiva em t=0,75 e teste as duas programações. |
| Um inimigo derrotado ainda bloqueia o portão. | A condição de grupo completo aguarda ambos os estados de derrota? | Abra apenas quando ambos forem derrotados; confirme que reinício fecha o portão. |
| O golpe erra durante a recuperação. | Confira distância, faixa, seleção do inimigo mais próximo e vulnerabilidade a um golpe. | Mantenha alcance de 1,5 na mesma faixa e teste um contra-ataque de cada vez. |
Registre observações separadamente da programação em papel. Num protótipo real, anote versão, entradas exatas, pista visível, resultado da verificação, estado do reinício e qualquer divergência. Um prompt não substitui essas observações, e um quadro gerado não prova que o tempo funcionou.
Use um criador de jogos com IA como fluxo inicial
A página atual do Criador de Jogos com IA Grátis da SEELE descreve um processo geral: explicar um jogo em linguagem simples, gerar uma primeira versão jogável 2D ou 3D, testá-la no navegador e refiná-la com prompts seguintes. Informa que o Workspace exibe modelo selecionado, saldo disponível de Koin e custo de geração antes do envio, e aconselha conferir o custo antes de cada geração. Esses fatos gerais não garantem programação de inimigos, área de colisão ou sala de beat ’em up específicos.
Para este design, apresente em um único briefing focado arena, ações da pessoa, avisos, ordem temporal, áreas de acerto, condição de conclusão e reinício. Se houver resultado jogável, inspecione cada regra e anote diferenças. No Workspace, confira modelo, saldo de Koin e custo exibido antes do envio. Mantenha os números definidos na lista de aceitação, não como alegação de que o produto já os entregou.
Essa distinção torna útil o próximo passo: uma pessoa criadora pode explorar a ideia usando um fluxo amplo de prompt para jogo jogável e, ao mesmo tempo, validar a lógica específica no resultado real.
Continue com uma sala legível de beat ’em up
Mantenha o primeiro encontro em um Avançador, um Guarda, uma regra de esquiva e um portão que só abre quando ambos forem derrotados. Primeiro confira se cada pista corresponde à área atingida; depois compare o próximo surgimento com o momento de recarga da esquiva. Só acrescente outro inimigo quando a pessoa entender e responder à onda. Os tempos são valores de design em papel, não balanceamento testado.
Quando quiser transformar o briefing em protótipo, comece pelo criador de jogos com IA grátis, confira o custo atual e inspecione o resultado jogável segundo o contrato da sala. Preserve a tabela de tempo, faça uma verificação em jogo real e altere uma variável por vez. Criador de jogos grátis com IA
Perguntas frequentes
Qual é o primeiro ciclo de um beat ’em up lateral?
Comece com aviso legível, esquiva de faixa, janela de recuperação e retorno claro de grupo concluído. A pessoa precisa saber por onde virá o ataque e quando o inimigo pode ser punido. Neste exemplo, dois oponentes bastam para ensinar espaçamento e tempo antes de acrescentar chefes, armas ou progressão.
Por que o atraso de 0,5 segundo do Guarda causa um acerto?
Após esquivar em t=0,75, a esquiva termina em t=1,0 e só fica disponível novamente em t=1,75. Com d=0,5, o Guarda termina seu aviso de 0,75 s em t=1,25, quando a pessoa ainda está na área fixa x=1,5–3,5 que cobre ambas as faixas. É um traçado fictício em papel.
A revisão de 1,5 segundo conta como teste com jogadores?
Não. É um cálculo manual: a esquiva definida fica pronta na verificação revisada do Guarda em t=2,25 e pode mover a pessoa a x=4 antes dela. Não mostra versão gerada, reação humana nem se o encontro parece justo. Isso exige resultado jogável e teste observado.
O que inspecionar num protótipo jogável de beat ’em up?
Compare cada aviso com a área de acerto real, confirme que a ação da pessoa ocorre antes da verificação no mesmo instante, cronometre a recarga da esquiva, verifique vulnerabilidade na recuperação e reinicie o encontro inteiro. Registre entrada e resultado exatos. Se uma regra divergir, isole uma mudança e confira de novo, em vez de ajustar vários tempos juntos.
Um criador de jogos com IA garante este tempo de inimigo?
Não há garantia de um tempo específico no fluxo geral descrito para o produto. Um briefing em linguagem simples comunica o ciclo solicitado, e uma versão jogável 2D ou 3D pode ser revisada e refinada. Ainda é necessário inspecionar avisos, áreas de colisão, recargas, condição do portão e reinício reais.
