BOMBANANA! Demo Callout Guide

This guide is written for Deaf Monkey — the player who sees the bomb, watches Mute's gestures, and speaks instructions to Blind. The challenge is not just knowing what to say. It is knowing the order to say it in, what to say while still waiting for Mute, and what to say the moment something goes wrong mid-callout.

The BOMBANANA! demo's in-game manual has blank pages the full release will fill in, so this guide does not give per-module answer tables. What holds steady across all modules is the callout structure itself — the order, the wait phrases, and the recovery lines.

The callout template

Use this order every time, regardless of which module your team is on. Each step solves a specific problem in the relay chain — cutting any step creates a specific failure.

Position	What to say	Example
1. Module name + location	"[Module], [where on the bomb]."	"Wires, top right."
2. State or count	"[What you can see right now]."	"Four wires, left to right: green, blue, red, yellow."
3. LED or required detail	"[LED color or other visible detail]."	"Red LED."
4. Wait phrase	"Waiting."	Hard pause — stop speaking, watch Mute.
5. Answer from Mute	"[What Mute just signaled]."	"Second wire."
6. Confirm + stop condition	"Confirm: [action]. Then stop."	"Confirm: cut second wire. Then stop."
7. Act signal	"[Your agreed act word]."	"Act."

Steps 1–3 happen before Mute looks anything up. Step 4 is a hard pause — stop speaking and watch Mute. Steps 5–7 happen only after Mute signals. The confirm in step 6 is not optional: it gives Blind the exact action and the stop point before the act signal fires.

Why module name comes first

Blind Monkey cannot see the bomb. When you start a callout, Blind's hands are somewhere on the panel — possibly not on the right module yet. If you lead with a color, a count, or an instruction, Blind has no spatial anchor to locate the correct area first.

Module name first solves this: Blind locates the right area before any clue data arrives. Module position (top right, bottom left) narrows it further. Only after both does Blind know which panel the incoming clue belongs to — and only then is it safe to act on it.

The same problem applies to Mute. Several manual pages share overlapping data — colors, counts, or LED states that could belong to more than one module. A callout starting with "green, blue, red" without a module name gives Mute nothing to anchor a page lookup on. Module name first is not just courtesy; it is the only thing that lets Mute find the right page under time pressure.

Check before speaking

Deaf Monkey watches two sources of information at once: the bomb's current visible state and Mute's current gesture. Neither is enough on its own. The bomb tells you what is physically true right now. Mute's gesture tells you what the manual says — but only about the state the bomb was in when Mute formed that gesture.

Run this check before every callout, not just the first one of the round:

1. Look at the bomb's current state. What module is active? What did Blind's last action change? Note the current LED color, count, or display value.
2. Check Mute's current gesture against that state. Does the gesture assume the same module, the same count, and the same LED you are currently looking at? If Blind's last action changed the LED or stage, Mute's gesture may now describe a state that no longer exists.
3. If both agree: proceed with the template. Both channels confirm the same step. Relay it.
4. If they disagree: hold before speaking. Say "Hold. Mute, discard — re-gesture current state." Wait for Mute to form a new gesture against the current display before continuing.

Skipping this check is the main way a correct gesture produces a wrong callout. The gesture was right when Mute formed it; the bomb changed; the relay moved a stale instruction to Blind.

Hold, wait, and abort phrases

Blind Monkey cannot hear hesitation. A trailing-off sentence sounds the same as a confirmed instruction until the last word. Use these phrases to stop Blind before they act on incomplete or wrong information.

Situation	Say	Do not say
Mute is still forming a gesture — answer not in yet.	"Waiting."	Any partial answer. "Probably…" or "I think…" counts as a partial answer to Blind.
Mute's gesture was unclear or ambiguous.	"Hold. Mute, repeat that."	A relay built on a guess. Blind cannot tell the difference between a guess and a confirmed answer.
The bomb's visible state changed after Blind's last action.	"Hold. Re-reading [module name]."	Continuing the previous callout. The LED, count, or stage may have changed — the old answer may be wrong now.
You started speaking and realized the answer was wrong mid-sentence.	"Hold. Correction incoming."	Trailing off without a clear stop signal. Blind acts on the last complete phrase they heard.

"Hold" works as a freeze word only if it has no other meaning in the callout. Agree on it as the dedicated stop signal before the round — and make sure it is never used as a filler word ("hold on, I'm looking"). Once it has another use, Blind cannot treat it as a reliable stop.

Wrong-input recovery

A wrong input can change the LED color, the displayed value, or which stage of the module is active. You may not know which changed until you re-read. Use this sequence immediately after any wrong input — do not let Blind attempt a self-correction on the changed state.

1. Say "Wrong. Hold." — Blind releases the module. Mute stops working on the current solution path.
2. Re-read only what changed. If the LED changed, call the new LED. If the displayed value changed, call the new value. If the stage indicator changed, call the new stage. You do not need to restart from step 1 of the template unless the entire module state reset.
3. Wait for Mute to re-check the manual against the updated state and re-signal the new answer.
4. Resume the template from step 5 (Mute's answer). Give the confirm and act signal as normal.

The temptation after a wrong input is to keep speaking — to correct the course by adding information. That stacks a second callout on top of an already-changed module state. "Wrong. Hold." first, re-read second.

Pre-round agreements

These five agreements remove the need to improvise under timer pressure. Each one exists because a specific failure in the sections above has no verbal fallback if it was not decided in advance.

Item to agree	What to decide	Why it cannot be improvised mid-round
Act signal	One word only — no other use in the callout. Example: "act."	Blind waits for this exact word before touching anything. Ambiguous words like "go," "okay," or "ready" create false act signals.
Hold signal	One word that freezes Blind until you say the act signal again. Example: "hold."	Without a hold signal, you cannot pause Blind mid-motion if the bomb state changes between your callout and their action.
Left/right orientation	Always Blind Monkey's left and right — not yours.	You watch the bomb on screen; Blind touches a physical panel. The same direction word produces opposite actions from different reference frames.
Mute's discard signal	A visually distinct gesture meaning "ignore my last signal; I am re-gesturing."	Without this signal, you cannot tell whether Mute's current gesture describes the current bomb state or a state that no longer exists after Blind's last action.
Wait duration	How many seconds you wait for Mute's signal before calling hold.	Without a time limit, silence looks identical to "still reading." A fixed wait stops you from stacking a second callout on an unresolved first one.

Source boundary

The callout template on this page is derived from the role constraints described on the official BOMBANANA! Steam page and the demo Steam page: Deaf Monkey sees the bomb, speaks to Blind, and watches Mute's gestures; Blind Monkey touches the bomb and cannot see; Mute Monkey holds the manual and cannot speak. The two-channel check sequence, hold phrases, and mid-callout abort procedure follow from these confirmed role constraints. No developer interview or official callout guide is publicly available as of July 2026.

Per-module callout examples (Wires, D-pad, Numpad, Switch Panels) are well-documented by other guides and are not duplicated here. For role-specific communication failures — wrong-relay correction, stale-gesture handling, multi-step gesture encoding — see the Deaf Monkey guide, Mute Monkey guide, and Blind Monkey guide.