Vermin At The Venue

Inspiration

Vermin at the Venue began with a simple question: what would a tower-defense game look like inside a struggling comedy club?

That led to a world where laughter is currency, microphones generate income, rubber chickens hold back attackers, and banana peels break up dangerous groups of vermin. The goal was to combine the strategic satisfaction of tower defense with the playful personality of a live comedy show.

What it does

Players collect Laughs and spend them to defend four lanes leading into the club. Microphones generate additional Laughs, Rubber Chickens attack and block vermin, and Banana Peels temporarily separate tightly packed groups.

The pressure gradually increases from individual Rats to overlapping groups and faster Rush Rats. Three breaches end the show; surviving the complete performance wins the game.

A guided first session teaches the game’s essential economic opening. After a defeat, the Health Inspector provides one short note selected from the player’s actual behavior—such as missing Laughs, neglecting a lane, delaying Microphone collection, over-stacking Chickens, or using Bananas inefficiently. This coaching is deterministic and runs entirely offline.

How I built it

The game was built with HTML, CSS, JavaScript, Three.js, and the Web Audio API. The simulation, input, rendering, audio, configuration, and post-game analysis systems are separated into modular source files.

A custom Node.js build process assembles the game into a readable, unminified index.html while keeping Three.js inside a local vendor directory. A separate submission mode removes development-only testing and tuning controls without changing the game itself.

All characters, environments, interface graphics, effects, music, and sound effects are generated through code. The game does not rely on external images, fonts, audio files, CDNs, or runtime network requests.

I worked iteratively with AI coding assistants, using detailed implementation prompts, structured design decisions, automated regression tests, and repeated human playtests. Failed experiments and rejected designs were recorded rather than erased, making it easier to understand why the final version works the way it does.

Challenges

The hardest challenge was balancing the economy. Microphones needed to feel essential without making victory automatic, while Chickens, Bananas, repairs, and manual Laugh collection still needed to matter.

Responsive presentation was another major challenge. The same portrait game had to remain readable on a phone and in a larger desktop browser without HUD elements shrinking, stretching, covering the battlefield, or leaving the frame.

The guided opening also exposed several timing and state-management problems, including premature wave countdowns and potential soft locks when Laughs were missed. Solving those issues required a clear session-state model and deterministic fail-safes.

Audio introduced its own complications, particularly browser autoplay rules and iOS audio unlocking. Submission packaging added another constraint: everything had to work offline while remaining readable and correctly structured.

Accomplishments I’m Proud Of

I’m especially proud of the mechanic that gives the player a tip at the end of a run. After a defeat, the Health Inspector reviews what actually happened during the session and delivers one concise, behavior-based suggestion. Instead of overwhelming the player with a list of mistakes, it points to the single lesson most likely to help them improve next time.

This mechanic connects the game’s analysis systems directly to its presentation and turns failure into useful feedback. Because the advice is deterministic, offline, and based on real gameplay behavior, it feels specific rather than generic. It also gives the ending of each run a bit of personality while encouraging players to try again with a clearer strategy.

What I learned

I learned that mechanical balance is only part of game feel. Clear onboarding, readable feedback, satisfying animation, sound, pacing, and useful failure messaging can change how fair and enjoyable the same underlying rules feel.

I also learned the value of separating simulation from presentation, testing authoritative behavior instead of duplicating rules, and treating unsuccessful playtests as evidence rather than setbacks.

Most importantly, I learned that concise feedback is often more useful than a full explanation. The Health Inspector mechanic does not list everything a player did wrong—it identifies the single lesson most likely to improve their next attempt.

What’s next

A full version could expand into additional venues with new vermin, comedy-themed defenses, progression systems, performers, challenges, and venue-specific twists while preserving the fast, strategic single-session core.