Shift At Midnight Community — Co-op Roles and Evidence

Shift At Midnight works best when a team treats communication as part of the evidence system. A loud lobby with no owner for the final decision is slower—and more dangerous—than one player following a fixed checklist. The goal of this page is to make every handoff obvious: who is checking, what fact they found, who is allowed to act, and what evidence should be saved if the result is unexpected.

If you are learning the systems for the first time, read How to Play before assigning roles. For compact survival habits, continue with Tips and Tricks. This page focuses on how a group shares those systems without losing facts between the register, computer, sales floor, fuel pumps, and defensive setup.

The fixed evidence call

Every customer call should use the same six fields. Do not replace this format with “looks weird,” “probably human,” or a stream of unrelated observations.

CUSTOMER → RECORD → OBSERVATION → NIGHT FACT → TOOL → DECISION

• Customer: exact displayed name or “unscannable ID”
• Record: alive/dead status and the field being checked
• Observation: the visible match or contradiction
• Night fact: only the notice, news, call, or event active in this run
• Tool: scanner, vehicle lookup, EmotiScope, Anomaly Lens, or “not available”
• Decision: serve, hold for one more check, or confirmed threat

The person at the counter repeats the decisive fact before acting. For example: “Clyde Dawson; record says sheriff and often wears glasses; portrait and date match; no conflicting night fact; lens clear; serve.” If there is still uncertainty, the decision is hold, not a guess.

The counter handoff begins with the displayed identity. The database player should never search a nickname guessed from voice chat.

Why the order matters

The format separates facts that are easy to confuse:

• An ID scan finds a record; it does not prove the holder is human.
• The database is the verified baseline, but its descriptive wording may allow variation such as “often.”
• A current-night warning can make a normally harmless statement testable.
• A normal special-tool result does not erase a contradiction found earlier.
• A customer who appeared in one video is an example, not a permanent script for every randomized run.

When two players disagree, do not vote on appearance. Repeat only the first field where the evidence chains differ. One player may have read “often wears glasses” as “must wear glasses,” or may be applying a newspaper fact from a previous shift. Rechecking that exact field is faster than restarting the entire conversation.

Read status, portrait, birth date, occupation, and listed traits aloud. The fixed order makes an omitted field noticeable to the rest of the team.

Solo plan: four stations, one checkpoint

Solo play is a complete supported route, but the player must prevent task switching from breaking the evidence chain. Treat the store as four stations even though you control all of them:

1. Customer station: ID, profile, appearance, questions, and final transaction.
2. Floor station: cleaning, stocking, deliveries, bags, pests, and other store objectives.
3. Vehicle station: driver interview, flashlight search, plate lookup, and fuel service.
4. Security station: read the threat rule, then stage boards, traps, weapons, healing, and a retreat route.

Complete one station's checkpoint before switching. At the counter, the checkpoint is a final spoken or mental evidence summary. On the floor, it is the objective or payment update. At a vehicle, it is the driver-and-car conclusion. During an alert, it is a complete vulnerable entrance and an open route to safety.

Use quiet gaps for floor work, but never walk away halfway through a customer comparison. If a delivery or cleanup prompt arrives during verification, finish the decision first unless an active survival countdown overrides everything. This creates the same clean handoffs that a co-op team uses without requiring another player.

Two-player plan: counter lead and rover

Two players should split decision continuity from interruptions.

Role	Owns	Calls to the other player	Must not do
Counter lead	IDs, database, interview, transaction, final verdict	Exact mismatch, extra check needed, serve/hold/threat	Approve while the rover is still reporting a vehicle or night fact
Rover	Floor duties, deliveries, pumps, vehicle inspection, first defense setup	Objective complete, plate/vehicle result, delivery location, vulnerable route	Make a customer verdict from across the store

The rover brings outside or floor evidence back in the fixed format. For a vehicle, the call should be: driver name, requested service, plate record, observed car detail, answer to the relevant question, recommendation. The counter lead owns the final action because that player has the full customer chain in view.

The rover should report all three vehicle checks before the counter lead accepts the recommendation. Ordinary crime is not automatically doppelganger evidence.

Safe two-player rotation

