The Whisperer

Social media simulation · Unity 6000.0.34f1 · Web (demo)

My Role

Technical Game Designer (Systems Designer focus)
Sole in-engine developer; teammates contributed narrative content for posts.

Project At a Glance

Play as an anonymous social media user during a fictionalized version of Iran's 2022 protests. Scroll a feed of incoming content, decide what to amplify, then choose platform, tags, caption, and timing, each choice shifts the balance between engagement and surveillance risk.

Play Now

Project Information

Type: Course project (OCAD University, Digital Futures)
Genre: Social media simulation, turn-based narrative strategy
Engine: Unity 6000.0.34f1
Platform: Web (demo); target was Mobile
Team size: 3 (I handled all in-engine implementation)
Duration: 7 weeks

Raw Documents

What I Built

My Contributions

I handled all in-engine implementation and authored all 420 tag/caption entries. Teammates contributed narrative content for posts.

Built the core data pipeline: a ScriptableObject-based post structure paired with a CSV-backed dictionary for tag/caption lookup, so I could author and tune content outside the engine without touching code.
Implemented the 6-step posting flow (feed, post detail, platform, tags, caption, confirm), with each step reading from and writing to a shared post object independently. Touch-friendly navigation included.
Designed the risk/engagement formula: platform multipliers, tag stacking, time-of-day curves. Different combinations produce noticeably different outcomes in reach and surveillance risk.
Built the day/hour cycle and post lifecycle: posts spawn, accumulate engagement and risk over time, and feed into end-of-day summaries that generate next-morning consequences.
Created daily summary and morning report screens to close the feedback loop, showing per-post results and triggering events like surveillance warnings or account flags.

Key Design & Tech Challenges

Building a consequence-driven system that respects its subject matter

Problem: the game has 4 decision axes (platform, tags, caption, timing) that all need to produce meaningfully different outcomes. And because the subject is Iran's 2022 protests, those outcomes can't just be score optimization: high engagement has to come with real risk, with no safe "win" path.
What I did:
- Gave each platform a distinct risk/reach profile (WhatsUp = high risk, high reach; TeleM = low risk, niche audience). Tags stack additively, each carrying its own engagement and risk values by style. Time-of-day curves make morning posts safer but lower-reach.
- Constrained the risk/engagement formula so the two always correlate, there is no high-reach, low-risk path. This wasn't just a balance choice; the subject demands that amplifying protest content always carries consequence.
- Made consequences emergent, not scripted: the daily summary generates next-day events (surveillance warnings, shadowbans, account flags) based on accumulated risk thresholds, not hand-authored story beats.
- Built feedback screens showing per-post engagement results and the events they triggered, so players can connect choices to outcomes even though the loop is indirect.
Why it mattered: without differentiated, honest consequences, the game either feels like a spreadsheet or trivializes a real tragedy. The system had to make choices feel meaningfully different and make the stakes feel earned.

Inside the Project

Systems, decisions, and how things actually worked.

Project: The Whisperer (course project, OCAD University Digital Futures)
Genre: Social media simulation, Turn-based narrative strategy
Platform: Web (demo); target was Mobile
Engine: Unity 6000.0.34f1
Primary input: Touch-first (mouse supported for Web demo)
Team: 3
Duration: 7 weeks
My role: Systems Designer, sole in-engine developer
Shipped: Prototype playable to Day 5, endings not implemented
Content scale: 7 content directions × 3 styles × ~20 instances = 420 tag/caption entries; 4 fictional platforms
Play time: 3–4 minutes

Brief

The Whisperer is a posting-simulation game set during a fictional version of Iran's 2022 "Woman, Life, Freedom" protests. The core idea: players scroll a feed of incoming protest content, decide which posts to amplify, then choose platform, tags, caption, and timing: each choice shifts the balance between engagement (reach, followers) and risk (surveillance, bans).

Gameplay Goals

A clear decision loop: every post has 4 axes (platform, tags, caption, timing), and each axis should produce noticeably different outcomes.
Readable feedback: players should be able to see which posts drove their risk and engagement, and reason about their approach, instead of just watching numbers change.
A short but complete arc: 5 in-game days, with escalating consequences leading to multiple endings.

Personal Goals

Push myself into data-driven architecture: ScriptableObjects for content, dictionaries for lookup, no hardcoded strings.
Learn to handle sensitive real-world subject matter in a game context without being exploitative.
Ship a vertical slice that demonstrates systems design thinking, not just "I made a game."

Production Constraints

7 weeks, no extensions.
Team of 3, but only 1 Unity-capable member (me). Teammates contributed narrative content for posts, but no in-engine work or content authoring for tags/captions.
Personal circumstances during development limited my available hours in the production period.

Things We Deliberately Cut

Day 6 and endings: The narrative was designed for 6 days with multiple endings based on cumulative risk/engagement. Day 6 and all endings were cut due to time.
Ban explanation UI: Players get banned, but the prototype doesn't show which post triggered it. Cut for scope.
Platform-specific mechanics: Early designs had each platform with unique rules (e.g., WhatsUp = disappearing posts, TeleM = group channels). Simplified to just risk/reach profiles.
Mobile optimization: Touch gestures work, but no performance pass for actual mobile deployment.

Game Loop Flowchart (Click to expand)

Systems I Owned

