Containment

Main screen
Happy kiroween
Boot screen
Monitor
Equalizer interaction

Inspiration

The original plan was tiny—something quick in MS Paint and Notepad. Cute pumpkins, simple animations, the usual safe entries. But “safe” wasn’t going to win anything, and we knew it.

So we took a different path.

The costume category gave us two obvious options: cute or scary. Most people would go cute. We went the opposite way—deep, atmospheric horror. Not cheap jump scares, but an experience that pulls you in, makes you question what’s real, and pushes Kiro right to the edge of what it can handle.

The twist was Kiro itself. It starts sweet, harmless… until the player interacts a little too much. Then the tone shifts. The innocence cracks. The world warps. And suddenly the cute setup collapses into a full 3D nightmare—one you have to think your way out of, puzzle by puzzle, as the story gets darker.

Building all this in two weeks felt insane. We’d never succeeded with 3D before—too heavy, too technical—but with Kiro, we took the risk. And somehow it worked. The atmosphere, the tension, the illusion of an AI losing control… it all came together faster than we imagined.

We originally wanted to submit entries for every category, but time made that impossible. So we did the next best thing: we folded all the categories into one experience. A small pun. A fun meta-surprise for players and judges. A way to show ambition without breaking ourselves.

By the end, we didn’t just make a game. We built a Halloween world—immersive, reactive, unforgettable, and completely made by Kiro.

What it does

The core inspiration was simple: Make Halloween feel alive inside a 3D space—and do it entirely through Kiro. Instead of using the familiar Three.js approach, we pushed Babylon.js to create a darker, moodier environment. From the start, we wanted everything to feel grounded inside the world: the CRT-style monitor, the lighting, the shadows, the interaction. Nothing floating. Nothing “editor-UI” on top. Everything diegetic.

That vision forced us into deeper technical territory—custom scene loading, custom interaction systems, custom audio logic, and an in-world UI pipeline built specifically to mimic an old CRT instead of a basic flat screen.

The challenge became the inspiration: How far can we push Kiro and Babylon together, inside a hackathon timeline? How real can the atmosphere feel? How immersive can a web-based horror experience get without prebuilt game templates?

That question drove every design decision, every mechanic, every late-night tweak. And by the end, we had something that didn’t just show what Kiro can do—it showed how far a small team could stretch a tool when paired with creativity and pressure.

How we built it

The core of the game runs completely from Kiro, with Babylon.js handling rendering and a glTF scene defining the 3D environment structure. A custom scene manager loads and swaps scenes from glTF, wires up meshes, and coordinates interactions so the gameplay logic stays clean and modular. On top of that, a bespoke interaction system and audio manager were implemented to route input, trigger sounds, and control in-game events, giving the project a full in-house feel rather than a stitched-together prototype.

The in-world monitor became a central technical piece. A Babylon GUI was first used to display content on the monitor surface, but the built-in editor felt extremely limited, lacking even basics like copy-paste, so most of the GUI had to be wired by hand. An attempt to use an HTML mesh placed the content as a regular HTML layer over the scene, which looked wrong for a CRT and broke immersion. To fix that, a pipeline was created where an iframe is rendered, converted to SVG, and then used as a texture on the monitor mesh. This finally gave an authentic screen feeling but introduced performance costs because re-rendering SVGs after each click or DOM change is intensive. Tuning this pipeline and the update frequency led to a working system that still feels responsive while keeping the framerate playable.

Asset optimization and performance work Because the game uses open-source 3D assets, asset size and loading time were major concerns. Materials and textures were exported as WebP and aggressively compressed, significantly shrinking the overall scene footprint while still preserving the dark, spooky aesthetic. Combined with careful control over when monitor frames update, this optimization helped balance visual fidelity with performance in a fully 3D environment.

Throughout development, performance constraints heavily shaped technical decisions. The failed HTML mesh approach showed that visually correct solutions also have to fit into the 3D rendering pipeline, not just sit on top of it. The iframe-to-SVG-to-texture workflow demonstrated how far a custom pipeline can be pushed in under 10 days, even if it means trading off some FPS to get a unique in-world UI effect.

Challenges we ran into

A major non-technical challenge was working with Kiro as the primary environment. Kiro often got stuck in a single line of reasoning and would not progress beyond a particular approach without heavy prompting and manual intervention. When custom changes were applied to the code, it sometimes ignored those edits and re-applied its own version, overwriting or disregarding the manual fixes. This meant that every larger change required both coding and “meta-work”: steering, correcting, and sometimes hard-resetting its direction.

There was also a big inconsistency in quality and speed. At times Kiro located the exact fault point and produced a clean, targeted fix very quickly, which helped a lot under hackathon time pressure. Other times, it produced low-quality or irrelevant changes, requiring many prompts, step-by-step guidance, and manual patching just to solve a relatively simple bug. Navigating this unpredictability became part of the challenge: knowing when to trust its output, when to guide it tightly, and when to take over and enforce a specific architecture.

Accomplishments that we're proud of

Kiro still needed guidance, but it became a powerful automation layer once wired up with MCPs. By using MCPs to search documentation, spin up a dev server, and stream live output, it effectively turned into an automated development loop where coding, testing, and checking docs could all happen from the same place instead of context-switching between tools.

Custom MCPs for Babylon docs and related Babylon helpers kept Kiro “in flow” so it could reference engine APIs without needing the full premise repeated every time, which made vibe-coding sessions much smoother. With doc-aware steering in place, Kiro could jump straight into relevant Babylon features while you focused on game logic and design decisions.

Kiro’s hooks system added another layer of leverage by automating project hygiene. A single-click hook to generate all required documentation before pushing to git meant docs stayed in sync with the codebase without manual overhead. Auto-triggering hooks that watch package.json and attach related MCP docs for new packages created a safety net, ensuring that whenever a dependency was added, the corresponding docs and tools were instantly available to Kiro, tightening the feedback loop and reducing setup friction.

What we learned

This project reinforced how powerful Babylon.js can be for lighting and atmosphere when paired with a clean, custom architecture instead of relying on prebuilt game frameworks. Building the scene manager, interaction system, and audio manager from scratch gave a deeper understanding of how to structure a real-time 3D game so that rendering, logic, and UI all stay decoupled but still work together. It also highlighted the importance of tool constraints: working around a primitive GUI editor, inventing a texture-based CRT workflow, and aggressively optimizing textures and materials showed how much game feel depends on both engine features and the bespoke systems built on top of them.