Tribe Gameplay Reference

Source: docs/tribe-gameplay.md Date: 2026-05-23 Feature: Document Tribe Gameplay Epic (specs/104-document-tribe-gameplay)

Overview

The tribe gameplay system transforms the early game of the Survivor fantasy simulator into proper Survivor tribe-based play. Instead of a flat individual competition, the game splits into team-based and individual phases, mirroring how the real show works.

How tribes form: During the schoolyard draft, each manager drafts one player at a time. The manager's picked players become their starting tribe. Every manager gets exactly one tribe — there are no unaffiliated players and no multi-tribe managers.

The three-phase lifecycle:

1. Pre-merge — Tribe vs. tribe. Each episode runs reward and immunity challenges at the tribe level. Only the losing tribe attends tribal council. Managers submit directives, but interactions are constrained to within your own tribe. Uneven tribe sizes are balanced through a sit-out system where larger tribes bench players for each challenge.
2. Merge — The turning point. A configurable, suspenseful rising-chance trigger determines when the merge happens. During the merge episode, there is no tribal council — all players survive and earn points. The merge episode also serves as the jury start point.
3. Post-merge — Individual competition. Challenges return to individual immunity, all players attend tribal council, reward challenges become individual, and all pre-merge directive restrictions are lifted.

Key concepts:

• Tribe-vs-tribe challenges: Tribes compete as teams. The tribe with the highest average challenge weight wins. Sit-outs are resolved before scoring to ensure fair team sizes.
• Losing tribe attends tribal: Only the tribe(s) that lost immunity send members to tribal council. Winning tribe members cannot be voted out, play idols, or be targeted by directives.
• Rising-chance merge: Rather than merging at a fixed episode, the probability of merging increases linearly as the player count approaches a configurable target. This creates suspense while ensuring the merge always happens before the finale.

Tribe Creation

Schoolyard Draft → Tribe Assignment

During the draft, each manager builds their roster through alternating picks. Every player a manager selects is automatically assigned to that manager's tribe. There is no "post-draft tribe assignment" step — the tribe roster is the draft roster.

One manager = one tribe. The draft ensures each manager gets one tribe with no cross-manager player sharing.

Automatic Tribe Naming & Colors

Tribes are automatically named using Survivor-themed names drawn from a curated pool. Managers see their tribe name and color appear as they draft and can optionally rename.

Colors are curated for visual distinction — no two tribes in the same season share the same color, and warm/cool/neutral categories help differentiate tribes at a glance.

Renames are allowed during the draft, but tribe identity locks at draft submission. Once submitted, names and colors are final for the season.

Manager-to-Tribe Relationship

Each tribe is permanently linked to its manager. The manager controls directives, sit-out selections, and other decisions for their tribe's players. AI managers receive automatically generated tribe names and have their directives and sit-outs handled by the engine.

Pre-Merge Gameplay Loop

During pre-merge, the game tracks the episode phase as pre_merge. Each pre-merge episode follows a fixed cycle that repeats until the merge triggers:

Manager Directives → Reward Challenge → Immunity Challenge → Tribal Council → Repeat

Every player in pre-merge belongs to a tribe, and all challenge and tribal mechanics are scoped to those tribes.

Manager Directives (Pre-Merge)

Before each episode, managers submit directives — strategic instructions for their players. During pre-merge, cross-tribe interactions are restricted to keep the team-based structure intact.

Restricted directives (target must belong to the same tribe as the directing player):

Unrestricted directives (self-targeted, always allowed):

throw_challenge: Accepted with a warning flag. A player throwing the challenge harms their entire tribe's immunity chance, which is rarely beneficial. The engine does not reject it, but the UI warns the manager.

Validation: Directives are validated at submission time. A form_alliance directive may select multiple allies, and every selected ally is checked against the acting player's tribe. Cross-tribe violations are rejected with an error message that identifies each offending target. The engine also performs defensive runtime filtering — any cross-tribe pairing that slips through validation is silently ignored during simulation, without discarding valid pairings from the same directive.

Post-merge: All directive restrictions are lifted. Managers can target any player regardless of original tribe.

Pre-Merge Alliances

In addition to manager-directed alliance formation, the engine's organic alliance dynamics are scoped strictly by tribe during pre-merge:

• Intra-tribe formation: Newly formed alliances only group players from the same tribe. Cross-tribe alliances cannot form pre-merge.
• Tribe size limits: Tribes with fewer than 2 active members cannot form new alliances, and alliance sizes cannot exceed the number of active players in the tribe.
• Per-tribe evaluation: Each tribe independently evaluates alliance formation with up to max(1, floor(tribePlayerCount / 4)) slots per episode.

Reward Challenge

Each pre-merge episode begins with a reward challenge that runs before the immunity challenge. The reward challenge is a tribe-vs-tribe contest: tribes compete as teams, and the winning tribe receives a mechanical bonus that applies to their members for that episode only.

Reward Types & Effects