PostData ScriptableObject: Core data structure for each post: content direction, base engagement/risk, applied tags, caption, platform, timestamp.
TagCaptionDictionary: Query system organized by ContentDirection → Style → instances.
PostingFlowManager + UIM_TagCaption: 6-step posting flow with step transitions, panel switching, and selection logic (max 3 tags, max 1 caption).
SwipeHandler: Touch-friendly feed navigation.
TimeManager: Day/hour progression, drives hourly evaluation cycles.
FeedManager: Post lifecycle - spawning, engagement decay, risk accumulation, world event triggers.
Risk/Engagement Formula: Platform multipliers, tag stacking, time-of-day curves. Engagement factors include content direction, platform multipliers, tags/caption values, and timing. Risk factors include content direction, tags/caption values, source platform, and timing.
MorningReportUI / DailySummaryUI: End-of-day feedback showing how each post contributed to outcomes.

Key Decisions I Pushed

Use ScriptableObjects + a dictionary lookup instead of hardcoded content arrays - this let me author content without touching code.
Treat tags as stackable modifiers with per-style engagement and risk values, not cosmetic labels.
Deep-copy the ScriptableObject template when a posting flow starts, work on that copy through all steps, and destroy it on cancel. Keeps authoring templates clean between flows.

Technical Breakdown - Post Flowchart

Traceable consequences across a 4-axis posting flow

Why it was hard

Players make 4 layered choices per post: platform, tags, caption, timing. Each combination needs to produce different outcomes in engagement and risk, and players need to trace those outcomes back to the choices they made. A flat lookup table can't do that. The pipeline has to accumulate choices across steps, let each step modify a shared object on its own, and feed the result into formulas that produce outputs a player can actually reason about.

What made it hard

The core data object had to work as both an authoring template and a runtime instance that accumulates player choices across 6 flow steps. If that boundary is wrong, every system downstream breaks.
420 tag/caption entries across 7 content directions × 3 styles, each with its own engagement and risk values. I needed a way to author all of that in the Inspector without writing code, and have UI scripts query it at runtime by direction + style.
Tags stack additively (max 3), caption is exclusive (max 1), and each selection modifies the shared post object directly. The UI had to enforce limits, support deselection, and handle players backing up to a previous step without corrupting the accumulated data.

What I did

Separated authoring templates from runtime instances: each posting flow deep-copies the template on start, works on that copy through all 6 steps, and hands it off to the feed system on completion. Cancel destroys it. No cross-contamination.
Built a dictionary-based query system with a CSV import/export pipeline: I export an empty template, fill in entries in a spreadsheet, then import them back. This let me author all 420 entries outside the engine, organized by content direction and style. UI scripts pull from it at runtime without knowing how the content is structured underneath.
Made the 6-step posting flow modular: each step reads from and writes to the same post object, but knows nothing about the other steps. Adding or removing a step doesn't break anything else.
Built the daily summary as both a feedback screen and an event generator: it shows per-post engagement totals (likes, shares, follower change), then uses the day's posts and player risk level to generate next-day consequences (surveillance, warnings, account restrictions) and forwards them to the morning report.

Result

Players in playtests could connect their choices to what happened: they saw which posts gained traction, which ones pushed risk up, and the next morning they got events like surveillance warnings or account flags tied to their risk level. The feedback loop was indirect, not a per-decision breakdown, but it gave players enough to reason about their approach.

On the authoring side, I could add new content directions or tune formulas without the two touching each other's code.

Week 1–2: Research

Read documentation on the 2022 protests, studied platform mechanics: how real social media handles virality and censorship. Defined the 7 content directions based on documented protest information tactics.

Week 3: Core Architecture

Spent a good chunk of this phase on architecture planning, making sure the system was modular and data-driven from the start. Then built PostData ScriptableObject, basic UI scaffolding, and the first version of the posting flow. Formula was still placeholder.

Process work: Brainstorm Board

Week 4: Dictionary + Selection Logic

Built TagCaptionDictionary and its entry structure. Started authoring tag/caption content myself. Implemented UIM_TagCaption with toggle behavior and slot limits (max 3 tags, max 1 caption). Played The New York Times Simulator around this time, which helped validate the decision-loop structure I was building.

Week 5: Feed + Time Systems

Integrated FeedManager and TimeManager. Posts now spawn, decay, and accumulate risk over time. First playable day loop working.

Week 6: Content Population + Feedback Screens

Finished authoring all tag/caption entries. Built MorningReportUI and DailySummaryUI. Playtested with classmates; feedback was positive on the decision tension, negative on clarity ("why did I get banned?").

Week 7: Polish + Presentation

Web build for demo. Touch gestures working. Cut Day 6 and endings due to time. Presented to class, instructor praised the systems thinking and encouraged the team to continue.

Results

Shipped a prototype playable to Day 5, with all content entries populated, 4 platforms, and a working risk/engagement loop. Web build for presentation. Instructor praised the systems thinking and encouraged the team to continue.

Takeaways

Data-driven architecture pays off: The ScriptableObject + dictionary setup meant I could author content without touching code, and tune formulas without content changes.
Sensitive subjects need intentional design: Abstraction, consequence-first framing, and no win state helped keep the game respectful.
Feedback is everything: The DailySummaryUI was a late addition, but it transformed the game from "random numbers" to "traceable decisions."

If I Did It Again...

I would involve domain experts (in this case, Iranian friends with lived experience) earlier in system design, not just narrative fact-checking. Most of my systems work was based on secondary research; having direct input while designing platform risk profiles or surveillance escalation could have caught blind spots sooner.
I would commit to solo development from the start for a project this systems-heavy, or establish clearer content handoff points with teammates much earlier.
The posting system + time cycle formed the core interaction framework. Once that worked, everything else (content, feedback screens, events) slotted in easily. If I continued this project, I'd want to explore how far that framework could extend to other "consequence-driven posting" concepts.