Criar um jogo cooperativo assimétrico com prompts de IA

Um jogo cooperativo assimétrico funciona quando os jogadores têm informações diferentes e cada um dispõe de uma ação que o outro não pode executar. Comece com um objetivo compartilhado, defina o que cada papel consegue ver e alterar e torne o resultado visível para ambos. Depois peça um encontro pequeno e uma forma de inspecionar as regras antes de ampliá-lo.

Os prompts abaixo usam Lantern Relay, um conceito original de resgate em caverna para dois participantes locais que se comunicam por voz. Ele não foi produzido nem testado. O Guardião consulta o mapa da rota e muda uma comporta remota; o Explorador gira um espelho físico e informa o trecho do feixe que consegue ver. São premissas de design para o exemplo, não alegações sobre recursos do SEELE.

Comece pela dependência, não pelas classes de personagem

Antes de nomear os papéis, complete uma frase: “Só alcançamos [objetivo compartilhado] depois que um jogador usa [informação privada] para executar [ação] e o outro usa [informação diferente] para executar [outra ação]”. Se qualquer ação puder desaparecer sem mudar a solução, os papéis têm nomes diferentes, mas ainda não dependem um do outro.

Para criar um prompt de jogo cooperativo assimétrico, escreva primeiro o objetivo comum e depois defina uma fronteira de informação e uma ação exclusiva para cada papel. Inclua o momento em que um jogador precisa do relato do outro e o feedback que confirma o que mudou. Assim, “habilidades diferentes” ficam ligadas a um ciclo real de puzzle, em vez de serem apenas duas descrições de personagem sem relação.

Um exemplo documentado de informação dividida aparece no guia oficial de jogo remoto de Keep Talking and Nobody Explodes: o Desarmador vê a bomba, mas não o manual; os Especialistas usam o manual sem ver a bomba. Lantern Relay tem outro cenário e outras regras. A pergunta útil de design é apenas qual informação precisa passar entre os papéis antes que uma ação possa dar certo. Criador de jogos com IA grátis

Dê a cada papel uma tarefa necessária

Em Lantern Relay, o Guardião conhece a rota fixa da caverna e as opções da comporta remota, mas não vê qual trecho do feixe está iluminado naquele momento. O Explorador vê o feixe atual e um espelho físico, mas não vê o mapa da rota nem controla a comporta. O Explorador ajusta o espelho e informa o trecho observado. O Guardião usa o relato para escolher a posição correspondente da comporta. Só então o feixe consegue chegar ao portão de resgate.

Esse é um contrato entre papéis: cada lado tem informação privada, uma ação ligada a essa informação e um motivo para se comunicar. Antes de escrever um prompt completo, preencha a tabela com substantivos e verbos que o jogador possa apontar. “O Batedor é rápido” não basta; “o Batedor vê a placa de pressão e pode mantê-la abaixada” dá ao outro papel uma dependência específica.

A tabela também revela uma falha comum: se o mapa do Guardião já mostra o trecho atual do feixe, o relato do Explorador não traz informação nova. Se o Explorador alcançar o objetivo ajustando apenas o espelho, o Guardião é apenas um observador. Feche essas lacunas nas regras antes de acrescentar diálogo, salas ou progressão de personagem.

Use três prompts para passar das regras a uma sala

Mantenha as solicitações separadas para que cada resposta tenha uma função. Primeiro defina o contrato entre os papéis. Depois peça uma interação jogável compacta ou, se a ferramenta escolhida não oferecer os controles necessários, um documento estruturado de design. Por fim, peça um plano de avaliação que aguarde suas observações reais. Os prompts de IA a seguir são modelos: substitua os campos entre colchetes e mantenha em mente que o exemplo não foi testado.

Prompt 1: definir o contrato entre os papéis

Crie um conceito de jogo cooperativo para exatamente [número de jogadores].
Objetivo compartilhado: [uma frase que descreva o que o grupo precisa alcançar].
Premissa de comunicação: [como os jogadores trocam informações].

