Systems & Game Design
- Designed the shared team economy and its redesign after testing
- Helped design enemy types and wave structure, including the core theme
- Part of the original group that expanded the vacuum into the core mechanic
Chaotic Co-Op Third-Person Shooter
A computer is infected and you are the antivirus. Up to four players shoot waves of malware, vacuum up the data they drop, and deposit it to restore the system. The same data buys your upgrades, so every run is a loud argument about spending. Built by 6 of us over an 8-month Sheridan capstone, now on Steam and still in development.
The Work: I designed our shared economy (one team progress bar that is also the wallet) and programmed the shop that sells from it.
Why / How: Testing proved the concept created more frustration than teamwork. Players said things like "why would I repair the firewall if it's easier to kill them inside?" So we scrapped my original design and rebuilt it. That cycle is the actual skill I'm showing here: expand a system, prototype it, test it, and when the data says it fails, redesign it without ego. One playtest group still ignored the win condition and pushed to wave 43 for fun, so we knew the loop underneath was worth saving.
The Work: I set up the networking groundwork the whole game runs on: server setup, sessions, player joining, and Steam integration.
Why / How: A co-op game that desyncs is dead, and a showcase build that needs the venue's wifi is asking for pain. For Level Up Toronto I designed and programmed the LAN systems so four strangers could join a match instantly with zero internet. Unglamorous work, but it's why our booth ran all day without a restart.
The Work: I helped design the enemy types and wave structure, built on the theme that every enemy is malware you might actually recognize.
Why / How: The basic swarmer is named after the real ILOVEYOU virus. The Popup Bug flies through walls and slaps an ad over your screen mid-fight unless you catch it first. Waves mix these behaviors so the team constantly re-prioritizes: who clears the swarm, who guards the base, who deals with the thing covering their screen.
The Work: The vacuum-gun started as a team idea. I was part of the original group that expanded it from "collect loot" into the mechanic everything else hangs off.
Why / How: The same tool that hoovers up data also pulls teammates out of danger, yanks enemies off the base, and launches whatever is stuck on the nozzle. One input, a pile of emergent plays. Enemy designs were built backwards from it: each type answers "what does the vacuum do to this?" before anything else.
The Work: I handled builds, publishing, and every push to Steam, plus the online media and marketing around the page.
Why / How: A student game that ships beats a brilliant one that doesn't. Keeping a real Steam pipeline alive meant playtesters got keys like a real release, showcases ran on stable builds, and the page collected 179 wishlists before the capstone term even ended.
My economy concept didn't survive contact with players. Redesigning it instead of defending it made the game better and made me a better designer.
Because networking and Steam plumbing existed early, the designers (me included) could test ideas with real online playtesters instead of guessing.
Builds, store pages, keys, marketing. None of it is glamorous and all of it is why people outside our classroom have played the game.