SkiSweeper Overview
As a kid of the early‐90s, most of my winter afternoons were spent dodging pixelated trees 🌲 in SkiFree and quietly cursing when a Minesweeper board exploded 💣 on me. Those simple games had surprising staying power, and I wanted to recapture that feeling with a twist. After seeing how other hackathon teams approached their ideas—some looked at real‑world problems like burnout and turned them into predictive dashboards, while others created entirely new genres of games on decentralized infrastructure I realized there was room for a hybrid experience that balanced reflex‑driven fun with brain‑teasing strategy. SkiSweeper was born from that blend of nostalgia and experimentation.
What it does
SkiSweeper fuses two very different classic games into a single seamless experience:
Infinite Ski Mode
You control a skier hurtling down a procedurally generated slope. Ten obstacle types (trees, rocks, stumps, snowboarders, other skiers, booms, ramps, moguls, dogs and lift poles) keep you on your toes. Advanced physics mean rocks launch you into the air at high speed and moguls slow you down while shaking your goggles. Tricks based on rotation and landing angle let you rack up points, and a Yeti periodically gives chase—yes, you can defeat him with a well‑placed boom .
Minesweeper Mode
Colliding with a boom isn’t the end; it teleports you into a persistent 8×8 Minesweeper board. You have three moves to safely uncover numbers (worth their value in points) before you’re booted back to the slopes. Detonating a mine costs 10 points and sends you down the mountain with a singed jacket .
Scoring
Distance equals points, numbers on the board grant extra points, tricks are worth 10–50 points, Yeti kills earn you 10 points, and mines deduct points. A scoreboard tracks your total and your high scores across runs .
The result is an addictive loop: adrenaline‑filled skiing interspersed with moments of quiet, strategic thinking. It evokes the retro charm of Windows 3.11 while adding modern physics, a trick system and two interchangeable themes (classic pixel art and a haunting horror style 👻). You can play forever—until your nerves or the Yeti get the better of you.
How I Used Kiro in SkiSweeper
I used Kiro as my main IDE and “co-pilot” for building SkiSweeper — from initial design to playable prototype. I leaned on its spec-driven features to define major systems (game state, physics, mode transitions, procedural generation, scoring, etc.), then used vibe-coding for small improvements, refinements, and “on the fly” changes. I also used steering rules to lock in project conventions, hooks for automation (tests, docs, scaffolding), and — where helpful — integrated contextual tools via MCP so the agent stayed aware of overall architecture and project constraints.
Vibe Coding — How I Structured Conversations & What Impressed Me
For small improvements, tweaks to gameplay logic, or when I just wanted a quick scaffold (e.g., adding a new feature, minor refactor, or a new module), I’d pop into Kiro’s chat and issue prompts like:
“Add a module for trick-based scoring: define a function that,
given jump height and landing speed, returns a score bonus;
integrate it into existing scoring manager.”
Kiro would generate the module skeleton, inject the new scoring logic, hook it into the existing score-calculation flow, and often stub out tests or type definitions immediately.
The most impressive moment: I asked for a full scaffold for procedural slope + obstacle generation — including code to place rocks, trees, ramps, moguls, with constraints to avoid impossible clusters. In one go, Kiro produced:
- generation logic
- basic collision data structures
- integration into the game loop
- placeholders for config constants
That saved hours of boilerplate and let me iterate on design in minutes.
Vibe-coding gave me speed and flexibility — perfect when experimenting or prototyping without disrupting the larger architecture.
📄 Spec-Driven Development — My Approach & How It Helped (vs. Vibe)
From day one, I started with spec mode. I created:
requirements.md
- user stories & game features
- skiing controls, slope generation
- “boom → minesweeper” mode switch
- scoring rules
- UI themes
design.md
- architecture overview
- engine core
- controllers (ski, minesweeper)
- models (skier, obstacles, minesweeper board)
- managers (scoring, audio, asset loading)
- generators (slope + board)
- data flow & interactions
tasks.md
- physics engine
- collision detection
- slope generator
- mode-switch logic
- scoring manager
- UI + rendering
- minesweeper logic
- tests
Spec-driven flow forced clarity: fewer surprises, clearer module boundaries, and one “source of truth.” While slower up front, coding became faster, cleaner, and more maintainable.
Agent Hooks — Workflows I Automated & Why They Helped
I set up several Kiro hooks to automate repetitive or error-prone work:
- On new/modified controller or game-mode module: auto-generate unit-test stubs.
- On save of major modules: auto-refresh documentation stubs to keep docs aligned.
These hooks removed overhead so I could stay in creative flow rather than maintenance mode.
Steering Docs — How I Used Them & Why They Mattered
Right after creating the repo, I ran the steering-setup flow and wrote files reflecting project constraints and style:
structure.md
- folder layout:
engine/,controllers/,models/,managers/,generators/,assets/,tests/ - naming conventions
- module responsibilities
tech.md
- stack choices: vanilla JS + ES modules
- HTML5 Canvas rendering
- Web Audio API
- vitest + fast-check for testing
product.md
- game vision
- core mechanics
- scoring rules
- themes (classic / spooky)
Because steering is persistent, every generated module automatically matched my conventions — no need to restate preferences each time.
Summary — Kiro’s Role in SkiSweeper (Spec First, Then Vibe)
- Spec-driven phase: defined structure, systems, tasks — a roadmap before coding.
- Steering + MCP: enforced conventions and architectural consistency.
- Agent hooks: automated tests, docs, and consistency checks.
- Vibe-coding phase: fast iteration for tweaks, small features, and experiments.
Together, this hybrid workflow let me build a playable, modular, maintainable SkiSweeper prototype far faster — without sacrificing code quality or future extensibility.
Try it here https://skisweeper.com/
Top comments (0)