Before a single wireframe was drawn, I immersed myself in the Game Design Document to understand Fireflies' world, tone, and mechanics. The GDD defined the game's visual identity — a dark cavern environment built around bioluminescence, vibrant light, and a whimsical-but-tense atmosphere — and I used it as the primary guide for the site's design direction.

From there, me and my team mapped out the three pages the site would need: a game overview page, a case study page documenting the full development process across all teams, and a team credits page. Defining the structure early gave me and my development partner a clear scope to work within, even as content remained unknown.

Wireframing was straightforward, the page structures were clear from the planning stage. The real work happened in the prototype phase, which was by far the longest stage of the project. I built out both desktop and mobile versions in Figma, establishing a component system that could flex around placeholder content without breaking the layout.

The biggest design challenge was the case study page. It needed to tell the story of five separate teams — Game Dev, Design, Web Dev, Social Media, and Motion Graphics — each contributing differently to the same project. I designed a section structure that gave each team equal visual weight while maintaining a clear narrative from concept to product.

Throughout prototyping, we operated on assumptions. I imagined what screenshots, write-ups, and team photos might look like, then designed around those assumptions. When the content eventually came in, very little needed to change structurally as the system we built was solid.

Development followed a mobile-first approach. I worked alongside my development partner to build out each page in HTML, CSS, and JavaScript, with the Figma prototype as our source of reference. We used GitHub for version control and coordinated closely to keep our code consistent across the three pages.

The most active part of development wasn't writing code, it was coordinating content. We had to reach out to every other team on the project, explain what we needed, and guide them toward producing assets that matched the placehoolders we'd already designed. That meant writing clear requirements, following up if needed, and adapting when what came back didn't quite fit. It was as much a production management challenge as a technical one.

On the interactive side, I pushed to include UI details that made the site feel alive such as hover states, animated transitions, and interactive elements on the case study page that let visitors explore each team's contribution at their own pace. This was important as it elavated the user expereince to truly be imemrsed in the Fireflies world.

The finished site lives at dtc-wsuv.org/projects/fireflies and consists of three pages. The Fireflies page introduces the game, it talks about its world, mechanics, and characters. In a way that communicates the tone and ambition of the project to anyone encountering it for the first time. The Case Study page is the one I'm most proud of: it documents each team's contribution and how that came together into a single narrative about how the game was made. The Meet the Minds page closes it out with team credits and individual profiles.

The visual language draws directly from the game's color palette. It includes deep cavern shadows, bioluminescent teals, firefly golds, creating cohesion between the site and the game world it represents. The site was presented publicly at the end of the semester and received strong feedback from faculty and peers, who noted its professional quality and the clarity with which it communicated a complex collaborative project.

We started by researching the medications EMS providers use most frequently — understanding dosage variables, weight-based calculations, and the kinds of errors that happen under pressure. From there, we conducted a competitive analysis of existing medical reference apps, looking at what they got right and where they consistently failed users in time-critical moments.

The most valuable input came from an active EMS professional who served as our field expert. They walked us through their real workflow, flagged features they wished existing tools had, and helped us understand what information is truly essential mid-call versus what can wait. That conversation shaped the entire architecture of the app — especially the decision to make most patient input fields optional for speed.

Before any screens were designed, we established a style guide to anchor every decision. MedicMate uses an EMS-inspired palette of clean blues, a muted medical red, and neutral tones — deliberately low saturation to avoid visual noise in high-stress moments. Red is reserved for critical actions only, so it always reads as meaningful. A dark mode was included for nighttime and low-light operations.

Typography pairs Geologica for headers with Zalando Sans for UI and body text — both selected for geometric readability at small sizes and in poor lighting conditions. Layouts are minimal and hierarchical: one primary action per screen, large tap targets, and no decorative elements that don't serve the user. The goal was an interface that requires zero effort to interpret.

