A browser-based detective game where players question AI characters and piece together a case in their own order.
The design challenge: keep an open-ended investigation understandable when both the player's route and the conversation can change.
What I delivered
A playable website, from investigation structure and interface design to character rules and implementation. The main investigation is designed to be readable; the hidden ending is an optional, more demanding route.
01 / The experience
Players enter as a detective investigating a death. Conversations, records, and clues on external websites offer different ways into the same case.
Conversation
Private chats let players question characters through free-form input. Each character's prompt defines a voice and the information they are allowed to share.
Cross-reference
A character's trail extends to a profile on X. Players investigate outside the case interface and bring their interpretation back into the story.
02 / Investigation flow
The core loop is to question, inspect, and connect evidence. Players can revisit records and characters as new information opens another route.
Investigation loop · high-level structure
An incident report establishes the player's role and the mystery.
Choose between conversations, member files, calls, and diaries.
Cross-reference records and follow clues onto the web.
Use discoveries to access more records and revisit characters.
Different paths resolve the case differently; closer attention to connected clues can open an optional hidden route.
New information sends the player back to earlier conversations and records.
Opened from an ending screen in this recording, the story map shows revealed and locked branches. It offers a view of the routes through the case after an outcome has been reached.
Information architecture
Chat, the member registry, and the mission board occupy separate routes. The player can return to the same record structure as the case grows.
State feedback
Locked records, available files, member status, and counters distinguish what is known from what still needs investigation.
Two exploratory exercises informed the direction: people could form different interpretations from the same fragments and inspect clues in their own order. These exercises informed the concept; they did not validate the final game's usability.
03 / AI interaction design
Free-form conversation needs limits. I defined character personalities, knowledge boundaries, and responses to off-topic input, then connected those behaviors to the investigation.
A boundary in the working build
The chat history records repeated weather questions and Lily's warnings. The recording then shows the disconnected chat and the “Revoked” ending.
01 / Character
Each character has a separate prompt for tone and conversational style. Midnight, for example, is calm and controlled, with a deliberate sense of distance.
02 / Knowledge
Rules distinguish acknowledging another member from revealing their private file. These instructions guide responses; they do not guarantee that the model will never reveal too much.
03 / Off-script input
Off-topic questions, challenges to the administrator, and questions about the AI have defined response rules. Repeated probing can become a story consequence, as the recording shows.
Illustrative exchange · not a playtest transcript
Built with Claude Code and the ChatGPT API. My design work covered the characters, response boundaries, interface states, and the relationship between conversation and progression.
04 / Playtesting & iteration
The hidden ending asks players to pay closer attention to clues and connections across the story. Discovering this layer is part of the challenge; universal completion was never the goal.
Two of the eight players reached the hidden ending. I treat this as an observation of discovery in this group. It provides a starting point for examining how players explore the optional layer, but does not establish the ideal level of difficulty or determine the game's overall usability.
01 / Entry
The text-heavy opening left testers unclear about who they were and why they were investigating.
02 / Conversation
Players challenged the fiction; keyword-based replies repeated themselves and made characters feel artificial.
03 / Discovery
Two of the eight players reached the hidden ending. This is an observation of discovery in this group, not proof that the difficulty is right or wrong.
A plain chatroom and member list provided an early way to explore the interaction. Testing exposed the need to establish a role and a reason to investigate before asking players to start a conversation.
05 / From Figma to a working website
The high-fidelity designs established the visual language. Working with real content made navigation, locked records, and changing member states part of the design work.
Navigation
Chat, the registry, and the mission board moved into their own routes when a single stacked view became too dense.
Interaction states
Locked and unlocked records, plus alive and deceased member states, needed recognizable treatments beyond the default screen.
Language
Character rules were maintained in both languages. Supporting the same intent requires more than translating the interface labels.
Visual system / a readable digital archive
Pixel display type establishes the fiction; monospace body text gives records a consistent rhythm.
Dark surfaces and light text frame the evidence, with red accents for status and alerts.
Repeated headers, folders, status tags, and counters help players recognize new information.
What I take forward
My next evaluation would examine whether the main investigation remains understandable, whether hidden-route clues can be reasoned through, and whether navigation and record states provide enough feedback without revealing the answer.