How to Model Conflicting Sources in a Game Puzzle Guide

When a puzzle guide has several published sources, the difficult part is rarely collecting more instructions. The difficult part is deciding what the interface should claim when those sources disagree.

I ran into that problem while organizing a guide for The Last Taxi, a side story in CONTROL Resonant. The route has seven reported taxi locations and several recurring Threshold puzzle patterns. Most walkthroughs agree on the broad route, but some location descriptions conflict. One source places a taxi west of a landmark while another says north. Another district is described as a warehouse service lane in one guide and a main-road approach in another.

A conventional wiki page tends to flatten those differences into a single confident answer. That makes the page easier to read, but it also hides the most useful information: the answer has a confidence boundary.

Store the disagreement beside the fact

The content model I used separates four things:

• the district or zone name;
• the shared landmark that sources agree on;
• the exact directional claim;
• the evidence status for that claim.

This allows a location card to say “southern island road near the Evac Building” while also explaining that the two written bearings conflict. The shared landmark remains useful, and the disputed detail stays visible instead of being silently resolved by the editor.

That distinction also affects search. A player searching by district can still find the page, while a player already standing at the landmark sees the warning before following the wrong direction.

Match the visible clue, not a fixed answer

The same approach works for puzzle logic. Published guides often pair a particular puzzle with a particular zone. That can be a helpful expectation, but it is risky to encode the pairing as permanent if the encounter can vary.

The safer UI asks what is visibly changing:

• taxi roof signs;
• headlights, tail lights, and roof signs together;
• overhead streetlights in a rhythm;
• tunnel lights switching off;
• mold and loose parts around a damaged taxi;
• shadows changed by a portable light.

The interface then routes the player to a rule to test. It does not return a hard-coded car number. The final confirmation still comes from the game’s green traffic signal.

This is a small example of a broader product rule: when the environment is the source of truth, the guide should help the user observe it instead of pretending a stored answer is always current.

Keep personal state local

The route checklist is intentionally browser-local. A player can mark each of the seven Thresholds after completing all three rounds, and the progress stays in that browser. There is no account requirement and no claim that the checklist syncs with game data.

That choice keeps the feature honest and lightweight. It also makes the privacy boundary easy to explain: the checklist is a convenience layer over the guide, not a remote profile or analytics system.

Write uncertainty as useful UI copy

“Unknown” is often too vague. A better status tells the reader what remains uncertain and what action is safe:

• “source-reported location; not tested in-game”;
• “sources disagree on the landmark approach”;
• “watch one full light cycle before choosing”;
• “confirm the taxi marker before following either bearing.”

These labels preserve the value of imperfect information without turning it into false certainty.

The working example is Resonant Field Guide, an independent guide that organizes the seven-taxi route, the visible puzzle signals, and a browser-local checklist around this model.

For game guides, confidence is part of the data. If two sources disagree, the interface should not hide the conflict. It should expose the stable landmark, label the disputed detail, and help the player verify the next step in the game itself.