We Shipped 100+ Titles. Here Is What the Winners Had in Common.

Across more than a hundred shipped titles, the games that worked shared three properties: the player did something meaningful within seconds, the loop could be described in one sentence, and the team iterated quickly on real feedback. Budget, art quality, and genre correlated far less than any of those three.

Why this matters

Studios accumulate opinions about what makes games work, and most of those opinions are formed from a small number of memorable projects.

Looking across a portfolio changes the picture, because it includes the ones nobody talks about. The patterns that survive that view are more useful than the ones drawn from a single success.

This post sets out what we look for now, and what we stopped looking for.

How we look at the portfolio

Two things are worth saying about method before any pattern.

First, this is a qualitative read rather than a controlled study. Titles were built in different years, for different clients and publishers, under different market conditions. No portfolio of this kind supports strong causal claims, and treating it as though it does would be misleading.

Second, survivorship affects everything. The titles that succeeded had more effort spent on them afterwards, which makes it hard to separate what caused success from what followed it.

What follows are patterns strong enough to change how we run projects, stated as what we observe rather than as measured effects.

Any studio telling you they have found the formula is describing their most recent success, not their portfolio.

Pattern one: time to first meaningful action

The single most consistent difference is how quickly a new player does something that matters.

In the titles that worked, the player is acting within seconds. No splash sequence, no menu, no account, no tutorial wall. Frequently the game is already in motion when it appears.

In the titles that did not, the same interval is filled with things the team considered necessary: a logo, a settings screen, a permission prompt, an explanation.

This is also the pattern most reliably fixable after the fact. Cutting everything before the first action is usually days of work and it changes the first-day number more than most design changes, per What Happens in the First 30 Seconds.

Pattern two: loop clarity

The games that worked can be described in one sentence, and the sentence contains a loop rather than a mood.

"The player matches tiles to earn coins and spends coins to unlock harder boards" is a loop. "A relaxing puzzle game with a calm atmosphere" is a mood.

Two consequences follow from clarity, and both matter commercially.

• It can be advertised. A loop that fits in a sentence usually fits in three seconds of footage, which is what paid acquisition requires.
• It can be tuned. A clear loop has identifiable levers. An unclear one produces changes nobody can evaluate.

The titles that struggled were frequently the ones where the sentence needed an "and also". That is usually two loops competing, and the fix is choosing one, per The One-Page Game Scope Template.

Pattern three: how fast the team iterated

The third pattern is about process rather than product, and it may be the most important.

Projects that reached a testable build weekly, showed it to people outside the team, and changed things in response consistently ended better than projects that worked in longer cycles toward a larger reveal.

Three mechanisms seem to be at work.

1. More attempts. More cycles means more chances to find what works, per Losing to Faster Teams.
2. Earlier problems. Issues found in week three are cheap; the same issues found in month four are not.
3. Less attachment. Teams that change things weekly hold decisions more loosely, which makes the necessary cuts easier.

This is the pattern we changed most of our own process around, and the practical form it takes is in The 7-Day Prototype.

What did not correlate with success

Worth stating, because these absorb a great deal of attention.

The art budget row is the one that surprises founders most, and it is consistent with the published creative findings in Why Simple Art Outperforms Detailed Art in Paid UA.

What we changed in our process because of it

Four concrete changes, all still in place.

• The first sixty seconds gets its own owner and its own review, every week, whether or not it changed.
• No project starts without the loop sentence written down, and it is revisited whenever the design drifts.
• A device build exists from day one and a testable build ships weekly.
• External testing starts while the game is still ugly, because polish distorts feedback, per Stop Polishing.

None of these are expensive. All of them are process rather than talent, which is the encouraging part.

What we would do

If you are starting a project, spend the first review on time to first action and the loop sentence. Both are cheap to fix early and expensive later.

If you are mid-project and things feel wrong, measure your iteration cycle before changing the design. A team shipping monthly will struggle regardless of the concept.

And be sceptical of pattern claims from any studio, including this one. Portfolios are noisy, survivorship is strong, and the honest version of this post is three things worth checking rather than three things that guarantee anything.

The short version

• Three patterns recur: fast first action, a loop that fits in a sentence, and weekly iteration.
• The first meaningful action should happen within seconds, with nothing in front of it.
• A loop sentence that needs an "and also" usually means two competing loops.
• Iteration speed may matter most, because it produces more attempts and earlier problems.
• Art budget, genre, team size, feature count, and development time correlated weakly.
• Portfolio reads are qualitative and survivorship-affected; treat them as prompts, not proof.

Write your loop sentence and time your first meaningful action this week. If you want a second read on either, tell us about the game.

Related reading: What Is a Core Game Loop, Why Simple Games Win, and Losing to Faster Teams.