Four reward types (Comfort items, Food, Idol clue, Spy mission) are selected uniformly at random each pre-merge episode. Letters from Home is excluded from the pre-merge reward pool — it is reserved as a special one-time event that occurs only near the end of the game (post-merge, 6 or fewer remaining players). Effects are tribe-wide (all members of the winning tribe benefit) and scoped to a single episode.

Pre-merge only: the full tribe pool is available. After the merge, Comfort items and Spy mission are no longer offered — the reward challenge becomes an individual contest drawn from a reduced pool (Food, Idol clue, plus Letters from Home when eligible).

Tribe Contest Formula

The reward challenge uses the same tribe-vs-tribe scoring formula as the immunity challenge:

tribeScore = avgWeight * (0.8 + rng() * 0.4)

Where avgWeight is the average challenge weight of that tribe's participating members (after sit-out resolution), and rng() rolls a single noise value for each tribe. The tribe with the highest score wins the reward.

Effect Application

Effects are applied immediately after the reward challenge resolves and before the immunity challenge runs. This means reward bonuses (like the Food boost to challenge weight) affect the same episode's immunity challenge.

Post-merge: Reward challenges become individual contests. Tribe-vs-tribe mechanics and tribe-wide effects are skipped.

Immunity Challenge & Sit-Outs

The immunity challenge determines which tribe is safe from tribal council. Like the reward challenge, it's a tribe-vs-tribe contest using the tribe scoring formula.

Tribe Scoring Formula

tribeScore = avgWeight * (0.8 + rng() * 0.4)

The formula works as follows:

1. Each tribe's participating members (after sit-outs) have their challenge weights averaged
2. A noise multiplier is rolled once per tribe: a random value in [0.0, 1.0] scaled by 0.4 and added to a base of 0.8, producing a factor in [0.8, 1.2]
3. tribeScore = avgWeight * noiseFactor
4. The tribe with the highest score wins immunity

Note: The noise is rolled once per tribe, not once per player. This preserves the team-based nature of the competition while introducing variance.

Sit-Out Resolution

When tribes have uneven sizes (managers drafted different numbers of players), larger tribes must sit out members to create even teams. The goal is to give all tribes a fair competition.

Equalization rule: Reduce each larger tribe's active participants to match the smallest tribe's size.

Example: If Tribe A has 5 members, Tribe B has 4, and Tribe C has 3 — then both Tribe A and B sit out members until each has 3 active participants.

Sit-out eligibility states:

No-consecutive-sit-out rule: A player who sat out the previous challenge cannot be selected to sit out again unless every eligible player on their tribe has also sat out recently. This ensures fair rotation of sit-out duty.

Manager selection first: Managers can manually choose which players sit out. If a manager doesn't make selections, the engine randomly picks from the eligible pool, deprioritizing previously-sat-out players.

Winning & Losing Tribes

The tribe with the highest tribeScore wins immunity. All other tribes are considered "losing tribes" and must attend tribal council.

Post-merge: Tribe-vs-tribe challenges are replaced with individual immunity challenges. Sit-outs are no longer needed (all players participate).

Tribal Council

Tribal council during pre-merge is scoped to only the tribe(s) that lost the immunity challenge. Winning tribe members are entirely excluded from the voting process.

Scoping Rules

• Voters: Only members of the losing tribe(s) can vote
• Targets: Only members of the losing tribe(s) can be targeted for elimination
• Winning tribe: Members cannot vote, cannot be targeted, and are completely absent from the tribal council simulation
• Cross-tribe directives: Any directive targeting a player in a different tribe (e.g., a target_vote for a player in a winning tribe) is silently ignored — not an error, just non-applicable
• Winning-tribe idols: Idol plays submitted by winning tribe managers are not processed — they have no one to save and no vote to nullify

Internal Mechanics (Unchanged)

Within the losing tribe's restricted player set, all standard tribal council mechanics operate normally:

• Vote weights and probability formulas
• Alliance vote coordination
• Idol plays (finding, playing, nullifying votes)
• Tie-breaking rules
• Elimination and point awards

The only difference is the scope of participants — everything else behaves exactly as it does post-merge.

Multiple losing tribes: If more than one tribe loses (possible when all tribes have the same size), each losing tribe holds its own tribal council scoped to its own members.

Post-merge: Tribal council returns to all-player participation. Tribe scoping is removed.

Merge Trigger

The merge is not a fixed episode. Instead, a rising-chance probability determines when the merge happens, creating suspense while guaranteeing it occurs before the finale.

Season Configuration

At the start of each season, three merge parameters are set:

The merge window is [mergeTargetPlayers - mergeDeviation, mergeTargetPlayers + mergeDeviation]. With defaults, this is [6, 10] — merge becomes possible when 10 or fewer players remain.

Rising-Chance Probability

Within the merge window, the probability of merging scales linearly from 0% at the upper bound to 100% at the lower bound:

mergeChance = (upperBound - currentPlayers) / (2 * mergeDeviation)

Examples with target = 8, deviation = 2 (window [6, 10]):

Each pre-merge episode, after calculating the merge probability, a random value is rolled against the season's rolledMergeThreshold. If the probability exceeds the threshold, the merge triggers.

