BOMBANANA! Deaf Monkey Guide

Before every instruction you give to Blind Monkey, check the bomb's visible state against Mute Monkey's current gesture — you are the only player watching both at once, and you will never hear whether the instruction actually landed. That single habit is most of what separates a smooth Deaf Monkey run from a stalled one.

This guide covers the specific problems that make that habit hard: what each channel cannot tell you on its own, how to handle a conflict between them, the one-way confirmation gap between you and Blind Monkey, and what to agree on before your first round.

The two-channel bottleneck

Each role is missing exactly one sense: Blind Monkey can't see, Mute Monkey can't speak, Deaf Monkey can't hear. That leaves Deaf Monkey with sight and speech intact, watching two separate sources of information at once. Neither one is enough on its own.

Input channel	What it tells you	What it does NOT tell you
The bomb's visible state	What is physically true right now — what changed after Blind Monkey's last action.	Which manual rule or option order applies to that state.
Mute Monkey's gestures	Which rule, option, or sequence the manual says to follow.	Whether the bomb's current physical state still matches what that gesture assumes.

Before you speak: check both channels against each other. If you only relay the gesture without glancing at the current bomb state, you can hand Blind Monkey an instruction that was correct a few seconds ago and wrong now.

When the two channels disagree

No confirmed rule exists for which channel takes priority. In practice: treat the bomb's visible state as the current physical fact, and treat Mute Monkey's gesture as an interpretation of an earlier state that may no longer apply.

Situation	Why it's a conflict	What to do
Mute signals "second option" but you count a different number of visible choices than the gesture assumes.	The gesture describes a layout that may not match what you're looking at right now.	Trust the visible count. Ask Mute to re-point at the current layout before you speak to Blind.
The bomb visibly changes while Mute is still mid-gesture on the previous step.	Mute's signal describes a state that no longer exists.	Hold the instruction. Wait for Mute's next gesture against the new state — do not relay the stale one.
Mute's gesture is ambiguous or repeats without a clear meaning.	An unclear signal is not information — passing it on just moves the confusion to Blind Monkey.	Do not guess and relay anyway. Signal back to Mute for a repeat before saying anything to Blind.

The one-way confirmation gap

Blind Monkey can hear and speak. So when you give an instruction, Blind Monkey's spoken response — "done," "which one," "didn't catch that" — travels through the air same as any voice line. You just can't hear any of it. Voice chat is restricted by role — this gap is a designed mechanic, not something the team can fix by talking louder or standing closer.

The failure mode this causes: if you keep giving instructions on the assumption that each one landed, you can end up several steps ahead of what Blind Monkey has actually done, because you never heard Blind say "wait" or "I didn't catch that." Your only real confirmation channel is visual — the expected change on the bomb itself.

• After speaking one instruction, watch the bomb for the specific change that instruction should cause.
• If that change appears, continue. If it doesn't appear within a couple of seconds, stop — do not add a second instruction on top of an unconfirmed first one.
• Agree before the round starts on one clearly visible action Blind Monkey can take (not a spoken word) to signal "I didn't understand," since you cannot hear that request if it's spoken.

One instruction at a time

Because you're merging two channels, the natural mistake is trying to relay both of them in one long sentence — the bomb state, the gesture, and the next step, all at once. That triples the chance Blind Monkey combines the pieces wrong. Run this sequence instead:

1. Look at the bomb's current state first.
2. Check Mute Monkey's current gesture against that state, not against what the gesture meant a few seconds ago.
3. If the two agree, say one instruction: the target and the action. Nothing else.
4. Watch for the expected visible change before saying anything further.
5. If the two channels disagreed in step 2, resolve that first — do not speak an instruction built on a conflict you haven't settled.

Relay agreement checklist

Five items, specific to the relay problem above. Agree on each one out loud before your first round.

1. Mute Monkey's "discard last gesture" signal. When the bomb state changes mid-gesture, the gesture Mute was forming becomes stale — but nothing tells you that automatically. Agree on a specific signal Mute can give to mean "ignore what I just showed you; I'm re-gesturing against the current state."
2. What visual change counts as "it worked" for each action type. Blind Monkey's spoken confirmation is inaudible to you, so watching for the expected physical change on the bomb is your only confirmation channel. Agree on what that change looks like before the round, not mid-round when there's no time to establish it.
3. Who re-checks first when the two channels conflict. Without a pre-agreed rule, both you and Mute pause waiting for the other to move. Decide now: does Mute re-gesture against the current bomb state, or do you describe the visible state back to Mute first?
4. How long you wait before assuming an instruction didn't land. Without audio confirmation, silence from Blind Monkey looks the same whether they're executing or confused. A timed wait forces you to stop before stacking a second instruction on top of a possibly unheard first one.
5. Blind Monkey's visible interrupt signal. Blind Monkey can speak, but you can't hear it. Any spoken "wait" or "repeat that" is inaudible to you. Agree on a specific visible action Blind Monkey can use to stop you mid-instruction — and make sure it's something they can do without accidentally operating the bomb.

Relay mistakes that break the two-channel merge

• Relaying both channels as two separate callouts. The temptation: describe what you see on the bomb, then relay what Mute just signaled, and trust Blind Monkey to combine them. In practice, if the two didn't fully agree, Blind Monkey ends up making the merge decision under time pressure, with less context than you had.
• Speaking a second instruction before confirming the first one landed. The temptation: the next step is obvious, Mute is already gesturing it, so you continue. But you have no audio channel back from Blind Monkey — you never heard "wait" or "I didn't catch that." The second instruction lands on top of an unresolved first one.
• Treating a gesture as current after the bomb state has changed. The temptation: Mute's gesture was correct when formed — it matched the bomb state a moment ago. Nothing flags the gesture as stale when the bomb changes. You relay it as if it still applies, which it may not.
• Skipping the pre-round agreement on a visible interrupt signal. The temptation: it seems obvious that Blind Monkey would do something visible if confused. Under real round pressure, "something visible" isn't specific enough — any unexpected movement from Blind Monkey looks like task execution until you realize it wasn't.

Post-round review: catching relay failures

The mistakes above are hard to notice mid-round because, by design, you can't hear most of the evidence that one happened. Ask these questions after every attempt.

Question	What it catches
Was there a moment you gave an instruction and moved on without checking the bomb actually changed?	Unconfirmed instructions stacking up while Blind Monkey was still stuck on an earlier one.
Did you ever relay a gesture that no longer matched the current bomb state?	Stale-channel relays caused by not re-checking the visible state before speaking.
Did Blind Monkey try to interrupt you with a visible signal you missed?	Gaps in the pre-agreed visible interrupt signal, or a signal that wasn't clear enough to notice mid-round.