Para cada papel, informe:
- quais informações só esse papel pode observar;
- qual ação só esse papel pode executar;
- que estado muda depois da ação;
- qual sinal o papel pode comunicar aos outros.

Mostre a dependência em ordem: informação, relato, decisão do parceiro, ação e feedback compartilhado. Descreva um encontro curto com estado inicial, ações válidas, condição de sucesso, condição de falha e estado de reinício. Depois retire cada papel, um de cada vez, e explique se o encontro ainda pode ser resolvido. Se algum papel puder ser removido sem alterar a solução, revise a dependência. Ainda não acrescente salas, progressão ou sistemas extras.

Entregue uma tabela de papéis, uma tabela de transições de estado e as regras que ainda precisam de uma decisão de design. Não afirme que o jogo foi produzido ou testado.

Este primeiro pedido solicita um contrato de design, não um mundo pronto e polido. Verifique se cada papel tem algo para perceber, algo para fazer e um relato que afete a próxima decisão do parceiro. Se a resposta inventar um detalhe de implementação que você ainda não escolheu, deixe-o como decisão em aberto em vez de tratá-lo como comportamento definido.

Prompt 2: delimitar a primeira sala

Crie o design de uma sala de puzzle de resgate em caverna chamada Lantern Relay. Este é um conceito didático fictício para dois participantes locais que se comunicam por voz. O prompt não foi executado nem testado.

Objetivo compartilhado: conduzir o farol até o portão de resgate.
Visão e ação do Guardião: o Guardião vê um mapa fixo da rota e as opções da comporta remota, mas não vê a cena atual da caverna nem o trecho atual do feixe. Somente o Guardião pode mudar uma posição da comporta remota.
Visão e ação do Explorador: o Explorador vê o feixe atual e um espelho físico, mas não vê o mapa da rota nem o estado da comporta remota. Somente o Explorador pode girar o espelho e relatar qual trecho está iluminado.
O mapa da rota mostra caminhos possíveis; o relato do Explorador identifica o trecho atual do feixe. O Guardião precisa do relato para escolher a comporta correspondente. O espelho e a comporta precisam estar ajustados corretamente antes que o feixe alcance o portão de resgate.

Mostre o estado inicial, cada ação permitida, o feedback para uma ação inválida, o estado de sucesso, um estado de falha ou tempo esgotado e um reinício para o início. Mantenha um espelho físico e uma comporta remota. Não adicione combate, inventário, progressão de campanha, rede online, software de chat por voz ou uma segunda sala. Nas perspectivas propostas, mantenha separadas as informações de cada papel.

Se a ferramenta de criação disponível não puder representar duas entradas locais ou perspectivas separadas, entregue uma especificação estruturada da mecânica e da interface em vez de apresentá-la como jogável. Sinalize qualquer mecânica que ainda exija uma decisão. Forneça uma tabela de estados e uma breve lista de aceitação.

Depois da resposta, leia a tabela de estados antes de julgar a direção de arte. Pergunte se uma escolha errada de comporta produz um resultado visível e recuperável; se o Explorador consegue relatar o estado do feixe sem ver o mapa do Guardião; e se o Guardião consegue usar o relato para escolher uma ação seguinte relevante. Se a ferramenta ou o ambiente não expressar essas restrições, o documento de design ainda é útil, mas não demonstra que exista uma experiência cooperativa funcional.

Prompt 3: avaliar observações que você realmente coletou

Revise as observações que forneço para este design cooperativo de uma sala.
Não invente ações dos jogadores, anotações de teste ou resultados bem-sucedidos.

Contrato de design: [cole a tabela de papéis e o estado inicial aprovados].
Sequência observada: [cole somente as ações e respostas registradas].
Resultado esperado: [descreva o resultado definido pelas regras].
Resultado real: [descreva o que os jogadores ou o build mostraram].
Primeiro ponto de confusão: [cite ou descreva a primeira ambiguidade].

