Um prompt de plataforma de precisão fica mais fácil de revisar quando define movimento, tempo, falha e o estado exato que conta como vitória. Comece com uma rota curta, dê duração a cada ação e trace uma tentativa bem-sucedida e um reinício antes de pedir mais níveis ou acabamento visual.
Este guia oferece um kit reutilizável de prompts em três etapas e um exemplo conferível à mão chamado Beatglass Crossing. O nível e a rota são um design fictício original. Os prompts de jogo abaixo não foram enviados; não se afirma versão jogável, sessão de jogador nem resultado de teste. O registro de batidas é uma simulação em papel sob suposições declaradas.
Delimite uma única questão de plataforma com tempo
Escolha um primeiro recorte que responda a uma pergunta de design: o jogador consegue ler uma persiana cíclica, esperar numa peça segura e pousar durante a janela aberta? Limite o elenco a uma mensageira, a rota a duas lacunas e um checkpoint e o objetivo a chegar a uma saída marcada. Esse escopo restrito dá espaço ao prompt para definir a regra de tempo, sem enterrá-la sob inimigos, colecionáveis e níveis extras.
Beatglass Crossing é um percurso fictício 2.5D de vista lateral, criado para este artigo. Seu mapa de peças, batidas, fases do portão e comportamento de reinício são suposições de design do autor. Não são observações de jogo existente nem medidas de um sistema de movimento.
A capa mostra a decisão antes de acontecer: o estado atual do portão difere do estado previsto na chegada. O jogador vê por que esperar importa sem precisar de pontuação, painel extra de HUD ou poder sem explicação.
Escreva o contrato de batidas e pouso
Use posições nomeadas e durações de ação. Neste modelo em papel, cada peça horizontal é uma unidade; “batida” é um relógio de design discreto, não alegação sobre física natural de saltos. Uma batida foi definida como seis passos fixos a uma frequência nominal de 60 Hz, ou 0,1 segundo. A rota só confere o portão quando a mensageira entra na peça dele.
| Trecho do percurso | Peças | Regra |
|---|---|---|
| Plataforma inicial | x=0–2 | Piso seguro; tentativa começa em x=0, batida 0. |
| Primeira lacuna | x=3 | Salto de x=2 a x=4 atravessa esta única peça vazia. |
| Plataforma do checkpoint | x=4–5 | Pousar em x=4 ativa o checkpoint; x=5 é a peça de aproximação. |
| Segunda lacuna | x=6 | Salto de x=5 pousa na peça da persiana x=7. |
| Persiana cronometrada | x=7 | Aberta nas fases 0 ou 1; fechada nas fases 2 ou 3; verificar ao entrar. |
| Plataforma de saída | x=8–9 | Piso seguro; chegar a x=9 depois de cruzar a persiana vence. |
Mantenha explícito também o contrato de comandos. Correr à Direita move uma peça e avança uma batida. Esperar mantém a posição numa peça segura e avança uma batida. Saltar à Direita move exatamente duas peças por duas batidas e atravessa uma lacuna intermediária; esta ação simplificada é resolvida no destino. A fase do portão é beat mod 4. Se a mensageira tentar entrar em x=7 quando fechado, ou correr para uma lacuna, cancele o movimento, mostre um aviso de bloqueio ou queda, volte ao checkpoint mais recente e reinicie o relógio da tentativa na batida 0. Não há pontuação, vida nem estado de colecionáveis.
A imagem do mecanismo foca na verificação de pouso, não num salto genérico. A peça da persiana, a lacuna vazia, a mensageira no chão e o indicador de fase representam o mesmo estado escrito.
Construa prompts em etapas
Uma biblioteca de prompts deve facilitar revisões. Peça primeiro o percurso e o objetivo, acrescente movimento e tempo em seguida e então feedback e casos de revisão. Os três prompts abaixo são modelos prontos para copiar, mas não foram executados. Substitua escolhas entre colchetes antes de usá-los numa versão futura; mantenha o relatório pedido vinculado ao estado visível do jogo.
Prompt 1: defina o recorte jogável
Crie um recorte fictício de plataforma de precisão chamado [título provisório]. Use câmera lateral e um percurso compacto de x=0 a x=9. O jogador controla uma mensageira cujo objetivo é alcançar x=9. Coloque piso inicial seguro em x=0–2, uma lacuna de uma peça em x=3, piso de checkpoint em x=4–5, uma lacuna de uma peça em x=6, uma persiana cronometrada em x=7 e piso de saída seguro em x=8–9. Ative o checkpoint quando o jogador pousar em x=4. Use um único relógio discreto de batidas e exponha posição atual, batida, fase do portão, checkpoint e vitória por feedback simples com ícones. Não acrescente outra lacuna, inimigo, colecionável, pontuação nem habilidade de movimento. Retorne o mapa e o estado inicial antes de acrescentar arte.
Esta primeira etapa restringe o tamanho do nível e informa ao futuro revisor quais variáveis de estado precisam ser inspecionáveis. Se o layout mudar, atualize o mapa de peças antes de mudar as regras de movimento.
Prompt 2: especifique movimento e portão cronometrado
Mantenha o percurso aprovado de x=0–9. Implemente somente estas entradas do design em papel: Correr à Direita avança uma peça segura em uma batida; Esperar permanece numa peça segura por uma batida; Saltar à Direita move exatamente duas peças em duas batidas e pode atravessar uma lacuna intermediária. Use phase = beat mod 4. A persiana em x=7 fica aberta nas fases 0 e 1 e fechada nas fases 2 e 3; só verifica quando o jogador entra em x=7. Um salto para x=7 se resolve no fim de suas duas batidas. Se a entrada ocorrer quando estiver fechada, ou uma Corrida entrar numa lacuna, cancele o movimento, mostre um aviso claro de bloqueio/queda, volte ao checkpoint mais recente e defina beat=0. Não acrescente impulso contínuo, altura de salto variável, controle no ar, pulo na parede, outro portão nem outra regra de tempo. Retorne uma tabela de estados para cada entrada.
Esta etapa elimina termos vagos como “salto difícil” e “abre na hora certa”. Ela pede diretamente a verificação de tempo e o estado de reinício, para que um revisor compare o estado mostrado com a regra escrita.
Prompt 3: peça feedback e um plano de revisão
Mantenha inalterados o percurso e as regras aprovadas. Mostre a fase de batida atual com quatro luzes pequenas, use turquesa para persiana aberta e vermelho para fechada e mostre um brilho discreto de pouso somente depois de um pouso seguro. Em x=9, acenda o sino de saída de latão e marque vitória. Numa entrada com portão fechado ou queda na lacuna, dê um único aviso breve, depois restaure o checkpoint e batida 0. Forneça: (1) registro de estados/entradas de sucesso, (2) registro de falha sem espera, (3) registro de recuperação do checkpoint e (4) critérios de aceitação para as duas lacunas, entrada aberta/fechada, reinício da fase e saída. Separe previsões de observações. Não afirme que um caso passou sem inspecionar uma versão registrada do jogo.
Pedir juntos o registro de estado e os critérios de aceitação ajuda a revelar contradições antes de acrescentar um segundo nível. Se uma versão futura usar controles ou tempo diferentes, registre a versão real e revise o contrato em vez de alterar silenciosamente a tabela esperada.
Confira à mão Beatglass Crossing
A rota bem-sucedida é Correr, Correr, Saltar, Correr, Esperar, Saltar, Correr, Correr. Como um salto consome duas batidas, registre a fase final, não apenas a fase inicial.
| Entrada | Batida após a entrada | Posição | Fase da persiana | Verificação em papel |
|---|---|---|---|---|
| Início | 0 | x=0 | 0, aberta | Plataforma inicial; relógio zerado. |
| Correr | 1 | x=1 | 1, aberta | Avanço em peça segura. |
| Correr | 2 | x=2 | 2, fechada | Na borda antes da lacuna x=3. |
| Saltar | 4 | x=4 | 0, aberta | Cruzar x=3; ativar checkpoint. |
| Correr | 5 | x=5 | 1, aberta | Peça segura de aproximação. |
| Esperar | 6 | x=5 | 2, fechada | Esperar com segurança uma batida. |
| Saltar | 8 | x=7 | 0, aberta | Cruzar x=6; entrar pela persiana aberta. |
| Correr | 9 | x=8 | 1, aberta | Alcançar plataforma de saída. |
| Correr | 10 | x=9 | 2, fechada | Vitória; portão se fecha atrás da mensageira. |
Em x=5, um salto imediato terminaria na batida 7, fase 3, então a entrada é bloqueada e a tentativa reinicia. Esperar avança o relógio para a batida 6; o próximo salto de duas batidas chega a x=7 na batida 8, fase 0. A rota só funciona como escrita porque o relógio inclui as duas batidas do salto.
Esta ilustração do resultado mostra um estado final inventado e resolvido à mão. Não é captura de uma versão do jogo, e o sino é uma indicação visual de objetivo, não evidência de teste concluído.
Defina o reinício do checkpoint
Uma nova tentativa precisa de um estado completo de reinício. Se o jogador entrar na persiana quando fechada na batida 7, restaure o checkpoint em x=4 e zere o relógio na batida 0. Então a rota de recuperação é Correr, Esperar, Saltar, Correr, Correr: chegar a x=5/batida 1, esperar até a batida 2, saltar para x=7 na batida 4/fase 0 e então correr por x=8 até x=9 na batida 6. A posição do checkpoint e o reinício do relógio são necessários; preservar a batida 7 produziria outra fase de portão.
Use a mesma regra após uma queda na lacuna. Cancele a ação falha, mostre a causa, restaure o checkpoint mais recente, zere o relógio da tentativa e mantenha inalterada a geometria do percurso. Isso torna útil uma falha: o jogador sabe qual regra ajustar e pode tentar novamente a partir de um estado nomeado.
Num teste futuro com jogadores, registre sequência exata de entradas, checkpoint inicial, batida, fase da persiana e posição retornada. Aqui, a rota é apenas repetida conforme a tabela declarada; nenhuma sessão de jogo foi registrada.
Transforme a repetição em critérios de aceitação
Antes de acrescentar conteúdo, transforme o modelo em papel em perguntas observáveis. São critérios de aceitação propostos para uma versão futura, não resultados já obtidos.
| Caso futuro | Estado esperado em papel | O que inspecionar numa versão real |
|---|---|---|
| Primeiro salto saindo de x=2 | Pousar em x=4 depois de duas batidas e ativar o checkpoint. | Posição de pouso e indicador de checkpoint. |
| Segundo salto após uma espera | Entrar em x=7 na batida 8/fase 0, com portão aberto. | Estado do portão ao pousar e ausência de aviso de queda. |
| Segundo salto sem esperar | Tentar entrada na batida 7/fase 3, com portão fechado; reiniciar em x=4/batida 0. | Cancelamento do movimento, aviso de bloqueio, checkpoint e relógio. |
| Correr em direção a uma lacuna | Cancelar movimento e restaurar o checkpoint mais recente. | Feedback de queda e estado reiniciado. |
| Saída depois da travessia | Alcançar x=9 e manter a vitória mesmo quando a fase 2 fecha atrás. | Feedback da saída permanece mesmo com portão fechado. |
Quando um resultado real estiver disponível, registre-o ao lado do estado esperado e mantenha a versão do jogo. Se um caso falhar, mude uma regra por vez — por exemplo, período do portão ou duração do salto — e repita as rotas de sucesso e falha. Não chame uma tabela manual de resultado de teste.
Leve o briefing a um fluxo de criação
Quando o prompt descrever uma primeira ação pequena e um alvo claro, você pode levar o briefing a um fluxo de criação de jogos. A página atual do Free AI Game Maker descreve entrada de ideias em linguagem simples, uma primeira versão jogável em 2D ou 3D, testes no navegador e refinamento com prompts seguintes. Oferece Koins gratuitos e pede aos criadores que confiram o custo antes de cada geração. São fatos gerais do fluxo; não demonstram que Beatglass Crossing, suas regras de tempo ou este prompt tenham sido gerados.
Numa iteração futura, compare a versão revisada com o mapa, contrato de controles, tabela de fases e estado de reinício do prompt. Mantenha uma correção específica por etapa, como tornar a persiana aberta mais legível ou mostrar o checkpoint após o reinício. Inspecione o resultado e o comportamento reais antes de tratar qualquer regra como implementada.
Mantenha a próxima revisão vinculada ao mapa declarado, contrato de movimento, fase do portão, estado de reinício e condição de vitória. Uma versão posterior pode divergir do exemplo em papel; registre o que faz antes de decidir qual regra revisar.
Comece com uma rota que possa revisar
Comece com uma única travessia cronometrada, peça o registro de estados e compare o resultado com o contrato impresso. Quando esses detalhes estiverem visíveis, escolha uma correção para explorar numa iteração futura. Os valores de Beatglass continuam sendo um modelo didático inventado e resolvido à mão, não evidência de jogo gerado.
Leve a ideia focada ao fluxo geral de criação: Free AI game maker. Crie jogos com IA grátis
Perguntas frequentes sobre prompts de plataforma de precisão
O que torna específico um prompt de plataforma de precisão?
Ele nomeia posições do percurso, deslocamento e duração de cada ação, regra de tempo, momento de verificação, feedback de falha, estado de reinício e condição exata de vitória. “Deixe o salto difícil” não diz o que o jogo deve fazer. Um registro curto mostra se essas expectativas são coerentes antes de acrescentar sistemas.
Um salto deve ter duração fixa?
Para um primeiro modelo determinístico em papel, sim: especifique deslocamento e batidas, além das lacunas que ele pode atravessar. Um motor futuro pode usar movimento contínuo, mas isso exigiria outro contrato e uma verificação registrada. O salto de duas batidas aqui é uma suposição de design.
Como descrever um portão cronometrado?
Informe período, fases abertas, fases fechadas e o evento exato de verificação. Beatglass confere somente quando se entra em x=7. A regra não muda no meio do salto. Declare se cada ação avança o relógio e qual fase o reinício restaura.
O que deve acontecer depois de uma tentativa de entrada no portão que falha?
Cancele o movimento, mostre um aviso de bloqueio, volte ao checkpoint mais recente e reinicie o relógio da tentativa na batida 0. Especifique posição e estado de tempo para que a nova tentativa possa ser traçada. Neste exemplo, não há pontuação, vida nem colecionáveis que exijam outra regra de reinício.
Beatglass Crossing foi criado ou testado com jogadores?
Não. O percurso é fictício e a rota foi resolvida à mão no papel. Os modelos de prompt não foram enviados; não se afirma versão jogável, teste de jogo nem resultado observado. As imagens geradas são ilustrações conceituais, não capturas do jogo. Os valores impressos descrevem somente estas regras inventadas, não comportamento de implementação observado.
