As a relatively small team of 5, I took on the role of project owner and solo programmer for this game. As I often implicitly took the role of lead designer in my previous projects, it was time to make it explicit and take on the role of project owner. This meant I was responsible for the overall vision of the game, every mechanic, system and feature.

As the only programmer I was also responsible for the implementation of all these features, which meant I had to be very careful about the scope of the project and what features I could realistically implement in the 9 week span we were allocated.

I was the lead programmer on this, though it was never an official title. Two of us wrote code, and I owned most of the architecture and committed two to three times as much. I had a playable prototype running by the end of the first day.

I was also the most active person in our design meetings, and a lot of what shipped came out of them, including the dodging fix above.

The rest of my time went to tools. I came in with around seven years of Unity, and none of my teammates had worked in it before, so a lot of what I built was about lowering the barrier for them, even when that meant making something I didn’t need myself. The most useful ones collected data that Unity usually spreads across many objects. The balancing setup kept every design value in one file, so when a teammate flagged an issue mid-playtest, they could find the value behind it without hunting through the scene. I did the same for audio: one list of every sound effect, so our audio person could wire up SFX from one source while I referenced sounds in gameplay before the real clips were hooked up. I also built a one-click deploy so non-technical teammates could push a build to itch without going through me.

Built for Game Design 1 at Uppsala University, where our team had to tell a single short story by making one microgame per story beat, each built individually under a 30-second, no-dialogue limit. This was my beat. I started from Mario Party’s face-reassembling minigame and reframed it as memory loss.

The player rebuilds the old man’s memory of his daughter’s face from floating features, and time fights the effort: each calendar page crumples into a paper ball and flies at her face, jumbling the features further with every hit. It builds faster than the player can fix it, until the screen overwhelms them and her face comes apart for good. The player is meant to lose her, and losing her is the old man’s memory decaying.

Two weeks forced two cuts. The paper balls were a compromise: the pages were meant to fold into origami bats that drained the color from her face as it struck. And reconstruction mistakes were meant to bleed back onto the old man himself, his own face coming apart as hers did, so forgetting her also meant losing himself.