Airport Security Sucks Team Guide

Airport Security Sucks becomes easier when each player knows what they own during pressure. A team does not need complicated strategy in the first session. It needs a queue owner, a station owner, and a short language for problems. If everyone talks at once or everyone chases the same passenger, the room falls apart even if each player understands the controls.

Use this page as a co-op setup before your next run. Pick roles, agree on callout names, then run one session where the goal is not winning fast. The goal is proving that every player knows when to stay, when to rotate, and when to stop talking so the most important callout can be heard.

Long explanations are useful after a run, not during the run. During pressure, use short calls: queue, bag, scan, hold, output, reset, stuck. Add one direction or station name if needed. A useful callout tells another player what changed and what must happen next.

Avoid blaming language. Saying "you missed the bag" wastes time and usually makes the next mistake worse. Say "bag at scanner" or "runner take bag" instead. The goal is to move attention, not assign fault.

In a two-player run, one player should stay close to the core inspection loop while the other becomes the runner. The runner should not wander permanently. They move to the next problem, fix it, and return to a known fallback position. If both players become runners, the main station loses ownership.

In a three-player run, the third player should act as a controlled floater. That means they help where the queue is about to break, then report back. The floater should not quietly start a side task unless the queue lead says the core loop is stable.

The best teams reset quickly. After a bad run, ask three questions: What station failed first? Which role had no owner? Which callout came too late? Do not review every mistake. Find the first break and change one habit for the next run.

If you cannot identify the first break, assign a caller for the next session. The caller watches the whole room and says only the priority. That single change often improves co-op games more than a long strategy document.

Roles should be stable during pressure but flexible between runs. Rotate roles only after a run ends or during a clearly safe moment. If the queue lead suddenly becomes runner without saying so, the team loses its reference point. If the runner quietly takes over inspection, two players may assume someone else is watching bags.

Use a simple transfer phrase when a player changes jobs: taking queue, leaving scanner, runner covering bags, caller watching side room. The phrase matters because it changes ownership in everyone's head. Without the phrase, the team sees movement but not responsibility.

Voice chat should be quieter when the room is hardest. That sounds backwards, but pressure calls need space. Use jokes, long explanations, and theory after the run. During a run, the player with the most urgent information speaks first. If two calls collide, the caller chooses one priority and everyone follows it for a few seconds.

If your group plays casually, do not turn the game into a workplace. Keep the system light: one role each, short callouts, one reset phrase, and a quick review after failure. The goal is to keep the funny chaos while removing the mistakes that make players feel helpless.

A useful post-run review is short and specific. Pick one failure, name the first station that broke, and decide one behavior to test next. Do not replay the entire run from memory. The last mistake is often just the visible result of an earlier ownership problem, such as nobody watching the queue or two players chasing the same bag.

If your team records clips, mark the timestamp where the first bottleneck appears. Later, convert that timestamp into a general rule instead of uploading or copying the clip into the guide. A sentence such as 'the runner must return after clearing bags' is more durable than a clip-specific command that only worked in one build.