Rotate after a completed customer, completed outside route, or closed shift—not in the middle of an evidence chain. A good rotation rhythm is every two or three customers so both players learn the systems without constantly changing authority.

At the handoff, say four things:

1. current customer state: none, waiting, held, or resolved;
2. unfinished floor objective and where its tool was left;
3. deliveries or defensive items already staged;
4. any current-night rule that the next lead must remember.

During an entity countdown, suspend the normal rotation. The player nearest the storage room stages weapons and supplies; the other completes the most important barricade and confirms the retreat route. Return to the normal role split only after the all-clear and cleanup objective.

Three-player plan: counter, floor, and safety

The official design is centered on a maximum of three players. A full intended-size team should separate the three sources of interruption while keeping one clear decision owner.

Counter lead

• Controls the ID, database, questions, special-tool check, and transaction.
• Reads every evidence result in the fixed call format.
• Keeps a customer on hold until the other roles finish a relevant check.
• Has final authority to serve or reject after repeating the decisive evidence.

Floor and vehicle lead

• Completes opening cleanup, stocking, deliveries, bags, pests, and revenue work.
• Owns pump interactions and vehicle checks when a driver arrives.
• Reports objective completion rather than saying a task “looks done.”
• Stops routine work when a current-night clue or alert changes team priority.

Safety and communications lead

• Reads the notice board, news, computer message, phone call, and entity rule.
• Repeats only the fact relevant to the current customer or threat.
• Stages boards, traps, weapons, healing, and a safe lane before they are needed.
• During an alert, calls the timer, completed defenses, target state, and retreat route.

The safety player is not idle before an attack. This role prevents the most common team failure: everyone watches the counter while deliveries, doors, and the current entity instructions go unread.

The safety lead calls one complete placement at a time—route, trap, confirmation—so teammates do not block the same doorway or each other's escape.

Responsibility rotation

Rotate roles at the next customer-free checkpoint. Use a predictable order:

counter → floor/vehicle → safety → counter

This makes each player practice verification, store operation, and survival planning while preserving a named owner at every moment. Before the next shift begins, the outgoing safety lead reads the new notice and hands it to the incoming lead; this prevents last night's fact from carrying into a new randomized shift.

Four to six players: optional patch mode

The July 23, 2026 patch added a lobby setting with a maximum player count of six. The same patch note says the game was designed and marketed around a maximum of three, warns that larger lobbies can become too chaotic, and does not recommend them for a first playthrough. Check Updates when evaluating a newer build because lobby behavior can change after patches.

Treat four-to-six-player sessions as an optional social configuration, not the baseline for guide balance. More people do not create more decision owners. Keep the same three leads and assign assistants:

Extra player	Assistant assignment	Communication limit
Player 4	Floor runner: stocking, bags, cleanup, delivery carry	Reports only task state and tool location
Player 5	Vehicle runner: flashlight check, plate lookup, pump	Reports through the floor/vehicle lead
Player 6	Safety runner: carries boards, traps, and supplies	Reports through the safety lead

Only the three leads should make full-channel calls. Assistants communicate to their lead, and the counter lead remains the only person who closes a customer decision. This avoids six people describing the same face while nobody finishes the plate check.

For a first campaign, stay at one to three players. A larger group can reduce tension, crowd small work areas, duplicate interactions, and obscure which person observed a result. If a problem appears only above three players, include the lobby size in any correction or bug report instead of presenting it as universal behavior.

Host and version readiness

Before opening a serious run, every player should confirm:

• the displayed game build is identical;
• the intended lobby maximum is selected;
• each player can hear normal and proximity voice as expected;
• the host can create a joinable lobby;
• no one has an unfinished update or a different content build;
• the person recording evidence has enough local storage and hides private overlays.

If one player cannot join, do not immediately reinstall every machine. The host should recreate the lobby once, then the affected player restarts the game and client. Confirm that the failure follows that player before changing the host. Work through Troubleshooting in order and change one variable at a time.

If a crash or disconnect occurred, record whether the player was host or client, lobby size, build, night, active objective, and last successful interaction. “Multiplayer broke” cannot be reproduced; “client 3 disconnected on build X while picking up a trap during the Night 5 countdown, twice in two attempts” can be investigated.

