Quando um quebra-cabeça de palavras muda de regra a cada rodada, um prompt de IA precisa definir mais do que um tema. Especifique as peças físicas do suporte, a condição exata para um palpite válido, as palavras aceitas, o custo do erro e o que faz a pessoa avançar. Depois, acrescente uma regra por vez e compare o estado resultante com uma verificação pequena e explícita.
Este guia usa Mosslight Letter Trial, um exercício fictício original de design. Os modelos de prompt não foram enviados a um gerador de jogos, e não há implementação nem teste de jogo. As listas de palavras e os resultados abaixo formam um contrato autoral para o leitor adaptar e verificar no próprio protótipo.
Transforme a mudança de regra num caso de teste
Comece com uma folha de regras que alguém possa seguir sem adivinhar o significado de “formar uma palavra”. Cada rodada tem um suporte, uma restrição, uma lista fixa de palavras aceitas e uma transição. As listas são intencionalmente pequenas: tornam o exercício determinístico sem afirmar que representam um dicionário completo.
| Rodada | Suporte físico | Restrição | Palavras aceitas |
|---|---|---|---|
| 1 | S, T, O, N, E | Use pelo menos quatro peças | STONE, TONE, NOTE, ONES, SENT |
| 2 | A, C, E, R, T | Use as cinco peças e inclua R | CARET, CATER, CRATE, REACT, TRACE |
| 3 | P, L, A, N, E, T | Use pelo menos quatro peças e não use E | PLAN, PANT, PLANT |
Leia as linhas como contrato, não como três desafios de dicionário. O palpite deve usar peças físicas do suporte atual, e cada peça pode ser selecionada somente uma vez. Depois, verifique o tamanho, a regra de inclusão ou exclusão da rodada e, por fim, a lista permitida específica daquela rodada. Pare na primeira falha para que a pessoa receba um motivo acionável, não várias mensagens concorrentes.
Por exemplo, TONE usa quatro peças disponíveis e está na lista da rodada 1, portanto as regras propostas aceitam a palavra. STENO usa cinco peças do suporte e satisfaz o tamanho mínimo, mas não aparece na lista; chega à verificação da lista permitida e falha ali. São resultados esperados do contrato escrito, não observações de um jogo em execução.
Peça o primeiro suporte e o ciclo de entrada
Peça uma rodada antes de solicitar progressão. Isso isola a interação básica: selecionar uma peça uma vez, removê-la ao selecioná-la de novo, limpar a linha sem custo, enviar o palpite e continuar editando após um erro ou avançar com uma palavra válida. O primeiro prompt pode servir como briefing inicial:
Crie um pequeno protótipo fictício de jogo de formar palavras chamado Mosslight Letter Trial. Mostre um suporte com as peças físicas S, T, O, N, E; uma regra ativa que exija pelo menos quatro peças por palavra enviada; uma linha ordenada para o palpite; os botões Enviar e Limpar; dois marcadores de tentativa; e Reiniciar sempre visível. Cada peça física pode ser selecionada uma vez, desmarcada com outro clique e a tentativa inteira pode ser limpa sem gastar uma chance. Aceite somente STONE, TONE, NOTE, ONES ou SENT nesta rodada única. Um palpite válido mostra um ponto de controle temporário “Rodada concluída”, não a vitória final do jogo. Mantenha o suporte após uma tentativa inválida, consuma uma chance e permita corrigir o palpite. Ainda não acrescente dicionário, pontuação, cronômetro, letras aleatórias ou outras rodadas.
Agora inspecione no papel o contrato de entrada. Selecionar T, O, N e E nessa ordem forma TONE; S permanece no suporte, sem uso. Selecionar as mesmas peças físicas em outra ordem formaria outra palavra, então a palavra final precisa ser conferida com a lista permitida, em vez de aceita somente porque as letras vieram do suporte. Um segundo clique na mesma peça nunca cria outra cópia.
Anote os estados esperados antes da implementação: uma palavra válida da lista avança; um envio inválido consome uma das duas tentativas, mas mantém o palpite editável; Limpar esvazia a linha sem alterar os marcadores; e o segundo envio inválido encerra a partida. Reiniciar está disponível em qualquer estado e volta à rodada 1, com palpite vazio e duas tentativas. Assim, um pedido visual vira uma sequência verificável de mudanças de estado.
Acrescente restrições sem mudar a entrada principal
Quando o contrato do primeiro suporte estiver estável, peça as rodadas seguintes declarando que os controles e palavras aceitas devem permanecer iguais. A rodada 2 muda tanto o tamanho mínimo como a regra de inclusão de uma letra. A rodada 3, por sua vez, proíbe uma letra. A mudança fica mais fácil de inspecionar quando o prompt declara a precedência dessas verificações e fornece um caso que falha em cada limite.
Mantenha exatamente iguais o suporte, os controles e as palavras aceitas da primeira rodada. Amplie o jogo para três rodadas. A rodada 2 usa o suporte A C E R T, exige as cinco peças e a letra R, e aceita somente CARET, CATER, CRATE, REACT, TRACE. A rodada 3 usa P L A N E T, exige pelo menos quatro peças, proíbe E e aceita somente PLAN, PANT, PLANT. Uma palavra válida avança imediatamente e substitui o suporte e a regra; uma palavra válida em cada rodada completa a partida. O estado de vitória mostra exatamente as três palavras aceitas naquela partida, sem um quarto suporte. Não acrescente API de dicionário, rodadas extras, pontuação nem peças aleatórias.
Use os exemplos para ver por que a ordem importa. Na rodada 2, CATE é menor que as cinco peças exigidas, então a primeira mensagem deve ser “Use as cinco peças”; não deve pular para a falta de R nem para a lista de palavras. CARET satisfaz o tamanho, a inclusão de R e aparece na lista. Na rodada 3, PLAN satisfaz o tamanho mínimo, não contém E e está na lista. PLANET usa seis peças do suporte, mas inclui o E proibido, então essa regra deve ser reportada antes de verificar se a palavra está na lista.
As listas fixas de palavras são restrições de design, não uma afirmação sobre um dicionário de inglês. Se um criador quiser depois um vocabulário aberto, deverá escolher e testar separadamente uma fonte de dicionário, tratamento de maiúsculas, flexões e regras de letras repetidas. Deixar essa decisão fora do primeiro exercício impede que um serviço oculto ou vocabulário sem limites altere o significado de “válida”.
Confira entradas inválidas e o estado da rodada
Use um terceiro prompt para deixar explícitos o comportamento de erro e de reinício. Após o primeiro erro, a pessoa deve conseguir corrigir o palpite; o segundo erro encerra a partida. Uma palavra válida avança imediatamente à próxima rodada e reinicia os dois marcadores de tentativa daquela rodada. O estado de vitória contém, em ordem, as palavras aceitas naquela partida e não apresenta um novo suporte.
Mantenha o contrato do jogo inalterado. Cada rodada permite dois envios. Valide nesta ordem exata: pertencimento das peças e ausência de repetição, tamanho, regra de inclusão/exclusão da letra e, por fim, lista fixa de palavras aceitas. Mostre somente o primeiro motivo de falha. Um palpite inválido consome uma tentativa e mantém as peças selecionadas na linha para que a pessoa possa editá-las; Limpar esvazia o palpite sem consumir uma tentativa. O segundo envio inválido encerra a partida com derrota. Reiniciar permanece visível em todos os estados e volta à rodada 1, suporte S T O N E, palpite vazio, duas tentativas e nenhum resultado. Confirme que STENO chega ao erro de lista permitida, CATE chega ao erro de cinco peças antes da condição do R ausente e PLANET chega ao erro do E proibido antes da lista; não afirme que essas verificações passaram até executá-las.
| Verificação no papel | Primeira condição que falha | Mudança de estado esperada |
|---|---|---|
| Rodada 1: enviar STENO | Lista de palavras aceitas | Gasta uma tentativa; STENO continua editável |
| Rodada 2: enviar CATE | Tamanho: são exigidas cinco peças | Gasta uma tentativa antes de conferir o R ausente |
| Rodada 3: enviar PLANET | Letra E proibida | Gasta uma tentativa antes de conferir a lista |
Este prompt pede o retorno esperado, não apenas uma tela de vitória. Numa partida nova da rodada 1, STENO deve falhar na lista duas vezes; o primeiro erro mantém o palpite editável, e o segundo mostra derrota. Uma nova partida pode enviar STONE para chegar à rodada 2, onde CATE deve exibir a mensagem de tamanho. Limpar deve remover CATE sem gastar outra tentativa; CARET deve avançar. Na rodada 3, PLANET deve exibir a mensagem do E proibido, e PLAN deve completar a partida. A tabela registra a primeira falha de três entradas representativas, permitindo identificar o ramo de validação que precisa de correção sem tratar o rastro no papel como resultado de teste.
A sequência de sucesso é intencionalmente curta: a rodada 1 aceita STONE, a 2 aceita CARET e a 3 aceita PANT. Cada palavra satisfaz as restrições escritas e a lista da rodada. A imagem é uma ilustração conceitual original desse estado definido, não captura nem evidência de que um jogo foi criado.
Corrija uma regra de validação por vez
Se um protótipo futuro aceitar PLANET na rodada 3, comece registrando o que ele realmente exibiu e qual versão das regras usou. Depois, peça uma correção delimitada: valide a condição do E proibido antes de conferir a lista, mantenha o mesmo suporte e conjunto de palavras e repita PLANET seguido de PLAN. Compare as novas mensagens com o contrato. Não conclua que a correção funcionou até executar e observar a mesma sequência.
A mesma disciplina vale para comportamentos pouco claros. Se clicar duas vezes numa peça duplicá-la em vez de desmarcá-la, descreva a identidade da peça física, o palpite atual, a ação e a linha esperada. Se Reiniciar mantiver um resultado antigo, especifique o estado que precisa limpar. Alterar uma regra por vez mantém uma comparação futura interpretável; mudar léxico, controles e progressão juntos dificulta localizar a causa da divergência.
Leve o briefing a um espaço de criação de jogos
A página de Criador de jogos grátis com IA da SEELE descreve um fluxo geral para expressar uma ideia em linguagem simples, revisar um resultado jogável em 2D ou 3D e iterar no Workspace. Essa informação oferece um lugar para experimentar um briefing futuro; não verifica Mosslight, as listas de palavras nem qualquer prompt acima. Antes de começar, confira as opções atuais do Workspace e os termos de conta ou geração exibidos; depois, compare qualquer resultado com as verificações explícitas, sem presumir que o prompt as produziu.
Quando quiser transformar suas regras delimitadas num ponto de partida, abra o criador de jogos grátis com IA . O fluxo publicado descreve prompts em linguagem simples, um primeiro resultado jogável em 2D ou 3D que pode ser testado no navegador e prompts posteriores para refinamento. Antes de enviar uma geração, confira o modelo selecionado, o saldo de Koin disponível e o custo exibido. Inclua no briefing o suporte, a regra, as palavras aceitas, a ordem dos erros e o comportamento de reinício; depois, inspecione o resultado real. Este artigo não promete nenhum resultado específico para o jogo. criador de jogos grátis com IA
Perguntas frequentes
O que um prompt de IA deve incluir para uma regra de palavras que muda?
Nomeie o suporte, as condições exatas de tamanho e letras, o conjunto de palavras aceitas, a ordem dos erros e a transição após um palpite válido ou inválido. Acrescente uma regra variável por etapa e inclua um exemplo que deve passar e outro que deve falhar. Isso permite inspecionar comportamentos específicos num resultado futuro sem presumir um dicionário amplo.
Devo conectar uma API de dicionário desde o início?
Não neste exercício delimitado. Uma lista pequena de palavras permitidas torna explícito cada resultado esperado e evita uma dependência não escolhida. Se depois usar um dicionário aberto, decida qual fonte e idioma ele cobre, como trata plurais ou flexões e como lida com letras repetidas; então teste essas regras separadamente. As listas de Mosslight são fictícias e intencionalmente incompletas.
O que acontece depois de um palpite inválido?
Pelo contrato proposto, o primeiro envio inválido consome uma das duas tentativas, mas mantém as peças selecionadas na linha para que a pessoa possa editá-las. Limpar esvazia a linha sem gastar tentativa. O segundo envio inválido encerra a partida. São regras desejadas para um protótipo futuro, não comportamento observado num jogo funcional.
Como conferir que a mesma peça não foi usada duas vezes?
Acompanhe a instância física da peça selecionada, não somente a letra impressa. A mesma peça deve ser desmarcada quando clicada novamente, e a linha de palpite não pode conter uma referência duplicada àquela instância. Uma verificação futura útil é selecionar uma peça, clicar nela outra vez e confirmar que ela desaparece sem alterar o suporte nem o número de tentativas.
Mosslight Letter Trial é um jogo gerado ou testado?
Não. Mosslight é um exercício original e fictício de design, e seus modelos de prompt não foram enviados a um criador de jogos. As tabelas e a sequência de sucesso foram resolvidas manualmente a partir das regras escritas. Não há jogo jogável, execução de prompt, teste de software, teste de jogo, resultado medido, história de cliente ou caso on-line a relatar.
