Jun 4, 2026 · 6 min read · GameMantra Team

From core-first to event-first: how mobile design changed

The center of gravity in mobile design has shifted from the core loop to the event calendar. Here is what that changes about how games are built.

For most of mobile gaming's history, the core loop was the answer to the question "what is this game?" A studio designed the moment-to-moment activity, polished it until it felt good, and built progression and content around it. Live events, when they existed, were add-ons — bonus content layered on top of a game that already worked without them.

In 2026 that framing has inverted. Industry coverage of top-grossing mobile games increasingly describes them as event-first: the event calendar is the primary design surface, and the core loop is the durable substrate that supports it. A new mobile game launching today without a planned year of events isn't shipping an incomplete game — it's shipping a game whose monetisation and retention model doesn't match how the market currently works.

This isn't a marginal shift in emphasis. It changes which decisions get made first, who makes them, and what gets cut when scope is tight. Studios still operating on the core-first model are usually slower to course-correct when their event calendar disappoints, because the calendar wasn't where they put their best people in the first place.

What "core-first" actually meant

The core-first model assumed a player's relationship with a game was carried by the core loop. If the loop was satisfying, players would keep playing. If it wasn't, no amount of event content would save the game. Design effort concentrated on getting the loop right, and the rest of the game was downstream of that decision.

This worked when sessions were short, when players had relatively few games competing for their time, and when monetisation was driven by isolated transactions rather than ongoing engagement. A player who liked the core loop opened the game, played it, made purchases when prompted, and left. The next session looked similar. Long-term retention came from the loop continuing to feel good.

In that environment, event content was supplemental. It gave engaged players occasional novelty, but the underlying revenue and retention engine ran on the core experience. A studio that nailed the core loop could earn a long tail without an aggressive event calendar.

What "event-first" actually means

Event-first is a different theory of what holds player attention. The argument is that the core loop is a foundation, but the reason a player opens the game today rather than yesterday is what's happening in the game right now. Without a reason to come back today, the core loop's quality alone can't sustain engagement past the early sessions.

Top-grossing mobile games in 2026 are reportedly built around 10+ live ops events per session. That's not a typo — players are encountering multiple event surfaces, time-bound content windows, and live-service elements in a single play session. The core loop is still there underneath, but most of what the player interacts with is event-scaffolded around it.

This changes the design hierarchy. The first decisions a studio makes about a new game in this model aren't about the core loop in isolation. They're about what kinds of events the game will support, how often, with what mechanics, and how the core loop has to be structured to accommodate that cadence. The core loop is designed to be eventable.

Practically, a game built event-first looks different in a few ways. Its progression systems support being interrupted by event content without players feeling derailed. Its economy can absorb the temporary influxes that events produce without inflating. Its UI surfaces upcoming events prominently rather than treating them as side content. Its analytics track engagement with event surfaces as primary metrics, not as supplementary ones.

What this changes about who's designing the game

In the core-first era, the senior design talent on a project worked on the core loop. Live ops, when it existed, was often staffed at the producer level — operational coordination, calendar management, content scheduling. The work was important but not where the design vision lived.

Event-first design moves senior design talent toward the event layer. The decisions about which events run when, what mechanics they introduce, how they interlock with player progression, and how they interact with monetisation are now where the most strategic design thinking happens. The core loop still requires great design, but it's increasingly a substrate decision — important to get right, but not where the year-over-year competitive battle is fought.

This is a real career shift for designers entering the industry now. The skill set that produces good event design — calendar thinking, player rhythm sensitivity, mechanic-mixing, scarcity calibration — overlaps with but isn't identical to the skill set that produces great core gameplay. Studios are increasingly hiring for the first and treating the second as table stakes.

The risk of event-first design done badly

Event-first design has a failure mode that core-first design doesn't. When the event calendar disappoints, the game has nothing to retreat to. The core loop, designed to be a substrate for events, is often deliberately less stand-alone-engaging than a core-first loop would be. Players who tune out of the event cycle don't have a deep core experience to fall back on.

The clearest sign of this failure mode is that engagement drops sharply during slow event weeks — the periods between major events when the calendar is light. In a healthy event-first game, slow weeks still see engagement from the underlying loop. In a brittle one, slow weeks see player numbers crater.

The fix isn't to abandon event-first design; it's to make sure the core loop is substrate enough to carry players through gaps. Event-first doesn't mean event-only. It means events lead, and the core supports them well enough to be there when the events pause.

The other failure mode is event fatigue. Ten events per session can produce engagement, or it can produce noise. Players who feel like they're constantly being asked to engage with new mechanics, new currencies, new time-bound content end up disengaging from all of it. The volume of events isn't itself the goal. The right number is the number players can engage with meaningfully without burning out, and that number is usually lower than the maximum the studio is capable of producing.

What event-first looks like for smaller studios

The event-first shift was driven by large publishers running titles with substantial live-ops teams. Smaller studios sometimes read this and conclude they can't compete — they don't have the headcount to run 10+ events per session, so they're stuck in the core-first model whether they like it or not.

That's the wrong read. Event-first design doesn't require massive event volume; it requires the calendar to be the central design surface, not the loop. A smaller studio running one well-conceived event per week, designed to interlock with the player's existing progression and economy, can be event-first in approach even if not in volume. The differentiator is that the event calendar is where the strategic design attention goes — not that there are 10 events running concurrently.

Smaller studios also benefit disproportionately from the shift toward templatised live ops infrastructure. The patterns the large publishers developed for running events at scale are increasingly available as systems rather than requiring in-house builds. A studio that can compose existing event mechanics intelligently doesn't have to invent them.

See how we approach event-first monetisation →

The center of gravity in mobile design has shifted. Studios still designing as if the core loop carries the relationship usually find their retention curves flatter than the studios designing the event cadence as the primary engagement engine. The core loop matters as much as it ever did — it just isn't where the work is anymore.

Talk to us about event-first design →

Share this post

See what this looks like for your game.

SDK for Unity and Unreal. A 20-minute call to walk you through it.

Book a demo