Uma plataforma cooperativa precisa de uma condição compartilhada clara: o que cada jogador faz, quando as ações contam juntas e o que acontece se alguém errar. Defina esse ciclo curto antes de pedir uma fase longa. Twinspan Relay, abaixo, é um exemplo original de design em papel, não um protótipo existente nem um teste de jogo. A janela de pareamento de 1,5 segundo e a ponte de 4 segundos foram escolhidas para facilitar a inspeção das regras; não são valores de balanceamento medidos.
Defina o contrato cooperativo
Escreva o ciclo de ação como sequência de estados, não como um clima do tipo “faça os jogadores cooperarem”. Twinspan Relay dá aos dois mensageiros os mesmos movimentos de correr e saltar. Em cada retransmissor, Jogador A precisa tocar a plataforma azul e Jogador B a âmbar. A primeira aterrissagem correta inicia um cronômetro compartilhado. Se a segunda pessoa alcançar a plataforma correspondente a tempo, uma ponte curta aparece; ambas precisam atravessá-la antes que retraia. O checkpoint só avança quando as duas chegam.
Este contrato também define a falha. Plataforma errada, queda ou cronômetro expirado devolve ambos ao último checkpoint compartilhado e remove a ponte. Neste exemplo didático, ninguém fica esperando sozinho nem perde uma vida. Se uma pessoa chegar ao checkpoint enquanto a outra ainda atravessa, ele permanece inativo até ambas chegarem. Assim o progresso continua ligado ao estado da equipe.
| Ação do jogador | Mudança de estado compartilhado | O que acontece em seguida |
|---|---|---|
| Primeira pessoa aterrissa na plataforma que lhe foi atribuída | Inicia janela de pareamento de 1,5 segundo; registra qual plataforma está ocupada. | A outra pessoa ainda pode completar o par. |
| Segunda pessoa aterrissa na plataforma correspondente antes do fim do cronômetro | Marca o par como concluído e abre uma ponte atravessável por 4 segundos. | Ambos seguem até o mesmo checkpoint. |
| Ambos chegam ao checkpoint antes que a ponte feche | Avança o checkpoint compartilhado e limpa o cronômetro do retransmissor. | Apresenta o próximo par de plataformas. |
| Plataforma errada, queda, aterrissagem tardia ou tempo da ponte esgotado | Limpa o par ativo e devolve ambos ao checkpoint anterior. | Permite que a equipe tente novamente o mesmo retransmissor. |
A tabela torna o tempo e a recuperação visíveis para ambos. Antes de acrescentar cenário ou mecânicas, confirme que cada linha nomeia um gatilho, uma mudança de estado e um próximo estado. Se o único resultado descrito for “a ponte abre”, o prompt ainda precisa dizer quando fecha e como a equipe se recupera.
Prompt 1: escreva as regras compartilhadas
Use um prompt contratual curto para definir quantidade de jogadores, escopo da tela, objetivo conjunto e regra de recuperação. Peça que as suposições não resolvidas sejam listadas, em vez de permitir que o criador preencha lacunas silenciosamente.
Planeje uma plataforma cooperativa local para dois jogadores em uma tela compartilhada. Ambos têm os mesmos movimentos de correr e saltar; ninguém tem habilidade especial. O objetivo comum é atravessar três retransmissores com plataformas pareadas e chegar juntos à saída. Em cada retransmissor, Jogador A deve aterrissar na plataforma azul e Jogador B na âmbar. A primeira aterrissagem correta inicia uma janela de pareamento de 1,5 segundo. Se a segunda pessoa pousar na plataforma que lhe foi atribuída antes do prazo, forme uma ponte contínua e atravessável por 4 segundos. Ambos precisam chegar ao próximo checkpoint compartilhado antes de a ponte fechar. Plataforma errada, queda, janela de pareamento perdida ou tempo da ponte esgotado devolve os dois ao último checkpoint compartilhado e limpa o cronômetro e a ponte ativos. O checkpoint só avança quando ambos estão lá. A saída só abre depois que os dois alcançam suas plataformas finais correspondentes. Reiniciar devolve ambos ao checkpoint inicial e limpa todos os cronômetros. Retorne uma tabela de estado para as posições dos dois jogadores, plataformas atribuídas, cronômetro de pareamento, cronômetro da ponte, checkpoint compartilhado e estado da saída. Liste as suposições restantes. Mantenha o plano local e na mesma tela; não acrescente rede on-line, poderes assimétricos, vidas ou eventos aleatórios.
Este prompt é um modelo de design, não registro de execução. Ele pede ao criador que exponha os estados que você precisa inspecionar. Se o esquema de controles resultante atribuir botões diferentes aos dois controles, confira se ambos ainda têm as mesmas ações e se as instruções identificam as entradas de cada pessoa antes da primeira lacuna.
Escreva o prompt para uma única lacuna
Transforme o contrato em um encontro pequeno com início, interação e checkpoint reconhecível. Mantenha um par de plataformas e uma lacuna para reduzir as possíveis causas de um resultado confuso. Especifique o que os jogadores conseguem ver antes do salto, como a primeira aterrissagem inicia o cronômetro e como a ponte comunica o tempo restante.
No exemplo Twinspan, as duas plataformas brilham em cores diferentes e ficam em bordas opostas. A primeira aterrissagem na plataforma atribuída inicia a janela de 1,5 segundo; a segunda forma a ponte. O caminho temporário deve ser largo o bastante para parecer uma rota, enquanto o checkpoint além dele continua inativo até os dois mensageiros chegarem.
Prompt 2: solicite um retransmissor
Mantenha restrito o pedido da primeira versão. Peça um reinício e um indicador de estado visível junto aos movimentos, pois ambos fazem parte do ciclo cooperativo.
Crie um pequeno protótipo local de plataforma para dois jogadores a partir deste contrato de regras. Use uma tela compartilhada, dois controles e os mesmos movimentos de correr e saltar para ambos. Construa uma lacuna alcançável com uma borda inicial segura, uma plataforma azul de aterrissagem para Jogador A, uma âmbar para Jogador B e um checkpoint compartilhado do outro lado. Mostre os dois jogadores, as cores das plataformas atribuídas, a janela de pareamento de 1,5 segundo após a primeira aterrissagem correta e um indicador claro do cronômetro de 4 segundos da ponte depois que ambos ocuparem as plataformas correspondentes. A ponte deve ser uma superfície contínua e atravessável. Avance o checkpoint somente depois que ambos o tocarem antes de a ponte fechar. Se alguém cair, aterrissar na plataforma errada, chegar após a janela de pareamento ou perder o cronômetro da ponte, devolva ambos ao checkpoint anterior e limpe o estado ativo. Inclua reinício que devolva os dois ao início. Mantenha a câmera aberta o suficiente para mostrar ambos e toda a lacuna. Inclua uma tela compacta de controles. Não acrescente outras lacunas, itens coletáveis, ataques inimigos, poderes especiais, eventos aleatórios ou jogo on-line. Informe quais regras foram implementadas e quais ainda não foram verificadas; não presuma sucesso do protótipo apenas com base neste pedido.
Uma boa especificação não garante uma implementação. Se usá-la com uma ferramenta de criação, inspecione se o indicador de estado muda em cada gatilho e se a segunda pessoa ainda pode agir enquanto a primeira espera. Salve o prompt real e a versão do protótipo antes de comparar alterações posteriores.
Amplie a rota somente depois do primeiro retransmissor
Quando um protótipo real de uma lacuna passar pelas verificações com a mesma ordem e com ordens opostas de chegada, amplie a rota sem mudar a regra central. Reutilize as cores das plataformas, o cronômetro, a duração da ponte, o reinício e o comportamento do checkpoint. Varie uma característica geométrica por vez, como largura da lacuna ou altura da aterrissagem, para localizar mais facilmente uma falha posterior.
| Etapa | Manter fixo | Alterar somente quando |
|---|---|---|
| Encontro de uma lacuna | Dois jogadores, um par de plataformas atribuídas, reinício e checkpoint compartilhados | As duas ordens de chegada e um caso de falha correspondem ao contrato. |
| Rota de três retransmissores | Mesmo movimento, atribuição de plataformas, cronômetros e regra de recuperação | O próximo retransmissor só começa depois que o checkpoint conjunto avança. |
| Saída final | Alvo visível de cada pessoa e condição de conclusão compartilhada | O portão abre somente quando ambos alcançam as plataformas finais. |
| Etapa de cenário | Colisão, indicadores, enquadramento da câmera e lógica dos retransmissores | Uma mudança visual ou espacial pode ser comparada usando a mesma sequência. |
O prompt de ampliação deve preservar essas invariantes e pedir um resumo da rota que mostre o retransmissor ativo e o checkpoint. Não acrescente uma habilidade só porque uma lacuna posterior é mais difícil; primeiro decida se o desafio deve testar tempo, comunicação ou distância do movimento.
Prompt 3: acrescente mais dois retransmissores
Somente depois de inspecionar a versão de uma lacuna com os critérios de aceitação, amplie a mesma rota cooperativa local com mais dois retransmissores de plataformas pareadas e uma saída final. Preserve os mesmos movimentos, atribuição de plataforma azul/âmbar, janela de pareamento de 1,5 segundo, ponte de 4 segundos, regra de checkpoint conjunto, reinício ao errar ou cair e comportamento de reinício. Altere somente o espaçamento das lacunas, a altura da aterrissagem e o cenário entre retransmissores. Mantenha os dois jogadores visíveis quando surgir um indicador de pareamento. Mostre o checkpoint compartilhado atual, qual retransmissor está ativo e se cada pessoa está antes da lacuna, na plataforma atribuída, atravessando a ponte ou no checkpoint. O portão final só abre quando ambos alcançam suas plataformas de saída correspondentes. Retorne um mapa compacto da rota e uma lista de transições de estado. Não acrescente rede, novos poderes, inimigos ou regras aleatórias. Se a versão de uma lacuna ainda não foi inspecionada, identifique esta etapa como ampliação planejada e não a rotule como verificada.
Verifique o estado dos dois jogadores
Escreva sequências de ação repetíveis antes de decidir se um momento cooperativo está claro. Registre as posições iniciais de ambos, quem aterrissa primeiro, o intervalo entre aterrissagens, se a ponte abre e se o checkpoint compartilhado avança. Os valores abaixo são um cálculo em papel para Twinspan Relay, não observações de um protótipo jogável.
Na primeira rota, Jogador A aterrissa na plataforma azul em t=0; Jogador B aterrissa na âmbar em t=1,0. Um segundo está dentro da janela de pareamento de 1,5 segundo, então a ponte abre em t=1,0 e expira em t=5,0. Ambos chegam ao checkpoint em t=3,2, antes que ela feche, e o estado de exemplo avança. No segundo retransmissor, Jogador B chega em t=1,9, depois do fim da janela de pareamento em t=1,5. A ponte não se forma e ambos voltam ao checkpoint compartilhado anterior.
| Sequência de ações | Estado compartilhado esperado | O que verifica |
|---|---|---|
| A aterrissa em 0,0 s; B em 1,0 s; ambos chegam ao checkpoint em 3,2 s | Par concluído, ponte ativa de 1,0 a 5,0 s, checkpoint compartilhado avança | Plataformas correspondentes, início do cronômetro, duração da ponte e chegada conjunta. |
| A aterrissa em 0,0 s; B em 1,9 s | Cronômetro do par expira em 1,5 s; nenhuma ponte se forma; ambos reiniciam. | Chegada tardia não abre ponte nem deixa uma pessoa avançada. |
| Qualquer pessoa aterrissa na cor errada | Retransmissor falha e ambos voltam ao último checkpoint compartilhado. | Atribuição das plataformas é legível e aplicada com consistência. |
| As duas plataformas correspondem, mas uma pessoa cai antes do checkpoint | A ponte desaparece; ninguém mantém progresso individual. | A recuperação da falha continua compartilhada. |
| Somente uma pessoa chega ao checkpoint antes que a ponte feche | Checkpoint continua inativo; ambas reiniciam quando o tempo acaba. | Uma pessoa não consegue avançar a equipe sozinha. |
| Ambos alcançam as plataformas finais pareadas | Saída abre e a rota compartilhada fica completa. | A condição final exige ambos os jogadores. |
| Reiniciar durante qualquer retransmissor ativo | Ambos voltam ao início; cronômetros e pontes são limpos. | Reinício remove estado compartilhado antigo. |
Esses estados esperados são critérios de aceitação para executar mais tarde em um protótipo real. Não são evidências de teste. Um registro de observações útil inclui versão das regras, os dois controles, ações, tempos, posições dos jogadores, estado do retransmissor, checkpoint e resultado. Se o resultado divergir, mantenha a sequência igual durante o diagnóstico.
Corrija a falha sem alterar o ciclo inteiro
Quando um par falhar, localize o primeiro estado divergente da sequência pretendida. Se alguém não viu a atribuição da plataforma, melhore o indicador ou o enquadramento da câmera antes de alterar o cronômetro. Se a aterrissagem correta é registrada, mas a ponte não abre, inspecione a correspondência das plataformas e o início do cronômetro. Se uma pessoa avança sozinha, corrija a condição do checkpoint antes de acrescentar conteúdo à fase.
Para uma revisão real, altere uma causa por vez e repita a mesma sequência. Um ajuste de câmera não deve também mudar a janela de pareamento; uma plataforma mais brilhante não deve alterar a regra de reinício. Mantenha notas separadas sobre o que observou, o que acredita ter causado o problema e o que mudou. Sem protótipo ou observação de jogador, apresente uma correção proposta como ideia de design, não como melhoria demonstrada.
Prompt 4: peça uma revisão focada
Com base na sequência real de ações e no registro de estado que forneço, identifique o primeiro ponto em que o retransmissor cooperativo diverge do contrato escrito. Separe uma incompatibilidade de implementação de um problema de visibilidade, câmera ou controle. Proponha uma pequena alteração, diga o que deve permanecer igual e escreva a mesma sequência de ações como verificação repetida. Não invente comentários de jogadores, resultados de teste ou uma revisão bem-sucedida. Se não houver registro de observação, retorne uma lista de verificação de causas prováveis sem alegar que alguma ocorreu. Preserve checkpoint compartilhado, atribuição das plataformas, cronômetros e regras de reinício, a menos que a evidência indique especificamente qual deles deve mudar.
Use um cenário curto de multijogador como especificação inicial
A página SEELE Multiplayer Game Maker descreve o planejamento de quantidade de jogadores, papéis, objetivos compartilhados, regras de interação e um cenário curto. Também diz que o jogo on-line ainda precisa de implementação específica do projeto, rede, sincronização, hospedagem e testes. Essa orientação ajuda a estruturar um conceito cooperativo, mas não verifica os controles locais de Twinspan Relay nem faz as regras exatas de tempo funcionarem. Inspecione as mudanças de estado dos dois jogadores em qualquer resultado real antes de ampliar o modo.
Comece escrevendo o objetivo compartilhado e uma sequência de aceitação. Quando quiser estruturar esse conceito curto de multijogador, use o Multiplayer game maker. Trate a página como ponto de partida para o planejamento; confirme no projeto que você realmente criar o comportamento necessário. Crie jogos com IA grátis
Perguntas frequentes
Quantos jogadores uma primeira plataforma cooperativa deve usar?
Comece com dois jogadores em uma única tela compartilhada. Isso basta para conferir se ambos têm uma ação útil e se o movimento de uma pessoa altera um resultado conjunto. Acrescente mais jogadores somente depois que atribuição das plataformas, cronômetro, checkpoint e regras de chegada continuarem legíveis ao repetir com a primeira dupla.
Jogadores cooperativos precisam de habilidades diferentes?
Não. Dois jogadores podem se coordenar por tempo, posicionamento ou objetivos compartilhados usando o mesmo conjunto de movimentos. Poderes distintos adicionam outro sistema a explicar; introduza-os somente se o ciclo central já funcionar e a nova habilidade criar uma escolha que nenhuma pessoa consiga resolver sozinha.
O que acontece se apenas uma pessoa chegar a um checkpoint?
No design Twinspan, o checkpoint não avança até que ambos cheguem. Se a ponte expirar antes disso, os dois retornam ao último checkpoint compartilhado. A regra impede que uma chegada individual deixe a outra pessoa isolada ou crie um estado do qual a equipe não possa se recuperar.
Um criador de jogos com IA pode garantir cooperativo on-line?
Nenhum prompt sozinho pode provar que rede, sincronização, hospedagem ou funcionamento em vários dispositivos estão prontos. Uma página de planejamento pode ajudar a definir quantidade de jogadores e regras de interação, mas um projeto real ainda precisa de implementação e testes nos dispositivos e nas condições de rede pretendidos. Mantenha jogo local na mesma tela separado de afirmações sobre jogo on-line.
Os tempos de sincronização e da ponte foram testados?
Não. A janela de sincronização de 1,5 segundo e a duração de 4 segundos da ponte são valores ilustrativos escolhidos para o exemplo em papel. Eles mostram como explicitar o tempo em um prompt. Use observações de jogadores em um protótipo real para decidir se deve alterá-los e registre cada revisão separadamente.
