Type: Game Design
Role: Lead Designer, Programmer & Artist
Duration: 1 Semester
Tools: GameMaker, Adobe Photoshop, Figma
Role: Lead Designer, Programmer & Artist
Duration: 1 Semester
Tools: GameMaker, Adobe Photoshop, Figma
A simple murder-mystery game where you play as a detective exploring a crime scene at a hotel.
NO ONE LEAVES UNTIL YOU CRACK THE CASE...
INTRO — The ASK
"Who Dun It?" is a top-down murder mystery game where players navigate the floors of a mysterious hotel using a limited move set, interacting with clues and NPCs to uncover the culprit of a murder. The information gathered throughout the game is stored in a notebook, which the player uses to make a final guess about the killer at the end of the three standard levels. The gameplay combines interactive storytelling with timing and memorization, requiring players to carefully choose which clues to interact with and retain the information given to them in order to solve the mystery.
This was a group project, but I was the only person on the team with a real background in both art and programming. That meant I was responsible for filtering what ideas were actually feasible at our scale, implementing the levels in GameMaker, creating every piece of pixel art in the final product, and composing the soundtrack. A huge inspiration for the game — both in terms of aesthetic and engine — was Undertale. Its use of GameMaker, its pixel art style, and the way it weaves story into every single interaction rather than front-loading it into a cutscene were all things we actively studied and tried to pull from. It set the bar for what a small team could pull off with limited resources, and it proved that a compelling narrative and a simple visual language could carry a game further than technical complexity ever could.
I also scheduled and ran a dedicated story session with my teammate Asha where we mapped out the entire narrative web — characters, motivations, suspects, red herrings — in a single hour-long call. That session was the backbone of everything that came after it.
CONTENT — Deliverables
Development began with a very basic single-level build in GameMaker, focused almost entirely on getting the player's move set and grid-based mechanics to feel right. Players could move the character around the room, pick up a key, and exit through a staircase. Simple as that. The point was never to build something impressive early — it was to make sure the foundation was solid before anything else got stacked on top of it.
The game was originally designed as a time-based challenge, but we pivoted pretty quickly to a system where the player is given a set number of moves per level instead. That single change completely reframed the design philosophy of the whole game. Suddenly every decision had weight to it. Do you spend moves chasing a clue that might not be worth it, or do you cut your losses and head for the exit? Players who run out of moves before finishing a level can choose to stay and keep searching, but the killer enters the floor the moment the counter hits zero and will chase them until they decide to move on. That push and pull between wanting more information and knowing when to leave ended up being the core tension driving the whole experience.
Level Design & Mapping
Once the move set system was locked in, I mapped out all three standard levels plus a tutorial level in Figma before touching GameMaker. Working in Figma first let me experiment freely with clue placement, obstacle positioning, and entry and exit points without the overhead of actually coding anything. More importantly, it let me count moves — I could trace the most likely paths a player would take through a room and make sure the allotted moves were tight enough to create pressure without tipping into unfair territory. Rather than trying to plan the entire game at once, we took a level-by-level approach that kept each floor focused and stopped the scope from spiraling.
Grid sizes grew over time as new mechanics came online. Early builds had smaller rooms that started feeling cramped once the killer mechanic was introduced, so layouts were opened up to give everything more room to breathe. Some levels, like the pool area, went through significant redesigns after playtesting revealed that the entry and exit points weren't clear enough and that clue locations were harder to find than intended.
ART DIRECTION & VISUAL LANGUAGE
The aesthetic was a deliberate choice that drew heavily from Undertale's approach to pixel art (pictured below) keeping things simple, readable, and tonally consistent rather than chasing visual complexity. The plan early on was to have more colorful and detailed environments, but time constraints pushed us toward a black-and-white style with hints of red reserved for anything important or striking. That constraint ended up suiting the tone better than the original direction would have. The monochrome palette gives the game a kind of quiet dread that a busier visual style probably would have diluted.
Every piece of pixel art in the final product — characters, furniture, environmental objects, UI elements — was made by me in Photoshop. Working within a limited palette made individual decisions faster and kept everything visually cohesive across all three levels. The soundtrack was also my work, designed to sit underneath the gameplay without overpowering the tension the move system was already generating.
NARRATIVE & DIALOGUE
The story needed to do a lot of heavy lifting. Because the whole game builds toward one final guess, every clue and every NPC interaction had to be purposeful — vague enough to keep the player second-guessing themselves, but specific enough that the correct answer feels earned rather than arbitrary. Asha and I worked out the full character web in one focused call: the victim, the suspects, what each of them was hiding, and how the evidence would be distributed across the three levels to lead a careful player toward the right conclusion.
From there, I wrote the dialogue for every interactable object and character in the game. Some clues are more valuable than others, which gives players who explore thoroughly an advantage and gives the game real replay value — a second playthrough hits differently once you know who did it and can trace exactly how the story was telegraphing it the whole time. A lot of outside playtesting had to happen beyond the in-class sessions to make sure the room designs and the clues and dialogue were tuned to the point where the mystery felt solvable without feeling obvious.
PLAYTESTING & FEEDBACK
The playtest build was the first version with all five areas playable: the intro, three standard floors, and the final guessing scene, along with a title screen and story introduction. We ran a live session with UM alumni and other students — gave them a brief intro, let them run a full playthrough, and had them fill out a feedback form after. The session surfaced some real problems. Instructions weren't clear enough. The killer's behavior was confusing. And in one particularly telling moment, a player correctly guessed the killer and had no idea they'd won, because the correct and incorrect guess sound effects were identical and there was no visible victory cue whatsoever. That last one was a good reminder that feedback clarity is just as important as the feedback itself — you can design a perfect mystery and still lose the player at the finish line if the game doesn't communicate the outcome properly.
The three biggest post-playtest changes were a pop-up notification alerting players when the killer enters their level, enhanced visual indicators on entrances and exits, and improved NPC positioning alongside a suspect dossier to help players keep track of information without having to memorize everything on the fly. Instructional pop-ups were limited to the intro and first level so that the guidance didn't overstay its welcome — the goal was always to get players oriented quickly and then let them figure things out on their own terms.
CLOSURE — Reflection
Working as the de facto lead on a team project taught me a lot about filtering ideas under pressure. When everyone is excited and throwing concepts at the wall, the hardest skill isn't generating ideas — it's knowing which ones actually serve the game and which ones are going to eat your timeline without adding much. I got a lot of practice making those calls quickly and explaining the reasoning behind them in a way the team could get behind. Communication and task delegation were things we all had to actively work on throughout the semester, and while there's still room to grow there, the improvement was real and noticeable by the end.
On the technical side, this project pushed my GameMaker skills further than any previous assignment had. Implementing the killer's movement in particular was a challenge — the original concept had the killer advancing two spaces for every one move the player made, which proved both too difficult to code at our level and too punishing for the player to deal with. We landed on a linear movement approach instead, which actually ended up adding a different kind of urgency to the late-game even if it lost the cat-and-mouse dynamic we originally wanted. Learning to adapt a concept to fit technical constraints without losing what made the concept interesting in the first place is something I think about a lot more carefully now.
The part of this project I'm most proud of isn't any individual asset or mechanic. It's the fact that it holds together as a complete thing. The story connects to the levels, the levels connect to the art, the art connects to the tone, and the tone connects back to the story. Getting all of those pieces to feel like one cohesive game — built by a group of people with very different skill sets and varying levels of familiarity with the tools — required a lot of quiet decision-making that never shows up in the final product but absolutely shows up in the absence of it when it isn't there.
This was my first time building a game from scratch with a team, and looking back, the experience fundamentally changed how I think about the relationship between design constraints and creative output. The tighter the constraints, the more deliberate every decision has to be — and deliberate decisions, more often than not, produce better work than total creative freedom does. The bones of this game are solid. There's something real in here, and given more time and a longer runway, I know exactly where it goes next.