Cafe Tycoon:
Live Operations
← Portfolio
Overview
I worked as a senior game designer on the live operations of Cafe Tycoon, designing for a game that was already live and being played rather than one still in development.
The role spanned building new features, tweaking gameplay that was already in players' hands, and playtesting content before it went out. Alongside the design work I carried product management responsibilities: tracking what shipped, managing the live content schedule, and making sure the updates we put out were timed well and held their quality bar before they reached players.
Live-ops design leans on reading real player behaviour and responding to it — which is a different muscle from designing a feature in isolation before anyone has touched it.
What I Was Aiming For
A Reason to Come Back
In a tycoon game that lives or dies on return visits, events are what carry that load. Building a solid event system — documented clearly, designed with the right mechanics underneath — was the foundation that every individual live event ran on top of.
Tuning Against Real Behaviour
A live game has data that a development-phase game doesn't. I used player feedback together with the numbers to tune difficulty and progression — reading the full picture rather than reacting to any single data point — and revised features after they shipped when real player behaviour revealed problems the design hadn't anticipated.
Clear Direction Into Production
Getting designs into the game meant directing artists and programmers who implemented them. Clear direction is the difference between a feature that ships matching its intent and one that drifts in production — so I treated the handoff as part of the design work, not a separate step after it.
The Work
The central piece of my live-ops work was the event system. I wrote the feature documentation that gave the team a clear picture of what we were building, detailed the systems design that defined how events would function under the hood, and built the event system itself. As product manager I also scheduled the event cadence and made sure each event went through playtesting before it reached players.
Once content was live, a lot of the work was watching the game and adjusting. I leaned on player feedback together with the numbers to tune difficulty, keeping the game satisfying without tipping into frustration, and adjusted the progression based on the full picture the data showed. I also revised features after they'd shipped — a feature rarely plays out exactly as designed once a large player base is interacting with it, and going back to fix that is part of running a healthy live game.
Alongside maintaining what was already there, I kept designing new features and building progression content, so players always had something new ahead of them. Getting those designs into the game meant directing the artists and programmers who implemented them — turning design intent into clear, buildable direction so the shipped feature matched what I'd set out to make. On the product side, I managed the content schedule so new features landed in a cadence that felt regular to players rather than erratic.
What I Owned
The event system end to end — documentation, systems design, and build. Ongoing tuning of difficulty and progression against live player data. Feature revision post-ship. New feature design and progression content. Direction of artists and programmers through implementation. On the product side: live content scheduling, update quality management, and production tracking across the live-ops cycle.
Live-Ops Outcomes
- Event system gave players a recurring reason to return
- Difficulty tuning reduced friction without removing challenge
- Progression rebalancing improved engagement across the player base
- Post-ship revisions fixed behaviour gaps real players exposed
- New features kept the content horizon moving forward
- Consistent update cadence maintained player expectations
Outcome
A live game that kept improving because the design and product work ran in step.
The event system gave the game a structural hook for return visits that individual content updates could hang off. The data-driven tuning meant changes were targeted at real friction rather than guessed at. And managing both the design and the product side meant the work that got designed also got scheduled, directed, and shipped — without the gaps that open up when those two roles aren't talking.
Live operations is the phase where a lot of games stop improving. The discipline is treating the live game as something still being designed, not something finished.