Um prompt para construção voxel fica mais fácil de inspecionar quando nomeia as células que podem ser editadas, como os recursos mudam, o que dá apoio a um bloco colocado e o que conta como vitória. Comece pelo contrato de regras, peça somente o menor ciclo jogável e reserve um terceiro prompt para diagnosticar uma divergência depois que alguém observar o resultado.
Este guia usa Mosslight Span, um exercício inventado para uma pessoa construir uma ponte até um farol. O mapa, as regras e a comparação de V0 com V1 são material didático original, resolvido manualmente. Os três modelos de prompt não foram enviados a um gerador de jogos; não existe implementação jogável, execução de prompt, teste de software, teste de jogo nem resultado medido.
O resultado prático é uma sequência curta: definir um mundo editável, especificar mineração e colocação, pedir uma implementação delimitada e comparar qualquer implementação futura com verificações declaradas. Essa sequência transforma “crie um sandbox voxel” num pedido que pode ser avaliado de verdade.
Defina um mundo editável pequeno
Um primeiro recorte voxel útil precisa de destino, obstáculo, decisão sobre recursos e sinal de conclusão. Mosslight Span reúne esses elementos numa travessia estreita. A pessoa exploradora começa numa plataforma estável próxima, na célula de superfície (0,1), com dois blocos de pedra. Do outro lado de uma ravina de três células ficam os espaços vazios x=1, x=2 e x=3; uma plataforma distante e um farol apagado ocupam x=4. O único objetivo é alcançar o farol.
A vista inicial estabelece uma escolha de design, não um resultado bem-sucedido. Dois blocos não preenchem três células vazias, então é preciso decidir se o orçamento de recursos deve mudar ou se deve haver outra rota. O exemplo escolhe um cubo reserva exposto numa plataforma lateral estável em (0,0,y=1), acima de um cubo de base permanente. Sua face lateral fica a uma face de grade da célula inicial, na altura de interação. A partir do início, uma ação Minerar coleta o cubo sem mover a pessoa exploradora; ela permanece em (0,1) e o inventário aumenta de dois para três.
Mantenha fechado o restante deste recorte. Só as três células da ravina podem receber blocos colocados. Um bloco precisa compartilhar uma face com a plataforma próxima ou com a sequência de ponte já apoiada. As plataformas permanentes e os blocos colocados na ponte não podem ser minerados. Não há inimigos, receitas, outros recursos, cronômetros, eventos aleatórios nem caminhos alternativos. Mineração, colocação ou movimento inválidos não mudam o estado. Reiniciar restaura exatamente o estado inicial da versão selecionada.
Esses limites tornam o prompt mais útil porque cada ação solicitada pode ser associada a um estado visível. “Mundo voxel”, por si só, deixa em aberto o mapa, o alcance da interação, o limite de construção e o objetivo. Aqui, as cinco células da superfície e a reserva lateral definem o que deve existir antes de considerar a decoração.
Escreva as regras de mineração, colocação e apoio
Palavras como minerar, colocar e andar precisam corresponder a mudanças de estado exatas. Neste exemplo no papel, minerar é uma única ação contra apenas o cubo reserva lateral exposto. A ação não move a pessoa nem exige uma etapa de aproximação. A colocação usa um cursor de construção sobre a zona de travessia de três células e também consome uma ação, sem caminhar até o alvo. Depois, o movimento avança exatamente uma célula ortogonal para uma superfície apoiada.
| Ação | Alvo válido e custo | Mudança de estado a conferir |
|---|---|---|
| Minerar reserva | A partir de (0,1), atinja apenas o cubo exposto em (0,0,y=1), adjacente por uma face na altura de interação; custa uma ação. | A reserva desaparece, o inventário aumenta em uma unidade e a pessoa exploradora permanece em (0,1). |
| Colocar bloco da ponte | Escolha uma célula vazia da travessia, x=1, 2 ou 3, em z=1; ela precisa se conectar por uma face à plataforma próxima ou à sequência apoiada. | O inventário diminui em uma unidade e a fileira contínua com apoio avança uma célula. |
| Mover | Avance exatamente uma célula ortogonal para uma superfície apoiada. | A posição muda; entrar em (4,1) depois que a rota existe acende o farol e vence. |
A ordem importa. Se o jogo permitir colocar blocos no vazio sem apoio, o quebra-cabeça de recursos desaparece. Se for possível minerar de qualquer distância, a posição da reserva deixa de importar. Se colocar um bloco também avançar a pessoa exploradora, o orçamento de ações muda. Especifique esses detalhes antes de pedir uma implementação jogável e diga que ações rejeitadas não gastam recursos nem movem a pessoa em silêncio.
Na visualização do mecanismo abaixo, a reserva já foi coletada do início, sem movimento; em seguida, foram colocados os blocos x=1 e x=2. A pessoa exploradora ainda está na plataforma próxima, resta um cubo de pedra, x=3 aparece como pré-visualização translúcida válida e o farol continua apagado. É um estado intermediário concreto para conferir numa implementação futura.
Prepare três prompts em ordem
Não peça que um único prompt invente as regras, construa o mundo e avalie o próprio sucesso de uma só vez. Dê a cada pedido uma entrada e uma saída claras. O primeiro fecha o contrato, o segundo pede uma implementação pequena e o terceiro espera uma observação real antes de propor um reparo.
Prompt 1: fixe as regras antes da implementação
Projete um ciclo minúsculo de construção voxel para uma pessoa, chamado {game_name}. Use as coordenadas de superfície {grid_and_start}, um objetivo {goal} e um inventário inicial {inventory}. Defina quais blocos podem ser editados, exatamente como funciona o alcance de mineração, como a mineração altera o inventário, o que torna válida uma colocação, como o apoio se propaga, quais movimentos são legais e quais são os estados exatos de vitória e reinício. Para o mapa fornecido, colete a reserva lateral exposta e adjacente por uma face a partir da célula inicial, usando uma ação Minerar sem se mover; retorne as coordenadas e o custo da ação. Forneça (1) uma tabela de coordenadas, (2) uma tabela de ação/estado, (3) casos extremos com inventário vazio e células sem apoio e (4) cinco verificações de aceitação. Não acrescente mecânicas que não foram pedidas. Aponte contradições antes de propor a implementação.
Para Mosslight Span, preencha os dados com a travessia de cinco células, o farol apagado em x=4 e dois blocos iniciais. Exija que a reserva esteja em (0,0,y=1), adjacente à posição inicial (0,1) na altura de interação, e que uma única ação Minerar a colete sem movimento. Peça ao modelo que repita o inventário após cada ação. Se o contrato acrescentar uma viagem de volta, mineração remota ou outra fonte de recursos, corrija as regras antes de usar o próximo prompt.
Prompt 2: peça somente o ciclo mínimo
Implemente somente este contrato voxel aprovado como um ciclo jogável compacto: {approved_contract}. Preserve todas as coordenadas, quantidades do inventário e custos de ação, incluindo uma ação Minerar a partir da célula inicial para coletar sem movimento a reserva adjacente por uma face. Inclua sinais visuais sem texto para colocação válida e inválida, mudança no inventário, movimento com apoio, vitória no farol e reinício. Permita editar blocos somente onde o contrato autoriza. Não acrescente inimigos, criação de itens, recursos extras, eventos aleatórios, multijogador, um segundo objetivo ou um mundo maior. Retorne os controles, um resumo curto da implementação e uma lista de evidências observáveis para cada verificação de aceitação. Marque como não verificado tudo que não foi implementado ou observado.
A restrição a um só ciclo é uma escolha de design, não uma promessa do que um gerador vai devolver. Um criador futuro pode acrescentar cenário depois que as regras de recursos e apoio estiverem visíveis. Peça um resumo da implementação e uma lista de verificação, mas não trate o pedido em si como evidência de que as verificações passaram.
Prompt 3: repare somente após uma observação
Estado esperado aprovado: {expected_state}. Observação real fornecida por uma pessoa: {observed_state_or_blank}. Compare somente a observação fornecida com as regras esperadas. Se a observação estiver em branco, retorne uma lista de verificação humana e não diagnostique um resultado. Se estiver preenchida, identifique a primeira divergência, a regra envolvida e a menor mudança de uma única variável que poderia resolvê-la. Indique qual verificação de aceitação deve ser repetida e quais verificações anteriores devem permanecer iguais. Não afirme que um reparo funcionou até que uma nova observação seja fornecida.
Este terceiro prompt se recusa deliberadamente a inventar um resultado. Se uma implementação futura parar depois de dois blocos, uma observação útil incluiria inventário inicial, alvo da reserva, posição da pessoa exploradora antes de minerar, estado da reserva após a ação e rejeição da colocação. Esses fatos ajudam a distinguir um problema de alcance de interação de um problema na quantidade de recursos ou no apoio. Sem eles, o próximo passo é registrar o estado, não declarar uma correção.
Confira manualmente o ciclo de recursos da ponte
A comparação fictícia altera uma variável: V1 acrescenta o cubo reserva exposto; V0 não tem reserva. Todo o resto, inclusive inventário inicial e rota, permanece igual. A tabela deixa visível a falta de recursos sem afirmar que um mecanismo ou modelo a produziu.
| Versão e ação | Células da ponte preenchidas | Inventário | Resultado manual |
|---|---|---|---|
| Início V0 | 0 | 2 | Não existe cubo reserva. |
| V0: colocar x=1 e depois x=2 | 2 | 0 | Os dois blocos têm apoio, mas x=3 continua vazio. |
| V0: tentar colocar x=3 | 2 | 0 | Rejeitado por inventário vazio; a plataforma distante continua inacessível. |
| V1: minerar a partir do início, sem mover | 0 | 3 | A reserva adjacente por uma face desaparece; o inventário passa de 2 para 3. |
| V1: colocar x=1, x=2 e depois x=3 | 3 | 0 | Cada bloco se conecta à plataforma próxima ou à sequência apoiada. |
| V1: mover x=0→1→2→3→4 | 3 | 0 | Quatro movimentos com apoio alcançam a plataforma distante; entrar em x=4 acende o farol. |
Conte a rota inteira de V1: uma ação Minerar + três Colocar + quatro Mover = oito ações. O estado final tem uma ponte contínua de três células, inventário vazio, a pessoa exploradora na plataforma distante e o farol aceso. Este é o resultado esperado calculado a partir das regras autorais, não um resultado medido. A sequência de V0 mostra por que a mudança de um cubo importa: sem ele, não é possível pagar pela terceira colocação.
Quando uma versão for criada, confira a ordem dos eventos além do resultado final. A reserva é coletada antes da colocação; os três blocos são colocados antes de atravessar a ponte; e o farol acende somente quando a pessoa exploradora entra em x=4. Se uma recompensa visual aparecer antes, compare o gatilho com o contrato em vez de supor que a imagem ou o código define outra regra.
Compare uma implementação futura com observações reais
Uma lista de aceitação útil nomeia um estado inicial, uma ação e a mudança esperada. Neste mapa, confira primeiro se uma ação Minerar a partir de (0,1) coleta somente a reserva exposta em (0,0,y=1), mantém a pessoa exploradora no lugar e aumenta o inventário de dois para três. Em seguida, confira se um bloco não adjacente ou coberto não pode ser minerado, se Colocar x=1 até x=3 consome exatamente três blocos em sequência e se a terceira colocação de V0 é rejeitada quando o inventário chega a zero.
Depois, teste apoio e movimento separadamente. Cada novo bloco da ponte deve se conectar à plataforma próxima ou ao bloco anterior apoiado; um alvo sem apoio deve ser rejeitado sem alterar o inventário. A pessoa exploradora deve mover-se uma célula ortogonal por ação e somente sobre superfícies apoiadas. Quatro movimentos podem levá-la a x=4 depois que a ponte estiver completa, onde o farol acende. Reiniciar deve restaurar a reserva, o inventário, a posição e o farol apagado da versão escolhida.
Registre o que realmente observar: versão, ação, estado anterior, entrada, posição resultante, inventário, estado da célula-alvo e qualquer sinal de vitória. Se uma verificação não for executada, marque-a como não verificada. Um teste de aceitação escrito é um plano para obter evidências depois, não prova de que o comportamento já existe.
Leve o briefing voxel ao Workspace
Quando as regras estiverem delimitadas, o contrato curto pode ser encaminhado a um fluxo de criação de jogos. A página oficial atual do Criador de jogos grátis com IA lista um cartão inicial Voxel Sandbox Builder para colocar e quebrar blocos na construção de um mundo-ilha. Esse texto descreve um ponto de partida amplo; não confirma Mosslight Span, este conjunto de regras de ponte, o comportamento de apoio nem qualquer resultado dos prompts.
A página oficial do Criador de jogos grátis com IA descreve um fluxo geral: explicar um jogo em linguagem simples, revisar no navegador um primeiro resultado jogável em 2D ou 3D e depois refiná-lo com prompts de acompanhamento. Também recomenda conferir o modelo selecionado, o saldo de Koin disponível e o custo de geração exibido antes de enviar. Leve as regras delimitadas, inspecione o resultado que realmente for produzido e compare-o com as verificações acima. Não presuma que haverá implementação voxel específica nem travessia bem-sucedida antes de observar uma.
Se quiser começar a esboçar essa ideia, use o criador de jogos grátis com IA . Mantenha pequeno o primeiro pedido, inspecione o resultado gerado antes de iterar e confira o custo exibido antes de continuar. Esta é uma indicação geral do produto, não uma afirmação de que os prompts ou o mapa Mosslight Span foram executados. criador de jogos grátis com IA
Perguntas frequentes
O que um prompt de IA para um jogo de construção voxel deve incluir?
Indique a área editável, o ponto inicial, os blocos disponíveis, o alcance exato de mineração, as regras de colocação, os requisitos de apoio, o movimento, o objetivo e o comportamento de reinício. Depois, peça uma pequena tabela de mudanças de estado e verificações de aceitação. Esses detalhes tornam mais fácil inspecionar uma resposta futura do que um pedido amplo de sandbox voxel sem limites, mantendo flexível o tema visual.
Por que definir o alcance de mineração antes de escrever o prompt de implementação?
O alcance altera o orçamento de ações. Em Mosslight Span, o cubo reserva exposto fica adjacente por uma face à célula inicial e custa uma ação Minerar, sem movimento. Se o prompt não definir o alcance, a implementação pode exigir uma aproximação separada ou permitir mineração remota, mudando a rota e o número de ações. Trate este alcance exato como uma regra fictícia para testar depois.
Como o exemplo consegue blocos suficientes para atravessar?
V0 começa com dois blocos e precisa de três, então a terceira colocação é rejeitada quando o inventário chega a zero. V1 acrescenta um cubo reserva exposto que pode ser coletado da célula inicial numa única ação, sem movimento. Assim, três blocos completam a travessia e quatro movimentos com apoio alcançam o farol. A contagem de oito ações foi calculada manualmente, não veio de uma implementação.
Os prompts de Mosslight Span foram executados ou o jogo foi testado?
Não. Mosslight Span e suas regras são um exercício fictício original, e os modelos de prompt foram escritos para este artigo, mas não foram enviados a um gerador de jogos. As tabelas são cálculos manuais. Não há protótipo jogável, execução de prompt, teste de software, teste de jogo, resultado medido ou caso on-line a relatar.
O que devo fazer se uma implementação futura divergir da sequência?
Registre o primeiro estado diferente, incluindo versão, posição da pessoa exploradora, inventário, célula-alvo, ação e retorno resultante. Compare a observação com a verificação de aceitação correspondente, altere uma regra ou detalhe da implementação e repita a mesma sequência. Se não houver observação, use uma lista de verificação para coletar uma em vez de escrever um resultado presumido.
