Para criar um jogo de inspeção original inspirado em Papers, Please, comece com dois registros e uma lista de verificação visível. Na fictícia Biblioteca de Padrões de Intake, um funcionário compara o rótulo de uma bandeja decorativa com um cartão de solicitação. Uma bandeja corresponde ao motivo e à baia de prateleira solicitados. Ela não tem um adesivo Violet. Se o funcionário deve guardá-la depende da lista de verificação desta rodada.
Deixe o jogador examinar as evidências e, em seguida, tomar uma decisão. Uma repetição com os mesmos documentos e um requisito alterado mostra se o jogo verifica a regra atual.
Transforme a comparação de documentos no seu próprio quebra-cabeça de inspeção
Em Papers, Please, um inspetor de imigração fictício toma decisões usando documentos de viajantes e ferramentas de inspeção. Lucas Pope descreve essa premissa no kit de imprensa oficial e em seu catálogo de desenvolvedor.
Use a ideia ampla de verificar evidências contra uma regra. Dê à sua versão seu próprio cenário e consequências. A biblioteca de padrões classifica bandejas de impressão decorativas. A solicitação e o rótulo listam cada um um Motivo e uma Baia. O rótulo também pode ter um adesivo Violet.
Separe a inspeção de uma decisão comprometida
Inspecionar destaca os campos correspondentes e mostra seus valores brutos. Não custa um turno. A lista de verificação pergunta se Motivo e Baia correspondem. Na versão revisada, também exige o adesivo. Mantenha a lista de verificação ativa visível enquanto o jogador decide.
Guardar envia a bandeja para a baia em sua solicitação. Devolver exige um motivo de uma lista fixa. Registre o que o jogador escolheu, o que a lista de verificação esperava e se a decisão e o motivo estavam corretos. Dê feedback para a bandeja resolvida e limpe os destaques temporários de inspeção.
| Entrada | Efeito |
|---|---|
| Inspecionar | Mostrar os valores comparáveis sem se comprometer. |
| Guardar | Comprometer-se com a baia solicitada. Pontuar como correto quando todas as verificações obrigatórias passam. |
| Devolver com um motivo listado | Comprometer a devolução. Pontuar como correto quando esse motivo é um requisito falho real. |
| Devolver sem um motivo listado, ou um comando para outro caso | Rejeitar sem avançar ou alterar o livro-razão. |
Os três motivos de Devolver são Desconformidade de Motivo, Desconformidade de Baia e Adesivo Ausente. Se mais de uma verificação obrigatória falhar, aceite qualquer motivo que se aplique. Um motivo listado ainda pode estar errado para a bandeja. Um motivo errado registra um erro e avança para o próximo caso.
Refaça as três bandejas contra a mesma lista de verificação
Use os seguintes casos em ordem. Após o terceiro comprometimento, mostre a pontuação e o feedback específico do caso. Apenas Reiniciar é aceito após a conclusão.
| Caso | Solicitação | Rótulo da bandeja | Decisão de base | Adesivo obrigatório |
|---|---|---|---|---|
| A | Arc, Norte | Arc, Norte, sem adesivo | Guardar. | Devolver com Adesivo Ausente. |
| B | Dot, Sul | Dot, Norte, Violet | Devolver com Desconformidade de Baia. | Devolver com Desconformidade de Baia. |
| C | Wave, Norte | Wave, Norte, Violet | Guardar. | Guardar. |
Na base, Guardar A, Devolver B com Desconformidade de Baia e Guardar C dá três decisões corretas. Tente devolver B por Desconformidade de Motivo. Ambos os registros mostram Dot, então o motivo está errado, mesmo que devolver a bandeja seja o destino certo. O livro-razão deve registrar o erro específico do motivo.
Dê à IA uma pequena lista de verificação de regras e uma repetição
Peça pelos dois cartões, a lista de verificação ativa e um livro-razão curto. Dê ao protótipo ambas as decisões esperadas e exemplos de ações que devem deixar a bandeja atual sozinha.
Construa um quebra-cabeça de inspeção original de Intake da Biblioteca de Padrões.
Mostre um par de Solicitação e Rótulo da Bandeja de cada vez.
A: solicitação Arc Norte; rótulo Arc Norte, sem adesivo.
B: solicitação Dot Sul; rótulo Dot Norte, Violet.
C: solicitação Wave Norte; rótulo Wave Norte, Violet.
Corresponda Motivo e Baia. Suporte uma configuração para se Violet
é obrigatório. Mantenha a lista de verificação selecionada fixa durante uma rodada.
Inspecionar mostra ambos os valores e não faz nenhum comprometimento.
Guardar envia a bandeja para sua baia solicitada. Devolver exige um
motivo listado: Desconformidade de Motivo, Desconformidade de Baia ou Adesivo Ausente.
Aceite uma Devolver apenas como correta se o motivo for uma verificação falha.
Motivos ausentes ou não listados e comandos de caso obsoletos não avançam.
Cada comprometimento válido registra a decisão esperada, a decisão e o motivo
enviados, e a correção. Mostre feedback específico.
Após os três, mostre a pontuação e pare. Reiniciar começa no caso A,
limpa o livro-razão e os destaques, e usa a lista de verificação selecionada.Inspecione duas vezes e confirme que a pontuação e o caso não avançam. Envie Devolver sem um motivo. Em seguida, selecione um motivo listado, mas incorreto, e confirme que ele avança com um erro. Reinicie e verifique se o livro-razão antigo e os destaques do caso foram removidos.
Torne o adesivo obrigatório e compare as mesmas decisões
Altere apenas se Violet é obrigatório. Repita Guardar A, Devolver B com Desconformidade de Baia e Guardar C. O Caso A agora falha porque o adesivo está ausente, então a pontuação cai para dois em três. Em uma rodada revisada separada, Devolver A com Adesivo Ausente e mantenha as duas escolhas restantes. Isso restaura três em três.
A folha de trabalho mantém os documentos e a ordem de entrada fixos para a comparação. Em uma construção funcional, verifique se os jogadores notam o requisito ativo e podem dizer por que A mudou. O guia para refazer uma construção após uma mudança pode ajudar a manter essa verificação focada.
Construa uma mesa de inspeção com uma regra que você pode refazer
Comece com dois cartões, três bandejas e uma mudança de versão. Comece seu quebra-cabeça de inspeção original com o criador de jogos de IA da SEELE e compare cada motivo registrado com a folha de trabalho antes de adicionar mais campos.
Perguntas frequentes
Por que separar inspecionar e comprometer?
Inspecionar dá ao jogador uma maneira de examinar evidências e verificar um campo novamente. Comprometer decide para onde a bandeja vai e registra o resultado. Mantê-los separados torna mais fácil dizer se um jogador negligenciou um valor ou aplicou a regra errada.
O destino pode estar certo e o motivo errado?
Sim. Uma bandeja pode precisar voltar porque sua baia difere, enquanto seu motivo corresponde. Se o jogador a devolver pelo motivo, registre isso como um erro de motivo. Mostre o campo que falhou para que eles possam ver qual parte da decisão mudar.
Onde a lista de verificação ativa deve aparecer?
Coloque-a perto dos registros e deixe-a visível antes do primeiro comprometimento. Nomeie a versão da regra no livro-razão de resultados também. Quando o jogador refaz com um requisito alterado, eles podem comparar resultados sem precisar lembrar qual lista de verificação estava ativa.
Como devo adicionar outra verificação?
Adicione um caso onde a nova verificação muda o resultado e um onde não muda. Mantenha os casos anteriores disponíveis para que você possa verificá-los novamente. Se um caso falha vários requisitos, teste cada motivo aceito e um motivo que não tem relação.