Force Conditions

Regardless of probability, the merge always triggers under these conditions:

1. Below the lower window bound: Player count drops below mergeTargetPlayers - mergeDeviation (below 6 with defaults). The merge fires immediately at the start of the next episode.
2. Penultimate episode: The merge always triggers before the final 3 episode to ensure a proper post-merge phase.
3. Already merged: Once merge has happened, it cannot happen again. The phase transitions to merge then post_merge.

Merge Episode Behavior

When the merge triggers:

• The episode phase is set to merge for that episode
• Individual immunity challenge — tribe-vs-tribe is suspended
• No tribal council — all players survive the merge episode
• All players earn survival points — no one is voted out
• Idol finds and alliance dynamics proceed normally
• The merge episode counts as the jury start point: players eliminated after this episode become jury members

After the merge episode completes, the phase transitions to post_merge for all subsequent episodes.

Jury Tracking

The campaign_jury directive becomes relevant once the merge episode has occurred. Players can campaign for jury votes, influencing their chances of winning if they reach the final tribal council.

Post-Merge Behavior

After the merge episode, the game transitions to post_merge phase. Tribe mechanics are fully retired, and the game returns to individual competition.

Key changes:

• All pre-merge directive restrictions are lifted
• Tribe names and colors remain visible for historical reference but have no mechanical effect
• Individual reward challenges replace tribe-vs-tribe reward contests
• Sit-out picker is hidden (no tribe-based challenge balancing needed)
• Alliance formation expands across the entire cast; intact pre-merge alliances persist and continue to protect allies

Final Four Fire-Making (Penultimate Episode)

On the penultimate episode (totalEpisodes - 1) with exactly 4 active players, there is no tribal vote. The merge is already forced (penultimate-episode force condition), and the vote-out is replaced by a fire-making selection:

1. Safe pick — the immunity winner is safe, then picks one of the other three players (favors allies) to advance as the second finalist.
2. Fire-making — the remaining two players compete head-to-head; the simulated winner (weighted by challenge performance) advances as the third finalist, and the loser is eliminated.
3. The finale receives exactly three finalists; the fire-making loser joins the jury.

The episode page shows a "Fire-Making Challenge" card (a story paragraph explaining the safe pick and fire duel, the safe pick, participants, winner, and the eliminated player) instead of the "Vote Breakdown" card. A 4-player episode that is not penultimate still uses the normal post-merge vote.

Narratives: The fire-making selection produces a final-four story (results.finalFour.story) that explains why the immunity winner chose their safe pick (grounded in the current alliances) and how the fire duel played out. Individual (post-merge) immunity and reward challenges get their own narratives via generateIndividualChallengeNarrative() in src/lib/challenge/narrative.ts, mirroring the existing tribal-state challenge narratives. Both are generated post-simulation (OpenAI with a deterministic fallback) and rendered read-only on the episode page.

The finale gets one too: after the jury vote resolves, results.finale.story narrates the final tribal council — the finalists' pitches, the jury's questioning, and how the votes decided the winner (including a tie-break) — and renders below the vote tallies in the "Jury Vote" card and the "Season Complete" card.

Edge Cases & Notes

Tribe Size Extremes

• Single tribe: If only one tribe exists (unlikely in normal play), the merge triggers immediately since there's no tribe-vs-tribe gameplay to run.
• Zero active members in a tribe: If all members of a tribe are eliminated pre-merge, that tribe is functionally removed. Remaining tribes continue the loop.
• One active member in losing tribe: The sole player cannot vote (no valid targets) and is automatically eliminated. The engine handles this edge case gracefully.

Idol Protection

• All losing tribe members idol-protected: If every member of the losing tribe is protected by an idol, no elimination occurs that episode. This is rare but mechanically valid.
• Winning tribe idols preserved: Idols held by winning tribe members are not consumed and carry forward to future episodes.

Merge Edge Cases

• Merge on first eligible episode: If the threshold roll is very low and the probability hits 100% immediately, the merge can trigger on the first episode within the window.
• Pre-merge finale: If somehow the merge never triggers before the final 3, the penultimate force condition ensures it fires. On a penultimate 4-player episode this is also when the final-four fire-making flow (safe pick + fire-making, no vote) replaces the tribal vote.

Sit-Out Conflicts

• All players previously sat out: The no-consecutive-sit-out constraint is relaxed. All players become eligible, and the engine auto-selects required sit-outs randomly.
• Cross-manager conflicts: Since each manager controls their own tribe, sit-out selections never conflict between managers. The engine validates that each tribe's selections are within its own roster.

Living Document

This document describes tribe gameplay mechanics as implemented at the time of writing (May 2026). Game mechanics may evolve with future updates. The definitive source of truth for any mechanic is the engine implementation and its corresponding specification.

Related specifications (the Tribe-based Gameplay Epic, #249):

Non-goals (not covered here, may be added in future updates):

• Mid-pre-merge tribe swaps or player transfers between tribes
• Tribe-specific challenge specialties or asymmetric challenges
• New advantage types beyond hidden immunity idols