Super Market
City
← Portfolio
Overview
I worked as a senior game designer on Super Market City from the early concept through to the Alpha release, and carried product management responsibilities alongside the design work throughout.
The role covered a wide span: creating features and gameplay elements, tweaking and tuning them, and playtesting the content I built. Across the project I was responsible for several distinct systems at once — the customer system, the social features, the core gameplay elements, and level creation — which meant moving between designing something new and refining something already in the game depending on what the build needed.
On the product side I tracked milestone progress, managed scope, and made sure the features I owned hit their quality bar on schedule through to Alpha.
What I Was Aiming For
A World That Feels Believable
The building properties, customer properties, waypoint system, and camera system are easy to overlook in a management game — but they're what makes the world feel alive. Customers that move believably through the space, a camera that frames the action well, a store that reacts plausibly to what the player builds: those are the things that make a simulation worth playing.
Features Designed Deliberately
For each feature I developed multiple concepts at every stage rather than locking onto the first idea, so we could compare directions and choose deliberately. That process is what separates a feature that works from one that happens to be built — the same time spent, but with the design risk removed before production starts.
Corner Cases Handled
In a simulation game, unusual situations will eventually happen. I spent real time designing solutions for the edge cases — the rare but possible states a player can reach — because those are what break the illusion if they go unhandled. Most players never notice this work, which is exactly the point.
How It Came Together
The early work started with research. I studied other games in the genre to understand what worked, what players expected, and where there was room to do something better — the groundwork that keeps a new design grounded rather than guessing. From there I created the game design document and supporting systems documentation, and built a basic prototype to finalise the core gameplay before the team committed to production. I also worked closely with the artist to finalise the look of the game, so design and art were pulling in the same direction from the start.
In production I moved from designing on paper to building in the engine. I created and finalised the gameplay elements directly, then built out the customer system — the properties and behaviours that govern how customers respond to the store, the products, and the player's decisions. The customer system is the feedback loop the whole simulation runs on: get it wrong and every other feature loses its meaning.
I built the waypoint system that governs how customers move through the store space, and the camera system that frames all of it for the player. Both are infrastructure-level work — invisible when they're right, immediately noticeable when they're wrong. Alongside this I designed and implemented the social features, which extend the simulation beyond the player's own store and give the game its longer-term engagement hook.
I tuned the game world continuously against stakeholder feedback, adjusting as their notes came in. I worked on the animation systems and the stats-based simulation underneath — the numbers that decide whether a store thrives or struggles — making sure the tuning produced a curve that was readable and satisfying rather than opaque. I also created and iterated on the game levels as the build developed.
As QA tested the build I fixed the bugs they surfaced and designed solutions for the corner cases — the unusual situations a player will eventually reach even when they're rare. Managing the QA pipeline for my features was part of the PM work: prioritising fixes, tracking what was blocking Alpha, and making sure nothing I owned held up the wider build.
What I Owned
The customer system, social features, core gameplay elements, level creation, building and customer properties, waypoint system, and camera system — each taken from concept through to Alpha. Plus the product management work that ran alongside it: genre research and design documentation at the start, milestone tracking and scope management through production, and QA pipeline ownership through to Alpha release.
Design Outcomes
- All owned features delivered to Alpha on schedule
- Customer simulation felt believable and responsive
- Waypoint and camera systems stable and invisible — working as intended
- Social features extended retention beyond the core loop
- Edge cases handled before Alpha — no simulation-breaking bugs in owned features
Outcome
A simulation that worked end to end, delivered from concept to Alpha across a wide spread of features.
The deliberate design process — multiple concepts developed before anything was committed to production, grounded by genre research at the start — meant the features that went into the build were the right ones, not just the first ones.
Running both design and product management across the same features meant nothing got lost between the two. Design decisions had product context from the start, and the PM work was informed by a designer's understanding of what actually mattered — which is what kept the features coherent and the timeline honest.