Hearsay

Hearsay uses CockroachDB as a living memory layer, enabling NPCs to remember encounters, spread rumors, and evolve relationships, so every conversation reshapes the game world.

Comment

Hearsay

The truth is what survives the telling.

Inspiration

Most game NPCs forget you as soon as a conversation ends. Even when modern AI characters can recall previous dialogue, their memories are usually isolated notes without a reliable understanding of who said what, how information spread, or which version of a story they currently believe.

We wanted to explore a bigger idea: What if a database could act as the long-term social memory of an entire game world?

That question became Hearsay, a game where information is a weapon, memory is world state, and reputation is the consequence. Instead of using CockroachDB only for accounts or save files, we use it to give NPCs durable, individual memories that can spread, mutate, conflict, and ultimately influence the outcome of the game.

What it does

Hearsay is a browser-based social-memory game set in Greyhaven, a living 2D town of twenty residents.

The player arrives as a stranger and has three days to win a mayoral election. During those days, they make promises, negotiate favors, reveal information, challenge powerful residents, and decide which statements should become public.

Every NPC remembers the world differently. A private conversation belongs to the NPC who heard it, while a public statement can enter the town’s shared memory and travel from person to person. As rumors spread, their wording and meaning can change. Those memories affect trust, dialogue, endorsements, relationships, and votes.

At election night, the result is calculated from the memories and relationships each resident accumulated. The game can show the exact remembered claims that influenced decisive voters, not simply say that the player gained or lost “reputation.”

How we built it

We built Hearsay as a full-stack browser game with a Next.js and React frontend, a FastAPI simulation backend, and CockroachDB Cloud as the authoritative world and memory store.

CockroachDB stores:

  • Individual NPC memories
  • Shared town memories
  • Immutable belief versions
  • Rumor transmission history
  • Relationships and promises
  • Conversations and world events
  • NPC schedules and locations
  • Election votes and their decisive inputs

Each memory belongs to a specific holder. When an NPC hears a new version of a rumor, we preserve the earlier versions and create a provenance-linked record of the retelling. This produces a traceable family tree showing who said what, who heard it, and how the information changed.

We use CockroachDB vector search with locally generated BGE embeddings to retrieve memories relevant to the current NPC and conversation. Relational reranking then considers factors such as the memory holder, source, recency, confidence, and relationship context.

Serializable transactions keep the active belief coherent when conflicting updates arrive concurrently, while retaining both histories. The game renderer never owns the world state: conversations, memories, schedules, weather, and election progress survive a refresh because CockroachDB remains the source of truth.

We also implemented a constrained Amazon Bedrock integration for character dialogue, rumor retelling, and bounded autonomous decisions, with validated structured outputs and a deterministic fallback for reliable local play. The Town Historian provides an auditable way to reconstruct memory lineage and explain how a remembered statement affected the game.

Challenges we ran into

The hardest challenge was making memory feel like gameplay rather than hidden infrastructure. It was not enough for an NPC to say, “I remember you.” A memory needed to produce a visible consequence: changed dialogue, a damaged relationship, a new rumor bubble, an endorsement, or a different vote.

We also had to balance emergence with consistency. AI-generated dialogue can vary, but promises, relationships, belief ownership, rumor lineage, and election outcomes must remain structured and explainable. We solved this by letting models shape language and bounded choices while deterministic game rules control consequential state transitions.

Concurrent belief updates created another challenge. Two NPCs can report conflicting versions of the same event at nearly the same time. We needed to preserve both accounts without leaving the character with two contradictory “active” beliefs. CockroachDB’s serializable transactions and retry behavior allowed us to keep one coherent active state without losing provenance.

Finally, we had to prevent the project from becoming a dashboard or a collection of chatbots. Building a walkable pixel-art town, readable objectives, visible NPC schedules, storms, public arguments, rumor bubbles, and a complete election arc was essential to making the memory system feel like part of a real game.

Accomplishments that we're proud of

We are especially proud that Hearsay treats CockroachDB as a core game mechanic not interchangeable backend storage.

The current experience includes a three-day, eighteen-action campaign with twenty approachable residents, free-form conversations, private and public memory scopes, multi-hop rumors, persistent relationships, autonomous NPC behavior, and an explainable twenty-voter election.

We also built a complete player-action-to-consequence loop:

The player makes a promise → an NPC remembers it → the information spreads → another resident changes their behavior → the memory influences the election → the game reveals the exact belief version responsible.

Memories, rumor hops, conversations, schedules, weather events, and election evidence survive application refreshes and backend reconstruction. We also verified real concurrent updates and holder-scoped vector recall against CockroachDB Cloud.

Most importantly, the finished experience demonstrates a broader use case: CockroachDB can power persistent NPC memory for games in which many characters and eventually many players continuously influence the same evolving world.

What we learned

We learned that believable NPC memory requires much more than storing conversation transcripts. A useful game memory needs ownership, meaning, confidence, source history, visibility, and a connection to gameplay consequences.

We also learned that semantic retrieval and transactional state should not be treated as unrelated systems. An NPC’s recalled memory must agree with the character’s current beliefs, relationships, and decisions. Keeping vectors, belief versions, provenance, and active state together makes the world easier to reason about and audit.

Most of all, we learned that explainability can strengthen game design. Showing players why someone distrusts them or which rumor cost them an election turns technical provenance into strategy, mystery, and emotional payoff.

What's next for Hearsay

Next, we want to expand Greyhaven beyond a single election campaign into a persistent social world where NPC relationships and town history develop across multiple visits.

Planned directions include:

  • Longer campaigns with multiple political and personal storylines
  • More autonomous NPC-to-NPC conversations
  • Cross-player town history through a shared Town Ledger
  • New towns with different factions, cultures, and rumor dynamics
  • Tools for developers to author characters, beliefs, and social scenarios
  • Deeper forensic queries through the Town Historian
  • Persistent multiplayer worlds where many players influence the same NPC society

Our larger goal is to turn Hearsay into a reference architecture for memory-driven game characters: NPCs who do not merely remember the player, but remember and reshape the society around them.

Built With

Share this project:

Updates