I Built a Deckbuilder Game Engine with Kiro: From Specs to "Slay the Spire"

#kiro #gamedev #typescript #ai

🃏 The Dream: Building "Chambers"

Like many developers, I’ve always been fascinated by the mechanics behind games like Slay the Spire. The synergy between cards, the economy of a shop, and the tension of a reshuffle—it’s a beautiful system. But from a coding perspective, it’s a nightmare of state management.

How do you handle a Discard Pile shuffling into a Draw Pile mid-turn without losing data? How do you ensure "Damage" is calculated correctly through 5 layers of status effects?

I decided to build Chambers, a survival deckbuilder. But instead of slogging through spaghetti code, I used Kiro, an agentic IDE, to architect the system for me. Here is how Kiro changed my development process from "guessing" to "architecting."

🏗️ Phase 1: The "Spec-First" Approach

Usually, when working with AI, we just start chatting: "Write me a card script." This often leads to disjointed code. With Kiro, I used Spec-Driven Development (SDD).

I didn't write code first. I wrote rules.

Inside the .kiro/ directory, I created a "Source of Truth" for my game logic. I described the Deck lifecycle in natural language:

Spec Excerpt:
"When the Draw action is requested, checking if the Draw Pile is empty. If so, shuffle the Discard Pile, move it to the Draw Pile, and then complete the draw. Ensure no card objects are duplicated or lost during the transfer."

Kiro read this spec and generated a robust TypeScript framework. It didn't just write a script; it built a system that adhered strictly to my rules. This meant my core game logic was decoupled from the game engine—pure, testable code.

🤖 Phase 2: Kiro as a QA Engineer (MCP & TDD)

This is where Kiro shined. I didn't want to debug shuffle logic inside the Unity Editor (which is slow). I wanted to verify the math instantly.

Using Agent Hooks and MCP (Model Context Protocol), I set up a "Self-Healing" workflow:

Kiro implements a feature (e.g., Shop.buyCard()).
Kiro automatically triggers npm test via the terminal.
If the test fails, Kiro reads the error log, analyzes the stack trace, and refactors the code immediately.
If the test passes, it moves to the next task.

It felt like pair-programming with a Senior Engineer who loves writing unit tests. By the time I opened Unity, I knew my logic was 100% bug-free.

🧠 Phase 3: The Hybrid Architecture (Node.js + Unity)

One of the hardest parts of this project was preventing "Language Contamination." I needed Kiro to write TypeScript for the logic and C# for the Unity frontend.

I leveraged Steering to give Kiro a split personality:

The Brain (Framework): "You are a Node.js architect. You do not know Unity exists. Focus on pure data structures."
The Body (Unity): "You are a Unity developer. You do not calculate damage. You only visualize the state provided by the framework."

This separation of concerns prevented the dreaded "Spaghetti Code" where UI logic mixes with game rules.

🌊 Phase 4: Vibe Coding the Polish

Once the hard math was done via Specs, I switched to Vibe Coding for the visuals. This was the fun part.

I chatted with Kiro to tweak the "feel" of the game:

"Make the cards hover when the mouse is over them."
"Add a particle effect when an enemy takes damage."

Because the logic was already solid, we could iterate on the visuals rapidly without breaking the game loop.

🚀 The Result

Chambers is now live and playable. It features a fully functional battle loop, a shop economy, and a robust deck-building system.

What I learned:
AI isn't just for writing boilerplate. If you use tools like Kiro to define Specs and enforce Tests, you can build complex, architectural software that is actually maintainable.