# Hospital Campaign Design Research This research survey collects insights for an **educational, investigation-focused hospital RPG**. We treat the hospital as a self-contained immersive-simulation world, designing a 3-act narrative with 12 major scenarios (plus incidents, social activities, mysteries, and multiple endings). Our approach blends **scenario-based learning** and immersive game design: players explore, investigate evidence, and make social decisions in a realistic hospital environment. This emphasizes analytic skills (evidence provenance, hypotheses, bias awareness) within a rich narrative. Key design influences include scenario-based learning theory, immersive simulation principles, and cooperative multiplayer game design. ## Scenario-Based Learning and Immersive Sim Design We frame each mission as a *scenario-based learning* activity: students (players) navigate an interactive narrative, applying knowledge and problem-solving in context. Scenario-based learning (SBL) is a proven active-learning strategy: learners progress through a storyline and must use critical thinking to resolve realistic problems. In our design, the hospital setting provides a **realistic context** (e.g. medical terminology, routines, chains of custody) while the narrative and puzzles teach analytic skills. By making the game **grounded but fictional**, we separate real-world facts from game fiction, citing actual terminology (e.g. “chain of custody”) only to teach concepts, and clearly labeling any real-world references in side-panels. As an *immersive simulation*, the experience emphasizes non-linear exploration and emergent narratives. We embed clues throughout the hospital environment (offices, wards, labs) and allow players to choose how to investigate. This follows the immersive-sim philosophy: the world is rich with interactive systems and information (patient charts, security logs, AI assistants, gossip) and players craft their own approach. Unlike a fixed lecture or training, players can drop in/out and play alone or cooperatively, and the story unfolds dynamically around their actions. For example, minor *dynamic incidents* (power glitches, rumors, schedule changes) happen spontaneously, creating new questions or hints between main scenarios. This mirrors MMORPG design where **drop-in/drop-out support** is critical: when players join or leave, the session adapts without breaking narrative flow. For solo play, AI companions and scenario scaling ensure challenges are fair. We will use story and game systems to encourage cooperation (shared goals, combined clues) while also enabling legitimate disagreement (conflicting motives or interpretations). ## Educational Realism and Analytic Techniques Educational content is woven into the gameplay. We incorporate **structured-analytic techniques** and intelligence concepts under the hood. Players will handle evidence with a simulated **chain of custody** – keeping logs of who handled each document or object – to learn that preserving provenance ensures evidence integrity. In practice, the chain of custody is “the sequential documentation or trail that accounts for the custody, control, transfer, analysis, and disposition of evidence”, which we adapt to hospital documents (e.g. who reviewed a patient chart and when). We also teach **analytic confidence levels**. Players assess how sure they are about a conclusion. In intelligence work, **analytic confidence** is an explicit rating (high/moderate/low) attached to conclusions based on source quality. Our NPCs might say “I’m 80% sure the chart was altered,” using plain words, and players can decide whether to demand more proof or act. High confidence means well-sourced, corroborated information, while low confidence indicates fragmented, poorly corroborated info. Critical thinking is reinforced by highlighting **cognitive biases**. We design situations where personal feelings or assumptions could mislead players. A cognitive bias is “a systematic pattern of deviation from norm or rationality in judgment”. For example, a friendly NPC’s claim might seem believable (authority bias), or players may jump to conclusions based on a single clue (confirmation bias). By exposing biases – e.g. one character tends to lie, another is unreliable – players learn to question their instincts and seek corroboration. In the **deception detection** domain, we train skepticism. Research shows people are only slightly above chance at spotting lies without hard proof. In gameplay, an NPC’s statement alone is never taken as fact; players must seek additional evidence. We emphasize that “detection accuracy tends to hover around chance”. For instance, one scenario might present contradictory testimonies; players learn to cross-check each testimony against independent data (camera logs, medical tests). Misleading clues are always identifiable upon careful analysis (there are *inconsistencies* and *verification paths*). We also highlight open-source intelligence (OSINT) concepts: players gather information from public records (forums on hospital intranet, bulletin boards, news bulletins). In modern intelligence practice, **OSINT** means “the collection, analysis, and dissemination of information that is publicly available and legally accessible”. Our NPCs use or mention social media and news reports, modeling how analysts weigh open-source info. Throughout, every clue and action has **provenance**. We will track who created a note or who was present at an event. Each piece of evidence in the game ledger will list its *source* (NPC, document, sensor) and *chain-of-custody*. This teaches players the real-world importance of evidence provenance: that an item’s trustworthiness depends on documented handling. For example, if a keycard is found, our ledger notes which character last had it; players can then verify that list rather than assume chain breaks. These educational elements will be explicitly debriefed in an “analytic panel” after each major scenario (or in optional codex entries), making clear the structured reasoning used. (Any real-world agency names or tech are explained only in separate labeled panels to avoid confusion.) ## Scenario Structure and Mechanics The campaign is organized in three acts (I: Orientation, II: Conflict, III: Resolution). This classic narrative structure breaks the story into digestible phases with increasing stakes. Each *primary scenario* follows a detailed template: - **Title & Label:** A brief title and a visibility/sensitivity rating (e.g. “Routine Shift”, “Whispered Rumor”). - **Premise:** One-sentence hook (e.g. “An important medical device goes missing just before an operation”). - **Educational Concept:** The analytic or social concept taught (e.g. “Chain of custody”, “Competing hypotheses”). - **Fictional Stakes:** Story stakes (e.g. patient safety, career advancement). - **Player Count & Scaling:** Min/max human players, with AI substitutions. Every scenario notes how it adjusts for 1, 2–4, 5–7, 8–10 players, avoiding any requirement that breaks if someone drops out. For example, NPC task-sharing scales or time limits adjust with player number. - **Starting Trigger:** How the scenario begins (a schedule notification, rumor overheard, alarm). - **Locations & Objects:** Which areas of the hospital are used (ER, labs, offices) and key items (reports, medical tools, logs). - **Characters:** Required NPCs and optional ones. NPC roles include doctors, nurses, technicians, administrators, patients, security, etc. - **Evidence Types:** At least three types (e.g. documents, biological samples, electronic logs, overheard conversation transcripts). Each evidence has **provenance** recorded (who created it, timestamps). - **Hypotheses:** Two or more plausible explanations for the mystery. For example, if medication is missing, one hypothesis is “a patient took it accidentally” vs. “someone deliberately sabotaged the case.” - **Clues:** At least one misleading clue (plausible but false) and one accurate-but-easily-misinterpreted clue. This mirrors realistic investigation: truth can appear contradictory at first. - **Decision Points:** Three+ major choices (e.g. “Confront Nurse A with this info or look for more clues first?”). - **Social Conflict:** A role-play challenge (e.g. convincing a suspicious nurse, mediating an argument). - **Resolutions:** Non-combat outcomes (negotiation, deduction, repurposing resources). We explicitly avoid violent combat. Each scenario has a *failure state*, but failure is **fail-forward**: it unlocks new information, changes relationships, or creates new paths instead of simply “game over.” (This follows the fail-forward standard: failure yields clues or scars.) - **Consequences:** In four categories: - *Personal*: what happens to the player or NPC (reputation, health of relationships, new obligations). - *Instance*: changes to the shared hospital world (e.g. a broken machine stays broken or a rumor spreads). - *Relationships*: how NPCs view each other and the player. - *Economy*: if relevant, inventory or resources gained/used. - **Replay Variation:** Each scenario will allow at least one different outcome branch or variation (e.g. alternate key NPC involvement) to ensure replayability. Branching is carefully designed so that multiple plays reveal different insights or consequences. - **Safety Notes:** Sensitivity advisories if any scenario touches delicate themes (medical issues, mental health, etc.), and how to handle them in-game or in debrief. - **Acceptance Tests:** Specific tests to confirm correct implementation (e.g. “If players present evidence X to NPC Y, NPC Y must respond truthfully according to their reliability rating.”). These guide QA and developers. For example, one scenario might be *“The Disputed Chart”*: a patient’s record shows two conflicting diagnoses. Clues include a forged signature (false lead) and a hidden log entry (hard clue). NPCs have motives (a resident doctor and an AI-assistant). Players choose whom to trust and how to verify: interview staff, inspect audit trails, confront the AI’s logs, etc. At each decision point, wrong turns still yield partial info (e.g. discovering an outdated test result), teaching players to recover from mistakes. We will build families of scenarios around common investigative tropes. Suggested scenario types include: missing objects, contradictory records, rumors affecting behavior, ownership disputes, maintenance failures, altered messages, false accusations, emergency drills with misinformation, hidden trading networks, and characters pursuing release or escape. Each family is grounded in hospital life but avoids any real illegal instructions. For example, an escape-attempt scenario might focus on forging trust and planning, not instructing how to actually bypass security. Between primary scenarios, **dynamic incidents** will occur as one-off events (3–15 minutes each). Examples: a sudden scheduling change, an overheard argument, a lost personal item, a broken coffee machine, a short blackout, an unexpected guest, a rumor at lunch, a queue dispute, etc. These inject urgency or hints: e.g. a staff shortage might temporarily shift roles in an ongoing scenario, creating new duties or revealing new information. These incidents encourage emergent play without derailing the main plot, and always present a choice (e.g. mediate an argument or record it?). ## Multiplayer and Scaling All content is built for 1–10 human players. As **cooperative multiplayer design** principles indicate, we support *drop-in/drop-out* without restarting the scenario. The game should run continuously when someone joins or the host changes, possibly with a brief recap. For example, if a required participant disconnects, AI can fill that role, or the scenario can gracefully skip that perspective (no unreplaceable bottlenecks). We will incorporate AI bots as necessary to balance team size. For solo play, all group-oriented tasks must have an alternate solution (e.g. hacking an AI terminal instead of teamwork). Difficulty and pacing scale: for instance, puzzle timeouts or the number of tasks adjusts with group size so that 10 players aren’t bored and a solo player isn’t overwhelmed. As [Game Wisdom] notes, cooperative games require explicit design for varying player counts. Certain scenarios will *require* cooperation or create natural disagreements. For example, a broken MRI machine might force players to decide on triage priorities or negotiate resource allocation together. Other scenarios might have players working at cross-purposes (e.g. one allied with management, another with patient rights), fostering healthy debate and negotiation. We aim for at least four scenarios that require genuine teamwork to solve, and at least four where players may disagree on the interpretation of evidence (given no immediately obvious answer). Social conflict resolution is built into mission goals, reflecting real-world negotiation rather than violence. ## Evidence and Provenance Ledger We will maintain a campaign-wide **Evidence & Provenance Ledger** (CSV) that catalogs every clue encountered. Each entry includes: evidence ID, description, source NPC or object, timestamp (in UTC per instructions), and authenticity/confidence rating. This enforces our training objective: evidence must be traceable. For example, “Memo 23: Nurse Shulin’s shift report – collected from Nurse Shulin – obtained at 02:15” with chain noting when player found it. This ledger helps both players and designers keep track of who, what, when. ## Dependencies and Branching Scenarios are not strictly linear: a **dependency graph** (scenario-dependency-graph.md) will map how scenarios unlock or influence each other. Some scenarios might require evidence from others, or choices that branch into different subplots. We ensure no single point of failure: if one path fails, players can often approach the issue via alternate scenarios or new incidents. We will track branching outcomes in a **Branching Outcome Matrix** (CSV), listing each scenario’s possible end-states (e.g. “Case solved – director’s trust gained”, “Suspect detained”, etc.). This branching approach makes the campaign replayable: different choices lead to new information and altered institutional status. At least three *long-running mysteries* weave through acts, so evidence from early scenarios can change meaning later. The pacing plan distributes these gradually over ~10 hours of play, ensuring key narrative beats in each act (campaign-pacing-plan.md). ## Deliverables Overview The final deliverables include: - **hospital-campaign-bible.md**: A comprehensive overview of setting, themes, act structure, educational goals, major plotlines, and style guidelines. (This document.) - **primary-scenario-specifications/**: A directory with 12 detailed scenario spec files (one per scenario) following the template above, each fully fleshed out for implementation. - **dynamic-incident-library.md**: A catalog of short incidents (3–15 minute events) with triggers and choice outcomes. - **scenario-dependency-graph.md**: Description or diagram of scenario interconnections (which scenario leads to which). - **evidence-and-provenance-ledger.csv**: CSV listing all evidence items planned across scenarios, with provenance fields. - **branching-outcome-matrix.csv**: CSV mapping each scenario to its possible endings/outcomes and narrative branches. - **player-count-scaling-matrix.csv**: CSV showing how each scenario scales with 1, 2–4, 5–7, 8–10 players (tasks, NPC count, time). - **dialogue-seed-packets.md**: Templates of conversation snippets and dialogue choices for key NPC interactions in each scenario. - **campaign-pacing-plan.md**: Timeline of how scenarios and incidents are arranged (hours 0–2, 2–5, etc) to meet the 8–12 hour first-play target. - **scenario-acceptance-tests.csv**: CSV listing acceptance criteria tests for each scenario (ensuring objectives work, no dead ends, deception is verifiable, etc). Each scenario’s specifications will include **acceptance tests** that check the fail-forward conditions: e.g. verifying that any “failure” still gives a clue or branch. This ensures that no scenario leads only to a dead-end loss. ## Conclusion In summary, the campaign design will marry immersive gameplay with explicit training in investigative and analytic skills. By rooting narrative scenarios in realistic practices (chain-of-custody, confidence assessment, bias awareness) and ensuring rich, branching interactivity, we create an educational RPG that is engaging and replayable. References on scenario-based learning, immersive simulation design, and cooperative game best practices guide our approach. Failure in the game always leads to new knowledge or opportunities, modeling the “fail-forward” philosophy. Ultimately, the players learn to reason like analysts in a complex institution, exploring hypotheses and gathering verified evidence in a safe, interactive hospital environment. **Sources:** Scenario-based learning theory; Chain of custody and evidence handling; Intelligence analytic confidence levels; Cognitive bias definitions; Deception detection research; Cooperative game design (drop-in/out, AI scaling); Immersive simulation game design; *Project Hospital* design insights.