Initial Brainstorming
Notes helped clarify the themes, tone, and major emotional beats. Early ideas were centered on fear, curiosity, and the mundane.
A Night At Home 2.0
Interaction Design & Iterative User Research / 2024 / Writer & Developer
A branching narrative horror game where your choices shape the story and determine your fate.
Project Overview
Developed over 2 months (November–December 2024), A Night at Home is a branching narrative horror game where players decisions shape the story, blending interactive fiction with subtle atmospheric horror.
- Twine + Twison
- HTML/CSS/JS
- Custom JSON Navigation
- Canva for visuals
- Narrative Design & Writing
- UX & Choice Architecture
- Front-end Development
- User Testing & Iteration
Experience the Game
Alone at night in your quiet, empty house, a noise pulls you from your thoughts. Do you brush it off and try to sleep, or let curiosity pull you deeper into the shadows?
Navigate a maze of creeping dread and uneasy choices in this interactive horror experience.
Branching Narrative
Multiple Endings
Atmospheric Horror
Player-Driven Story
Play A Night at Home
Technical Implementation
The development of A Night at Home moved through multiple phases — from story planning to interactive prototyping and finally a custom-coded interface.
Story Planning
Mapped narrative structure and key branching decisions using diagrams and flowcharts. Early visual planning helped define tone and pace.
Interactive Mapping
Built a playable Twine prototype to test narrative logic and player choice flow. Iterated based on usability testing and readability concerns.
Twison Export
Used Twison to convert the Twine story into structured JSON data. This enabled full control over passage rendering and logic.
Front-End Build
Rebuilt the experience using HTML, CSS, and JavaScript. Implemented a custom navigation system, conditional logic, and a responsive layout.
Evolution: Version 1.0 → 2.0
The game started as a simple Twine game. Over time, it transformed into a polished, custom interactive experience.
- Standard Twine UI
- Basic navigation
- Default styling
- Core story only
➞
- Three-page custom structure
- Save system (in progress)
- Improved pacing & visuals
- Atmospheric horror enhancements
Story Mapping
Before any technical implementation, the story structure was carefully mapped across several stages — from loose brainstorming to a full interactive diagram in Twine.
Preliminary Map
This branching diagram laid out key choice points and structural pacing, allowing for early testing of flow and pacing.
Final Twine Map
The final version was fully playable in Twine, showcasing 3 major paths and 5 possible endings. It served as the reference for all future implementation.
Development Process & User Testing
Each phase of development was guided by structured user testing sessions with 5–8 participants recruited from both my personal network and people unfamiliar with the project. Sessions combined direct observation, think-aloud, and written feedback collection — giving me behavioral data, in-the-moment reasoning, and reflective responses to triangulate across.
Early Testing
- Each phase of development was guided by structured user testing sessions with 5–8 participants recruited from both my personal network and people unfamiliar with the project.
- Sessions combined three methods: direct observation, think-aloud protocol, and written feedback collection. This gave me behavioral data, in-the-moment reasoning, and reflective responses to triangulate across.
- After each round, I reviewed session notes to identify recurring patterns before making any changes, treating user testing as a genuine feedback loop rather than a final check.
Later Testing
- In early sessions, I observed where players slowed down, reread passages, or disengaged — often without being able to articulate why.
- Think-aloud data revealed that dense passage lengths were breaking narrative immersion. Players were losing the thread of tension before reaching a choice point.
- Written feedback corroborated this, with multiple participants noting the story felt "slow to get going." These patterns led to two decisions: splitting long passages into shorter beats, and integrating choices within the narrative rather than holding them until the end.
Results & Impact
- A second round focused on pacing at the macro level and genre payoff at the end.
- Thematic analysis of feedback surfaced a consistent feeling that the story's resolution didn't fully deliver on the dread built throughout — players wanted a more consequential "bad" ending. This directly informed the addition of a true bad ending to satisfy horror genre expectations.
- Final sessions validated runtime (~10 minutes per route) and confirmed players felt a sense of agency and investment in replaying to explore alternate paths.
Challenges in Interactive Horror
Building an interactive horror experience required balancing choice architecture with pacing and visual design.
01
Passage Length & Pacing
Managing the length of passages was the key to maintaining flow. Early versions were too dense, so I focused on making each segment digestible and purposeful through iterative testing.
02
Twine to Custom Implementation
The transition to a custom interface using Twison broke some internal logic, forcing me to create a new navigation system and rethink how story data is handled.
03
Custom UI Design
The UI needed to support the tone of the story while staying intuitive. This included integrating save features, responsive layout, and page styles that reflected what's happening on-screen without distracting from the story.
What I Learned
Narrative Architecture
Designing branching narratives taught me how structural decisions: where to place a choice, how much information to withhold all directly shape a player's emotional experience. What started as a writing challenge became a lesson in how information architecture drives user behavior and perception.
Observation vs. Self-Report
Running sessions with both think-aloud observation and written feedback revealed a consistent gap between what players experienced in the moment and what they remembered afterward. Players would narrate confusion or hesitation while playing, then rate the experience in written feedback. That tension taught me to weight behavioral data heavily and treat self-reported feedback as a secondary signal.
Synthesis Over Instinct
The most important shift was learning to sit with raw feedback before acting on it. Early on I'd make changes after a single session. By the second round I was reviewing all notes together first, looking for patterns before drawing conclusions. Resisting the urge to fix the loudest piece of feedback immediately is what turned my user testing into actual research.