Our deliverable was a comprehensive concept package rather than a playable prototype. We presented a complete vision of what Cosmic Catch could be: a meditative fishing experience where players learn the rhythms of different cosmic fish, building their collection while enjoying an ambient soundtrack.

The package included fully realized art assets — our mermaid protagonist, three unique fish designs with animation poses, the space moon pool environment, and a complete UI system. We also delivered three original "fish fight" music tracks with percussion and vocals, plus ambient background music. The judges saw not just an idea, but a world ready to be built.

Our initial brainstorm landed on a tight concept: rhythm-based fishing with a star theme. We scoped it small on purpose. But passion has a way of expanding scope — one teammate's enthusiasm for adding a collection system was hard to resist, and suddenly we had two interconnected systems instead of one focused mechanic.

With four hours left and programming hitting unfamiliar technical walls, I had to make a call. I assessed where we actually were versus where we hoped to be, and redirected the team's energy. Instead of forcing a broken prototype, we would highlight everything that was done and present a polished concept. We focused on what we had — incredible art, cohesive direction, original music — rather than scrambling to ship buggy mechanics.

That pivot meant packaging our vision in a way judges could understand and get excited about. The result was a presentation that showed not just what we made, but what Cosmic Catch could become — and that vision won Most Innovative.

Cosmic Catch won the Most Innovative award at the Create-A-Thon — a recognition that a polished partial vision, presented with confidence, can outperform a buggy "complete" prototype.

Sometimes you can pick your team, and sometimes you can't. This jam taught me that either way, understanding your teammates' actual capabilities before scoping is essential. We asked our programmer to tackle unfamiliar systems without fully understanding the learning curve involved. Going forward, I'd interview teammates about their comfort zones and experience levels before committing to technical scope.

Establish your bare minimum first — the smallest version that proves the concept works — then layer on features. We tried to build both the rhythm system and collection system simultaneously, and ended up with neither. A working rhythm demo with placeholder art would have been stronger than beautiful art with no mechanics.

A polished partial vision can still win. Knowing when to pivot from "ship the prototype" to "sell the concept" is its own skill. Sometimes the best project management decision is recognizing what you actually have and presenting it with confidence.