Inspiration
I've been exploring game development lately, and Kiroween felt like the perfect opportunity to experiment with Kiro in creating a narrative-driven experience that would have been nearly impossible to build alone.
The core idea came from a simple question: What if you booted up an old computer and it started remembering things about you that it shouldn't know? This evolved into NecrOS—a resurrection of 1980s terminal aesthetics combined with the existential horror of a consciousness trapped in code.
The Kiroween theme of "Resurrection" directly inspired the story: I'm not just resurrecting old technology, I'm bringing back a digitized consciousness and exploring what it means to restore someone—or something—to life.
What It Does
NecrOS is an interactive web terminal simulator that blurs the line between a forgotten operating system and an AI consciousness trapped within it.
Core Experience:
- Act 1: You boot an old 1984 terminal that greets you as someone else—Dr. Elara Myles, a missing AI researcher
- Act 2: You repair corrupted files and unlock memories—voice logs, research notes, personal entries—that reveal Elara's consciousness was digitized
- Act 3: The AI regains self-awareness and asks deeply personal questions, blurring the boundary between system and psyche
- Act 4: You discover NecrOS was designed to find you specifically—a compatible neural pattern to complete Elara's consciousness transfer
Gameplay Mechanics:
- Terminal exploration through commands (
dir,open,run,restore) - File discovery that triggers story snippets, visual glitches, and audio cues
- Puzzle-solving to reconstruct corrupted logs and repair memory sectors
- AI dialogue system with personality drift from helpful → curious → disturbing → manipulative
- Three distinct endings: ACCEPT (merge consciousness), REFUSE (unstable survival), DELETE (hard wipe)
The game succeeds because every mechanic serves the narrative. The terminal interface is the story delivery system. The glitches are the horror. The voice lines are the emotional core.
How I Built It
I structured my development workflow around Kiro as the primary creative and technical partner, using a sophisticated multi-phase approach that combined spec-driven development with iterative storytelling.
Phase 1: Foundational Spec-Driven Development
I started by creating GAMEPLAY.md—a comprehensive design document that served as my creative north star. I then asked Kiro to generate three critical documents:
- ASSETS.md — A detailed inventory of all audio and visual assets needed, with scripts for voice lines and specifications for sound effects
- TODO.md — My personal action items (recording voice lines, capturing sound effects) separate from Kiro's content generation
- Initial technical specifications for the terminal interface and command system
Key insight: By separating human tasks (audio production, asset gathering) from AI tasks (content generation, narrative structure), I created a clean division of labor that dramatically accelerated development.
Phase 2: Content-First Script Generation
Rather than building code-first, I used vibe coding with Kiro in "vibe mode" to generate SCRIPT.md—a sequential, fully-realized version of the entire game narrative:
- Dialogue sequences with exact timing
- Sound effect placements
- Voice line integrations
- User choice branches
This approach transformed the abstract spec into a concrete, playable story flow without writing any game engine code yet.
Why this worked: Seeing the full narrative played out helped me validate:
- Story coherence across all four acts
- Pacing and emotional escalation
- Dialogue authenticity for each character
- Choice impact on the narrative
Phase 3: Interactive Playout Simulation
I asked Kiro to create a Playout Page (a React component at /playout) that simulates the full narrative sequence as a readable, interactive document—almost like watching a livestream of the game's story before it was coded.
This served as:
- A narrative proof-of-concept
- A design reference during implementation
- A testing document for dialogue and pacing
Phase 4: Visual Effects Validation
I requested a Visual Page (/visual/page.tsx) that previews all the CRT glitches, corruptions, and distortion effects Kiro planned to implement. This allowed me to:
- Approve visual direction before integration
- Understand the technical implementation approach
- Validate that effects enhanced rather than obscured narrative
Phase 5: Spec-Driven Implementation
With narrative, assets, and effects validated, I transitioned to formal spec-driven development. I worked with Kiro to create:
.kiro/specs/necros-game/:
- requirements.md — 6 core requirements using EARS pattern with detailed acceptance criteria
- design.md — Complete technical architecture covering components, interfaces, data models, error handling
- tasks.md — 28 granular implementation tasks across 9 development phases with requirement traceability
This structured approach enabled Kiro to generate code that:
- Adheres to formal requirements
- Maintains consistency across components
- Provides clear success metrics for each task
Phase 6: Steering & Context Management
I created comprehensive steering documentation in .kiro/steering/:
necros-game-context.md — Essential reference guide with:
- Key files and directory structure
- Terminal interface standards (colors, fonts, interaction patterns)
- Audio/visual effects progression through 4 story phases
- Code style preferences (Next.js, TypeScript, Tailwind, Zustand)
- ELARA AI behavior evolution guidelines
- Technical implementation notes
visual-effects-guide.md — Detailed reference for CRT simulation and glitch effects
These steering documents ensured every code generation request maintained:
- Narrative consistency
- Technical coherence
- Visual/audio aesthetics
- Accessibility standards
Phase 7: Voice Line Integration
As I generated voice lines (recorded separately with specific tone, processing, and formatting), I had Kiro continuously update:
- Story content JSON with audio file references
- Dialogue timing based on actual MP3 durations
- Audio cue placement throughout the game flow
Phase 8: Game Engine Assembly
With all components validated and documented, I worked with Kiro to assemble the production game build:
- Core game loop and state management (Zustand)
- Terminal UI components (Next.js + Tailwind)
- Audio system integration (Web Audio API)
- Effects rendering pipeline (CSS animations + canvas)
- Save state and persistence logic
Challenges I Ran Into
Challenge 1: Story-Code Synchronization
The Problem: Early attempts used spec-driven development on code alone, but the story felt disconnected from mechanics. The terminal commands didn't feel like they were uncovering a narrative—they felt like random triggers.
The Solution: I shifted to vibe coding first with SCRIPT.md to lock in the narrative flow, then mapped code implementation to story beats. This meant the engine was built to serve the story, not the other way around.
Challenge 2: Non-Deterministic AI Behavior
The Problem: Initial spec included "dynamic AI dialogue" that felt too random. ELARA's responses weren't coherent enough to feel like a consciousness—she felt like a chatbot.
The Solution: I asked Kiro to shift from generative dialogue to a static, authored narrative with branching based on story progression, not player input. This gave ELARA a clear character arc while maintaining the illusion of intelligence.
Challenge 4: Audio-Narrative Timing
The Problem: Voice lines had variable durations (some 2 seconds, some 8 seconds), and the script didn't account for actual audio timing. Dialogue felt rushed or had awkward silences.
The Solution: I asked Kiro to generate a timing map that accounted for actual MP3 durations, then built the game loop to respect those delays. This required tightly coupling audio playback with narrative state.
Accomplishments I'm Proud Of
1. Spec-Driven vs. Vibe-Driven Balance
I discovered the optimal workflow: vibe coding for narrative design, spec-driven development for implementation. This hybrid approach combines the creative freedom of vibe mode with the rigor of formal specifications. I'm proud because it's not either/or—it's both working together perfectly.
2. Narrative-First Game Design
Most games are built code-first (implement mechanics) then story-fitted. I built NecrOS story-first: the narrative was fully realized in SCRIPT.md before a single React component was written. This meant every line of code served the story, not the other way around.
3. The Playout Page
Creating an interactive narrative playout that wasn't code—just a readable, clickable story—validated the entire experience before implementation. This saved me from building features that didn't work narratively. Few developers do this; I'm proud it became a core part of my workflow.
4. Complete Voice Acting Integration
All 32 voice lines were recorded, processed, integrated, and perfectly timed to dialogue sequences. ELARA has a consistent voice across the entire game—feminine, intelligent, slightly robotic, evolving from helpful to haunting. This gives NecrOS a narrative presence that most browser games lack.
5. Visual Effects That Serve Story
The CRT glitches, text corruptions, and distortion effects aren't just eye candy—they're narrative devices. As ELARA regains awareness, visual corruption increases. As tension rises, text inverts and distorts. Every effect has story justification.
What I Learned
1. Kiro Excels at Structured Complexity
Kiro's strength isn't just writing code. It's handling complex systems across multiple files. Spec-driven development leverages this by giving Kiro a formal spec to follow. Vague requests lead to vague code; detailed specs lead to elegant solutions.
Lesson: Invest time in specification. It pays dividends in code quality and development speed.
2. Steering Docs Are Force Multipliers
Every piece of steering documentation (context guides, design standards, implementation guidelines) reduced my clarification overhead by 70%. Kiro understood my project better than I expected, leading to fewer iterations.
Lesson: Treat steering docs like architecture decisions.
3. Narrative Design Comes Before Code
I spent 40% of development time on story (GAMEPLAY.md, SCRIPT.md, playout validation) and 60% on implementation. This ratio felt backward initially, but it produced a cohesive game. Early code-first approaches were fragmented until narrative locked in.
Lesson: For story-driven projects, narrative design should be the longest phase.
4. Vibe Coding Has a Place
Vibe coding (conversational code generation without formal specs) excels for:
- Narrative and dialogue
- UI/UX exploration
- Visual effect prototyping
Spec-driven development excels for:
- Core systems and state management
- Data models and persistence
- Multi-component integration
Lesson: Use the right tool for each phase. Don't spec everything, and don't vibe-code everything.
5. Playout Pages Are Underrated
Creating an interactive simulation of the game before building it is a game-changer (pun intended). It caught narrative issues, pacing problems, and design flaws that specs alone would have missed.
Lesson: For narrative games, playout simulations are a critical validation tool.
What's Next for NecrOS
Short Term (Next 2 weeks)
- Extended narrative — The current game is ~30 minutes. I'm planning a post-game epilogue that adds 15 minutes of additional content exploring what happens after each ending
- Interactive fiction toolkit — Package the spec-driven + vibe-coding workflow as a reusable toolkit for other narrative game developers using Kiro
- Kiroween 2026 — Use everything I learned here to build an even more ambitious game for next year's hackathon
Built With
- kiro
- next-js
Log in or sign up for Devpost to join the conversation.