How to submit a reproducible correction

Use Support for a guide correction or repeatable site problem. A useful report lets another player reconstruct both the game state and the disputed step without contacting you for missing basics.

Required report fields

1. Page and heading: copy the internal page path and the exact section title.
2. Game build and date: use the build visible when the run occurred; “latest” becomes ambiguous after an update.
3. Mode and lobby: Story Mode or another mode, host or client, and total players.
4. Night and checkpoint: include the current objective, customer phase, or attack countdown state.
5. Expected result: quote or summarize the one guide instruction being tested.
6. Observed result: state exactly what appeared, what interaction was available, and what happened next.
7. Reproduction count: one occurrence, repeated in the same run, or repeated after a new run.
8. Evidence: one cropped screenshot for the relevant field, plus a second image only if it proves the before/after state.

Use this compact template:

• Page / heading:
• Build / date:
• Mode / host or client / player count:
• Night / objective:
• Expected:
• Observed:
• Repeated:
• Screenshot description:
• Random instance or stable rule:

Screenshot checklist

A screenshot should show the smallest complete proof. Keep the relevant name, field, objective, tool output, or result visible. If the claim is about a contradiction, capture both the verified record and the conflicting observation when possible. If the claim is about completion, include the objective update or results screen.

A results screenshot is stronger than a memory of the run because it preserves the exact shift outcome. Pair it with the build and player count in the written report.

Do not send a full desktop capture when a cropped game frame proves the issue. Exclude account names, invite codes, private chats, email addresses, payment details, browser tabs, and unrelated players' voice or video. Never upload save files, executables, crash dumps, or logs unless a trusted support workflow explicitly asks for a specific sanitized file.

Random instance or stable rule?

Story Mode contains randomized customers and events, so every correction starts by classifying the claim.

Usually instance-specific

• customer name, order, appearance, products, dialogue, or patience in one run;
• which profile is easy or difficult to verify;
• a current newspaper, local event, relationship, or customer claim;
• the timing of a routine interruption;
• the exact path a teammate took through the store.

These details can support an example but should not become “always serve this name” or “this person is always a threat.” A different instance does not automatically invalidate a guide.

Usually stable enough to test

• what an interface field means;
• the order of ID, database, observation, question, nightly fact, and tool checks;
• the objective text and the confirmation that completes it;
• a named tool's documented limitation;
• an entity instruction presented in the active run;
• a patch's lobby option, fix, or announced behavior;
• a page link, missing image, broken anchor, or mobile layout issue on this site.

To promote an observation into a stable rule, reproduce it on the same build or support it with the current in-game instruction. If a second player or video shows a different customer while the same interface rule still works, preserve the rule and rewrite only the example.

Privacy, safety, and fair collaboration

• Share game evidence, not personal identity. A screen name is rarely needed to explain a mechanic.
• Ask before recording other players' voices. Use a transcript of the evidence call when audio is unnecessary.
• Hide lobby codes, account overlays, direct messages, and desktop notifications before capturing.
• Do not distribute modified executables, unverified downloads, or another player's save data.
• Do not shame a teammate for a wrong verdict. Rebuild the evidence chain and identify the first field that was missed.
• Keep spoilers proportional. Name the night and section before describing a late-game mechanic.
• Treat a correction as a testable improvement, not a contest between creators or communities.

Team pre-shift card

Before the door opens, run this final checklist:

• Build: everyone reports the same version.
• Lobby: one to three for intended balance; four to six only by deliberate choice.
• Roles: counter, floor/vehicle, and safety owners are named.
• Call: everyone uses customer → record → observation → night fact → tool → decision.
• Authority: the counter lead owns customer actions; safety owns attack setup calls.
• Rotation: roles change only at a completed customer, outside route, or shift.
• Evidence: the recorder knows which screenshots are needed and what private data to hide.
• Fallback: unresolved technical issues go through Troubleshooting; reproducible corrections go to Support.

The best community contribution is not the loudest theory. It is a clear, versioned observation that another player can reproduce—and a team routine that still works when the next shift changes the customer order.