To make an original inspection game inspired by Papers, Please, start with two records and a visible checklist. In the fictional Pattern Library Intake, a clerk compares a decorative tray’s label with a request card. One tray matches the requested motif and shelf bay. It has no Violet sticker. Whether the clerk should shelve it depends on the checklist for this run.
Let the player examine the evidence, then commit a decision. A replay with the same documents and one changed requirement shows whether the game checks the current rule.
Turn document comparison into your own inspection puzzle
In Papers, Please, a fictional immigration inspector makes decisions using travelers’ documents and inspection tools. Lucas Pope describes that premise in the official press kit and his developer catalogue.
Use the broad idea of checking evidence against a rule. Give your version its own setting and consequences. The pattern library sorts decorative printing trays. The request and label each list a Motif and a Bay. The label may also have a Violet sticker.
Separate inspection from a committed decision
Inspect highlights corresponding fields and shows their raw values. It costs no turn. The checklist asks whether Motif and Bay match. In the revised version, it also requires the sticker. Keep the active checklist visible while the player decides.
Shelve sends the tray to the bay on its request. Return requires one reason from a fixed list. Record what the player chose, what the checklist expected, and whether the decision and reason were correct. Give feedback for the resolved tray and clear the temporary inspection highlights.
| Input | Effect |
|---|---|
| Inspect | Show the comparable values without committing. |
| Shelve | Commit to the request bay. Score as correct when all required checks pass. |
| Return with a listed reason | Commit the return. Score as correct when that reason is an actual failed requirement. |
| Return without a listed reason, or a command for another case | Reject without advancing or changing the ledger. |
The three Return reasons are Motif Mismatch, Bay Mismatch, and Sticker Missing. If more than one required check fails, accept any reason that applies. A listed reason can still be wrong for the tray. A wrong reason records an error and advances to the next case.
Replay all three trays against the same checklist
Use the following cases in order. After the third commitment, show the score and case-specific feedback. Only Reset is accepted after completion.
| Case | Request | Tray label | Baseline decision | Sticker required |
|---|---|---|---|---|
| A | Arc, North | Arc, North, no sticker | Shelve. | Return with Sticker Missing. |
| B | Dot, South | Dot, North, Violet | Return with Bay Mismatch. | Return with Bay Mismatch. |
| C | Wave, North | Wave, North, Violet | Shelve. | Shelve. |
In the baseline, Shelve A, Return B with Bay Mismatch, and Shelve C gives three correct decisions. Try returning B for Motif Mismatch. Both records show Dot, so the reason is wrong even though returning the tray is the right destination. The ledger should record the specific reason error.
Give AI a small rule checklist and a replay
Ask for the two cards, the active checklist, and a short ledger. Give the prototype both expected decisions and examples of actions that should leave the current tray alone.
Build an original Pattern Library Intake inspection puzzle.
Show one Request and Tray Label pair at a time.
A: request Arc North; label Arc North, no sticker.
B: request Dot South; label Dot North, Violet.
C: request Wave North; label Wave North, Violet.
Match Motif and Bay. Support one setting for whether Violet
is required. Keep the selected checklist fixed during a run.
Inspect shows both values and makes no commitment.
Shelve sends the tray to its requested bay. Return requires one
listed reason: Motif Mismatch, Bay Mismatch, or Sticker Missing.
Accept a Return only as correct if the reason is a failed check.
Missing or unlisted reasons and stale case commands do not advance.
Every valid commitment records expected decision, submitted
decision and reason, and correctness. Show specific feedback.
After all three, show the score and stop. Reset starts at case A,
clears the ledger and highlights, and uses the selected checklist.Inspect twice and confirm that the score and case do not advance. Submit Return without a reason. Then select a listed but incorrect reason and confirm that it advances with an error. Reset and make sure the old ledger and case highlights are gone.
Make the sticker required and compare the same decisions
Change only whether Violet is required. Repeat Shelve A, Return B with Bay Mismatch, and Shelve C. Case A now fails because the sticker is absent, so the score drops to two out of three. In a separate revised run, Return A with Sticker Missing and keep both remaining choices. That restores three out of three.
The worksheet holds the documents and input order fixed for the comparison. In a working build, check whether players notice the active requirement and can tell why A changed. The guide to replaying a build after one change can help keep that check focused.
Build one inspection desk with a rule you can replay
Start with two cards, three trays, and one version change. Start your original inspection puzzle with SEELE’s AI game maker and compare each recorded reason with the worksheet before adding more fields.
Frequently asked questions
Why separate inspecting and committing?
Inspect gives the player a way to examine evidence and check a field again. Committing decides where the tray goes and records the outcome. Keeping them separate makes it easier to tell whether a player overlooked a value or applied the wrong rule.
Can the destination be right and the reason wrong?
Yes. A tray may need to go back because its bay differs while its motif matches. If the player returns it for the motif, record that as a reason error. Show the field that failed so they can see which part of the decision to change.
Where should the active checklist appear?
Put it close to the records and leave it visible before the first commitment. Name the rule version in the result ledger as well. When the player replays with a changed requirement, they can compare outcomes without needing to remember which checklist was active.
How should I add another check?
Add one case where the new check changes the result and one where it does not. Keep the earlier cases available so you can verify them again. If a case fails several requirements, test each accepted reason and a reason that is unrelated.