Compare a sequência observada com o contrato, passo a passo. Identifique a primeira divergência, explique a regra ou o sinal envolvido e sugira uma revisão de escopo limitado. Preserve a sala, os papéis e todas as regras não relacionadas. Se a observação estiver ausente ou ambígua, pergunte o que deve ser registrado na próxima vez. Não diga que o design passou a menos que a observação fornecida sustente isso.
Entregue a linha alterada, o que deve ficar observável e uma verificação para uma sessão futura.

As entradas importam mais do que a palavra “avaliar”. Sem uma sequência observada, o modelo só pode sugerir uma verificação de design, não relatar como os jogadores se comportaram. Quando coletar observações, inclua o resultado pretendido e o primeiro momento de confusão; assim a revisão pode corrigir a menor divergência em vez de reescrever os dois papéis.

Verifique se os dois jogadores são importantes

Uma tabela de papéis descreve a intenção, mas a sala ainda precisa de verificações observáveis. Percorra o encontro desde o estado inicial e pergunte o que cada jogador sabe em cada etapa. Os itens abaixo são um método proposto de revisão para seu design, não resultados de um teste de Lantern Relay.

Faça uma mudança de cada vez. Se o relato for ambíguo, esclareça o sinal antes de adicionar um sistema de dicas. Se um papel ficar ocioso, reduza o intervalo entre suas observações e ações. Se o objetivo for difícil de entender, melhore o feedback do feixe ou do portão antes de incluir outro puzzle. Uma revisão pequena preserva as partes que você ainda quer avaliar.

Revise a partir de uma observação real

Quando puder observar jogadores em um design, anote quatro coisas: ação, resultado esperado, resultado real e o primeiro momento em que alguém hesitou ou entendeu errado. Evite conclusões como “o Guardião foi entediante” sem apontar um momento para inspecionar. Uma nota como “o Guardião podia escolher qualquer comporta antes de o Explorador relatar o feixe” identifica uma dependência específica que pode ser alterada e verificada novamente.

Mantenha o restante da sala fixo ao revisar essa regra. Depois repita a mesma situação inicial e veja se o relato muda a decisão do parceiro. Isso não prova que o design esteja equilibrado ou seja amplamente utilizável; oferece uma próxima pergunta rastreável. Até ter observações reais, descreva o problema como risco a verificar, não como resultado de um teste.

Leve um briefing focado a um fluxo de criação

Depois que o contrato no papel estiver coerente, você pode experimentar a ideia em um fluxo de criação de jogos e inspecionar o resultado. A página atual do Criador de jogos com IA grátis da SEELE descreve pedidos em linguagem natural, revisão de resultados jogáveis em 2D ou 3D e iteração no Workspace. Também orienta a conferir os custos de geração exibidos e as opções da conta. Essas informações gerais não verificam cooperativo local, duas entradas locais simultâneas, comunicação por voz ou esta sala fictícia. Criador de jogos com IA grátis

Inclua no pedido o objetivo comum, a primeira ação de cada jogador, os estados da cena e o feedback. Depois verifique se o resultado realmente representa cada controle e papel antes de tratá-lo como protótipo cooperativo. Se o fluxo disponível não puder expressar duas perspectivas ou entradas, use a resposta como ponto de partida de design e planeje a implementação adequada separadamente. Para o puzzle, a página do Criador de jogos de puzzle com IA ajuda a formular uma regra, uma pista visível, uma ação de resolução e um resultado; ela não comprova suporte multijogador. Criador de jogos com IA grátis

Um bom primeiro resultado é o menor que você consegue inspecionar em relação ao contrato. Mantenha a sala apenas se cada papel contribuir com informação ou ação, escolhas inválidas se explicarem e o estado de sucesso surgir claramente da contribuição dos dois. Se esses critérios não forem atendidos, revise uma regra ou solicite uma especificação de design antes de ampliar para uma segunda sala.