This used a custom shader to render the effect.

Sprint

Sprint

Ball Knockback

Ball Knockback

Inventory System

Inventory System

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.

As lead programmer for this university project, I leveraged 7 years of Unity experience to create a centralized workflow using Scriptable Objects. This approach allowed for easy tweaking of game settings, experimentation with different SO configurations, and iterative testing for rapid development and refinement.

Project Structure

Designing games requires a lot of value tweaking, sometimes to the point of feeling like alchemy, mapping out all the potential mixtures of different values and how they interact with each other. So to be able to try these mixture of value and store them for later review is a must. This led me to go all in with Unity’s Scriptable Objects, so all the game design related values were nested in a single file, making it easy to swap out different submodules for different overall experience and stored on multiple files for later playtesting.

Retrospective

Nesting Scriptable Objects turned out to be more problematic than I anticipated and the reasons were manifold. Since I wanted the ability to combine different modules it meant that each module would represent different portions of the game (Player, Shooting, Enemy, EnemyFromBehind) it both made it difficult to decide what should be a distinct module and what should be a part of another module (see Player and Shooting). I wanted each module variant to have a memorable and descriptive name such as “SprayNPray” for a Shooting variant that shot at a very high frequency, but when you’d make a game mode variant that mixed all of these modules together it would be normal to slightly tweak some of the values so everything would fit well together, but ooops, another game mode was using one of the modules you just tweaked. Having a single file to access all of the values was however a great boon, since variables were no longer spread over different GameObjects and Components and it allowed for making a few game modes that was easy to go between during playtesting.

Tooling

I created a Unity tool that automated the WebGL build and upload process to itch.io, allowing non-technical team members to deploy builds easily. This reduced friction, enabled continuous playtesting, and allowed for fast hotfixes during testing sessions.

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.