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?
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:
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.
The entire experience is built around a single idea:
Without active, painful prioritization, every system eventually degrades into noise.
Play the Game: Memory Drift
Source Code:
"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 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:
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.
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.
Every day, characters ask for help.
Important details are automatically stored inside the Memory Bank.
At night:
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?"
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.
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:
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.
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.
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.
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:
The save system validates stored schemas before restoring progress, preventing corrupted saves from breaking the game.
The original prototype contained:
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:
made every storyline feel intentional.
Average playtime dropped to roughly 3 minutes.
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.
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.
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:
to communicate interactivity more clearly.
Visual decay is central to the game's theme.
However, blurred text creates accessibility problems.
To balance theme and readability:
Narrative games often suffer from interaction fatigue.
Removing unnecessary continuation clicks significantly improved pacing while preserving narrative tension.
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.
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.
Visual corruption is mechanically important but not universally readable.
A dedicated accessibility layer would replace blur effects with symbolic degradation while preserving gameplay semantics.
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.