Use “doppelganger” as an investigation label, not as a promise that every suspicious customer follows one identical animation. Shift At Midnight’s official Store page describes a loop of examining an ID, cross-checking a computer, and observing behavior. That is enough to build a repeatable check. It is not enough to publish a fixed weakness, damage value, or guaranteed spawn location without a current-build reproduction.
Start with the ID
Read the customer’s ID before rushing to a conclusion. Say what you saw and which field needs a computer comparison. In co-op, one player can inspect while another keeps the next route clear. In solo play, finish the check methodically and avoid abandoning the station task just because a customer feels unusual.
Cross-check the computer
Treat the computer as a second evidence source. A mismatch should become a callout, not an automatic accusation if the current game gives the team another check to perform. Record the exact field, the customer’s location, and whether the behavior changed afterward. This makes reports comparable across generated shifts.
Observe behavior
Watch what the customer does after the ordinary checks. The public description confirms behavior observation as part of the loop, but it does not list every tell. Do not fill that gap with a made-up checklist. If a movement, sound, or interaction repeats, record the mode and update date before calling it confirmed.
Decide and prepare
Once the team has enough evidence, decide whether to continue serving, report the customer, or prepare for the defensive state indicated by the current run. If the creature gets out, switch to the Survival plan: keep a route, use a purposeful barricade or trap, and hide when confrontation is not justified. The official page names those defensive options; their exact timing remains build-sensitive.
Compare reports carefully
Two players can describe the same customer differently if one saw the ID and the other saw only a movement. Put the observations in order and keep the original wording. A useful report includes the shift or mode, the check that was performed, the customer’s location, the behavior that followed, and whether the team reached a decision before the escape. This format makes it possible to compare repeated reports without pretending that a single run proves a fixed tell.
If the evidence remains mixed, keep the team at a safe distance and assign one person to observe while another prepares a route. The Store page confirms the investigation loop and the defensive choices, but it does not disclose a full doppelganger weakness table. Treat community clues as hypotheses until the current build reproduces them.
A useful report template
Write the report in this order: mode, shift context, customer position, ID result, computer result, observed behavior, decision, and outcome. If a field was not checked, write “not checked” rather than guessing. If the creature escaped, note which player saw the transition and what route the team took afterward. A detailed negative result is still useful because it prevents another player from repeating a check that already failed to distinguish the customer.
The template also protects the guide from inherited information. A screenshot or comment from another product, an old branch, or the separate demo should not become a base-game rule. Confirm the Steam AppID and build context before merging a report into this page. Until the evidence is repeated, describe the clue as an observation with a confidence label.
When the report is complete, link it to the date of the next official patch that could affect the clue. That makes later review quick and keeps an old observation from looking like a current guarantee.
Keep the original screenshot or replay note with the report when possible, but do not publish private player information. The goal is a reproducible clue, not an identity claim about a teammate.