The core flow was designed around a single principle: get out of the paramedic's way. The app opens to a secure login gated to verified EMS organization accounts — once authenticated, the user stays logged in for the rest of the day so re-entry never interrupts a call. From there, the camera launches immediately for fast medication scanning, with a search bar as a fallback.

After scanning, the user enters patient details — weight, age, and any relevant complications. Most fields are optional and can be skipped for a quick calculation or filled in later. A single tap calculates the recommended dose, displayed in large, easy-to-read type. The History page lets paramedics revisit past entries and add notes they didn't have time to enter during the call. A Settings page and account management round out the experience.

Every screen follows a one-decision-deep structure — there's always a clear next step, and the user never has to search for it.

After completing the initial prototype, we ran user testing sessions to observe how people moved through the app. The sessions surfaced real friction points that hadn't been obvious in design — font sizes that were technically readable but too small to scan quickly, color combinations that didn't hold up under different lighting conditions, and flow transitions that added unnecessary steps.

We went back and made targeted adjustments: increasing type sizes across critical screens, refining the color palette for better contrast in both light and dark modes, and streamlining a few interaction patterns that were slowing users down. The result was a tighter, more confident prototype — and one that our EMS expert signed off on as genuinely useful.

The core design goal was a game that felt worth replaying — one where each run felt slightly different and getting a better score felt genuinely satisfying. I landed on a farming game with a time-pressure mechanic: players tend three crop plots, water plants before they decay, and chase off crows that swoop in to steal mature crops. The tension between tending plants and defending them is what makes the loop interesting.

Before writing a single line of code, I mapped out the full game state — what objects existed, how they interacted, and what would change at each difficulty level. Easy, Medium, and Hard alter crow spawn frequency, movement speed, and plant decay timers, giving experienced players a meaningful challenge without changing the core feel of the game.

All visual assets were created from scratch in Clip Studio Paint — the player character, walking animation, three crop types (tomatoes, wheat, carrots) each with three growth stages, crow flying and landed animations, plot tiles, water source, UI elements, and full background and foreground layers. That's over 30 individual sprites, each drawn and exported manually.

The art style is warm and deliberately hand-made — soft pixel edges, a muted garden palette, and character designs that feel cute without being generic. I wanted the game to have a visual identity that was clearly mine, not something that looked like it came from a tutorial asset pack. The player character and crow animations were the most technically involved — each required frame-by-frame sprite sheets and a custom animation system in JS to cycle through them correctly.

The game is built entirely in vanilla HTML, CSS, and JavaScript using a canvas renderer — no frameworks, no game engines. I structured the codebase around a set of ES6 classes: Game, Player, Plot, Plant, Crow, Water, and Overlay, each responsible for its own state and behavior. A central game loop driven by requestAnimationFrame handles all updates and rendering with delta time for frame-rate-independent movement.

The crow system was the most complex piece of engineering. Crows spawn on a difficulty-scaled timer, fly toward a random plot, land, and begin eating a fully grown plant if the player doesn't intervene. The spawn system needed to pause and resume correctly when the game was paused — which required tracking remaining delay time and resuming mid-interval rather than resetting. Plant decay works similarly, using setTimeout chains that suspend during pause and resume with corrected delays.

Sound design was handled with the Web Audio API — each interaction has its own sound effect (watering, crow caw, plant eaten, score tick, game end), with audio cloning to allow overlapping sounds and cleanup on game end to prevent audio leaks.

Players open to a start screen where they choose a difficulty and time limit — 30 to 150 seconds — before dropping into the garden. The goal is simple: keep your crops alive, water them before they decay, and chase off the crows that swoop in to steal mature plants. Every action scores or costs points, and the leaderboard pressure of a ticking clock makes even a 60-second run feel genuinely tense.

The game supports keyboard controls, a pause system with full state preservation, and a restart flow that returns the player to the start screen rather than immediately re-launching — so they can adjust difficulty between runs. The overall feel is exactly what I aimed for: cute, competitive, and satisfying to play more than once.