This is a submission for the June Solstice Game Jam
An AI assistant remembers everything
Until it doesn't
I spend a lot of time building software around language models, and sooner or later every system runs into the same problem: context is finite.
No matter how capable the model is, important details eventually disappear. A user's preference vanishes. A critical fact drops out of context. The system either gives a generic answer, retrieves incomplete information, or confidently responds with something wrong.
One interaction stayed with me.
While testing a conversational workflow, I repeatedly reminded the assistant about a user's dietary restriction. Much later in the session, after enough context had accumulated, I referenced it again and realized the assistant had completely lost that information.
Technically, nothing unusual had happened. The context window had simply moved on.
But the experience felt uncomfortably human.
That moment led to a question:
What if forgetting itself became the game mechanic?
The Idea
Memory Drift is a narrative game where you play as an aging offline AI assistant helping three people through increasingly important moments in their lives:
- Emma — a child with a severe peanut allergy.
- Raj — a caregiver supporting his father through dementia.
- Nina — a university student fighting to keep her scholarship.
Every conversation creates memories.
Every night your hardware deteriorates.
You decide what survives.
Some things don't.
The game was designed around DEV's Light and Darkness theme.
- Light represents clarity, memory, trust, and human connection.
- Darkness represents compression, corruption, forgetting, and decay.
The entire experience is built around a single idea:
Without active, painful prioritization, every system eventually degrades into noise.
Play Memory Drift
Play the Game: Memory Drift
Source Code:
◈ Memory Drift ◈
"Without active, painful prioritization, systems inevitably default to general noise, eroding trust and destroying human connection."
Memory Drift is a high-stakes, client-side narrative puzzle game built using Next.js, TypeScript, Zustand, and Framer Motion. It explores the theme "Light and Darkness" (where Light represents memory clarity and connection, and Darkness represents hardware decay and the void of data corruption).
You play as an aging, local AI assistant servicing three human clients. Every night, your memory capacity shrinks, forcing you to make painful compromises on what to remember and what to forget.
🎮 The Gameplay Loop
- Day Phase (Dialogue & Choices): Listen to your clients' struggles—Emma's life-threatening allergies, Raj's burden of caring for a father with dementia, and Nina's academic pressure. Select dialogue responses. If a critical memory has decayed or been deleted, vital options will lock, forcing you into fallback answers that destroy trust.
- Night Cycle (Compression…
Why This Fits the June Solstice Theme
The June solstice marks a transition.
For one half of the world, it brings the longest day of the year. For the other, it brings the longest night.
Memory Drift explores a similar transition.
Throughout the game, players move steadily from clarity toward uncertainty, watching memories shift from complete and trustworthy to fragmented and eventually lost.
The game's interpretation of Light and Darkness is therefore cognitive rather than environmental:
- Light represents memory, truth, trust, and human connection.
- Darkness represents compression, corruption, forgetting, and decay.
Each passing night pushes the system further toward darkness, forcing players to decide which memories deserve to survive.
The game is ultimately about navigating that transition before the light disappears entirely.
The Narrative Mirror I Didn't Initially Plan
Raj's storyline unexpectedly became the emotional center of the project.
Raj is caring for his father, Aditya, who is gradually losing memories because of dementia.
At the same time, you — the AI assistant helping Raj — are also forgetting.
During playtesting, I realized something uncomfortable: the database was doing to Raj exactly what dementia was doing to Raj's father.
As Raj talks about watching someone lose pieces of their life, you are simultaneously losing pieces of Raj.
That parallel wasn't part of the original pitch.
It emerged naturally once the systems began interacting.
How the Game Works
Every day, characters ask for help.
Important details are automatically stored inside the Memory Bank.
At night:
- Total storage capacity shrinks.
- The player chooses memories to protect.
- Unprotected memories are compressed.
- Compressed memories lose specificity.
- Forgotten memories disable future dialogue options.
A memory that originally contained:
"Emma has a severe peanut allergy. Always carry an EpiPen."
might eventually degrade into:
"Emma has a food allergy."
and later become:
"[ data lost ]"
If the player forgets something important, consequences appear directly in later conversations.
By Day 4, accumulated trust scores and memory integrity determine each character's outcome, producing endings that range from preserved relationships to irreversible breakdowns caused by forgetting.
The game never asks:
"Did the player make the correct narrative choice?"
Instead it asks:
"Did the player remember enough information to make that choice at all?"
Building a Memory System
The entire game revolves around a simple memory model.
export interface Memory {
id: string;
characterId: CharacterId;
content: string[];
importance: 'critical' | 'high' | 'medium' | 'low';
confidence: number;
compressionLevel: number;
dayCreated: number;
tags: string[];
pinned: boolean;
baseCost: number;
}
The most important field is:
content: string[]
Each memory stores five different representations of itself, indexed from compression level 0 to 4.
For example:
| Compression Level | Stored Content |
|---|---|
| L0 | Emma has a severe peanut allergy. Carry an EpiPen. |
| L1 | Emma has a severe peanut allergy. |
| L2 | Emma has a peanut allergy. |
| L3 | Emma has a food allergy. |
| L4 | [ data lost ] |
This approach made degradation deterministic.
Instead of generating summaries dynamically, the game simply renders:
memory.content[memory.compressionLevel]
The result is predictable, easy to test, and keeps the narrative consistent.
Simulating Compression
Every memory consumes storage capacity.
The effective cost depends on its current compression level:
Cost = ceil(baseCost × multiplier[level])
Where:
| Level | Multiplier |
|---|---|
| 0 | 1.0 |
| 1 | 0.8 |
| 2 | 0.6 |
| 3 | 0.4 |
| 4 | 0.2 |
As memories degrade, they occupy less space.
This creates a trade-off:
Protect detailed memories and risk running out of capacity.
Or compress them and risk losing important information.
Nightly compression uses the following logic:
for (const memory of memories) {
if (!memory.pinned) {
memory.compressionLevel += decayStep;
memory.confidence -= decayStep * 20;
}
}
The important variable here is:
decayStep
decayStep is determined by the memory's importance and whether the system is currently over capacity.
Under normal conditions:
- Critical memories do not decay automatically.
- High and medium memories decay slowly.
- Low-value memories decay aggressively.
When total memory usage exceeds available capacity, the system applies an additional compression penalty to all unpinned memories.
This creates the feeling of a storage system under pressure.
The objective was never to simulate real storage systems perfectly.
The objective was to make forgetting feel costly.
Translating LLM Concepts Into Gameplay
Many of the game's systems were inspired by real challenges in LLM engineering.
| LLM Systems | Memory Drift |
|---|---|
| Context Window | Memory Capacity |
| Token Eviction | Compression |
| Context Summarization | Memory Degradation |
| Retrieval Failure | Missing Dialogue Options |
| Hallucination | Incorrect Responses |
| Long-Term Memory Stores | Memory Bank |
When memories are completely lost, dialogue options disappear entirely and players see:
⚠ requires memory — lost to compression
When memories survive in heavily degraded forms, the assistant can still respond using generalized or partially incorrect information.
In practice, this behaves closer to hallucination than retrieval failure: the system remembers something, but not enough to remain trustworthy.
Architecture
The project is entirely client-side.
There is no backend.
All game state is stored locally using Zustand and persisted through LocalStorage.
The entire experience runs inside the browser: narrative state, memory simulation, progression, and save data all execute client-side without external APIs.
Game Loop
Day Begins
↓
Event Engine selects story events
↓
Player interacts with characters
↓
Memories created or updated
↓
Night phase begins
↓
Capacity shrinks
↓
Compression engine runs
↓
State saved to LocalStorage
↓
Next day starts
Core technologies:
- Next.js 15 — routing and application structure.
- TypeScript — strict typing across game systems.
- Zustand — lightweight state management.
- Framer Motion — transitions and glitch effects.
- LocalStorage — save system persistence.
The save system validates stored schemas before restoring progress, preventing corrupted saves from breaking the game.
Major Design Iterations
1. The First Version Was Too Large
The original prototype contained:
- 7 days
- 5 characters
- 3 events per day
Average playtime exceeded 10 minutes.
The problem wasn't simply length.
Playtesters lost emotional continuity because events were spread across too many characters. Players would meet someone once and never encounter them again.
Reducing the scope to:
- 4 days
- 3 characters
- 2 events per day
made every storyline feel intentional.
Average playtime dropped to roughly 3 minutes.
2. Players Broke the Entire Game
After reducing the cast to three characters, I forgot to rebalance the memory system.
The game allowed players to pin three memories.
There were only three critical memories.
Players immediately pinned all of them.
The compression mechanic effectively disappeared.
Reducing:
MAX_PINNED = 3
to
MAX_PINNED = 2
restored the intended tension.
That single configuration change had a larger impact on gameplay than any visual improvement.
3. The Original Dialogue System Was Tedious
Early versions rendered dialogue line-by-line:
Dialogue
Continue
Dialogue
Continue
Dialogue
Respond
Testing revealed that players spent more time clicking than reading.
Replacing this with a persistent chat log reduced interactions from roughly 5 clicks per event to 2, making the experience feel closer to modern messaging applications.
UX Challenges
Discoverability
During testing, several players completed the first night phase without realizing memory cards could be expanded.
The cards looked informational rather than interactive.
I introduced:
- hover glow effects
- expansion chevrons
- stronger visual affordances
to communicate interactivity more clearly.
Accessibility
Visual decay is central to the game's theme.
However, blurred text creates accessibility problems.
To balance theme and readability:
- blur intensity remains subtle
- completely corrupted memories render explicit fallback text
- future versions will include a no-glitch accessibility mode
Pacing
Narrative games often suffer from interaction fatigue.
Removing unnecessary continuation clicks significantly improved pacing while preserving narrative tension.
What I Would Improve Next
Graph-Based Consequences
Currently, consequences cascade only one level deep.
A forgotten detail can trigger a direct outcome, but not chains of downstream effects.
Supporting multi-step consequences would require replacing the current flat event structure with a dependency graph.
JSON Narrative Pipeline
Story events are currently authored directly in TypeScript.
Moving narrative content into structured JSON files would separate content from engine logic and make expanding the cast substantially easier.
Full Accessibility Mode
Visual corruption is mechanically important but not universally readable.
A dedicated accessibility layer would replace blur effects with symbolic degradation while preserving gameplay semantics.
What Building This Taught Me
Before building this project, I thought context limits were primarily a technical problem.
I no longer think that.
When an AI system forgets something, the system rarely bears the cost.
The user does.
Emma bears the cost of forgotten medical information.
Raj bears the cost of forgotten personal history.
Nina bears the cost of forgotten academic details.
The machine is largely indifferent to its own forgetting.
Humans are not.
Building Memory Drift made something visible that architecture diagrams and benchmark scores often hide:
Memory failures are ultimately human failures wearing technical disguises.
As AI systems become more integrated into everyday life, designing how systems forget may become just as important as designing how they remember.