Player Lifecycle

Summary

The Player Lifecycle is a model for understanding how a player’s relationship with a game changes over time. Oscar Clark’s formulation in Games as a Service (Clark, 2014, see source-games-as-a-service) identifies five stages — Discovering, Learning, Engaging, Earning, Churning — and argues that every design decision should map onto one or more of these stages. The model is analogous to the product lifecycle from marketing (introduction → growth → maturity → decline), but applied at the level of the individual player’s journey rather than the product’s market position.

Key ideas

  • Discovering — The player first encounters the game. They have no invested utility yet; barriers to entry (price, complexity, unclear value proposition) will prevent most potential players from ever starting. Design goal: reduce friction, establish immediate perceived value within the first minute of play.
  • Learning — The player is building competence and familiarity. They are vulnerable to confusion or frustration. Design goal: onboarding that rewards progress frequently, establishes core pattern-matching, and creates early emotional investment (see engagement-led-design for the Bond Opening technique).
  • Engaging — The player has formed a habit and is in active relationship with the game. This is the stage most design literature focuses on. The context-loop and metagame carry most of the work here. Design goal: sustain the rhythm-of-play, deepen social connections (see six-degrees-of-socialization), and create meaningful reasons to return.
  • Earning — A subset of engaged players convert to spending. This is not a binary switch; spending behaviour correlates with depth of engagement and perceived value. The “gateway good” — a first purchase designed for low risk and high obvious value — is the recommended conversion mechanism (Clark, Games as a Service, see source-games-as-a-service). Design goal: present monetisation opportunities that feel natural rather than intrusive; never imply that payment is required for a non-paying player to continue meaningfully.
  • Churning — The player leaves. Churn is inevitable; the design question is when it happens and how gracefully. A player who churns positively (satisfied, might return) is very different from one who churns negatively (frustrated, becomes a detractor). Design goal: extend the engaging stage for as long as the game genuinely delivers value; build re-engagement mechanisms (notification, seasonal content, friend activity) without becoming coercive.

The non-paying player as infrastructure

Clark’s most counter-intuitive claim is that non-paying (“freeloading”) players are not a problem to be solved but a structural requirement (Clark, Games as a Service, see source-games-as-a-service). They:

  • Provide the population density that makes multiplayer and social features work.
  • Serve as social proof for paying players (seeing activity normalises the game).
  • Represent potential future payers at a later life stage.
  • Generate organic word-of-mouth and content (streaming, screenshots, discussion).

A monetisation strategy that degrades the experience for non-payers damages the ecosystem that paying players inhabit.

Relationship to product lifecycle theory

Clark maps the lifecycle onto Geoffrey Moore’s technology adoption curve (Crossing the Chasm, referenced in Clark, Games as a Service, see source-games-as-a-service): innovators and early adopters enter the Discovering stage before a “chasm” where early majority players require a lower friction entry. This has practical design implications: the onboarding experience should be designed for the early majority (who need “permission to play”), not for the hardcore early adopters who will figure it out themselves.

Whale players and lifecycle position

“Whale” players — the small percentage of users who account for a disproportionate share of revenue — are typically deeply engaged players at the Earning stage, not casual browsers. Clark cautions against designing specifically to exploit whale psychology, as this tends to degrade the experience for the broader population and can trigger regulatory scrutiny (see dark-patterns).

In practice

Map every major feature and UI decision to a lifecycle stage during design review:

Lifecycle stageTypical design concerns
DiscoveringApp store listing, first screen, tutorial entry, no upfront cost friction
LearningOnboarding flow, first-minute reward, early failure handling
Engaginggame-loops, daily return hooks, social features, metagame layers
EarningVirtual goods placement, gateway good, pricing tiers, opt-in advertising
ChurningRe-engagement notifications, graceful exit, positive churn design

When reviewing analytics, Clark recommends segmenting by “days since download” (cohort analysis) rather than calendar date, so that players at the same lifecycle stage can be compared regardless of when they joined (Clark, Games as a Service, see source-games-as-a-service). This prevents the distortion caused by mixing new and veteran players in the same data set.

For live-service games in Unity, the lifecycle model informs:

  • Tutorial system design — gated not by time but by demonstrated competency at each stage boundary.
  • Analytics event naming — naming events by lifecycle stage (e.g. player_first_purchase, session_day_7) to make cohort queries straightforward.
  • Notification logic — sending re-engagement pushes only to players who have passed the Learning stage (days 3–7 threshold, empirically set per game).

Evidence

Clark draws on product lifecycle theory (Moore, Crossing the Chasm), Bartle’s player types (achievers, explorers, socialisers, killers), and operant conditioning / Skinner Box frameworks (B.F. Skinner) to support the lifecycle model (Clark, Games as a Service, see source-games-as-a-service). The stages are presented as a practitioner framework derived from Clark’s own production experience (PlayStation Home, 3UK, Applifier) rather than from controlled empirical studies.

Bartle’s original taxonomy (MUD, 1996) is a typology of player motivations, not lifecycle stages; Clark adapts it to describe what motivates players at different points in their journey rather than as fixed personality categories.

Implications

  • Onboarding is not a tutorial problem — it is a lifecycle transition problem. The goal is not to teach controls but to move the player from Discovering to Learning as quickly as possible, then from Learning to Engaging before they churn from confusion.
  • Retention metrics proxy lifecycle health — Day 1, Day 7, and Day 30 retention rates are industry-standard proxies for the Discovering→Learning, Learning→Engaging, and Engaging→Earning transitions respectively.
  • Monetisation timing matters — presenting purchase opportunities during the Learning stage is counterproductive; players have not yet formed sufficient investment to overcome purchase resistance.
  • Churn analysis is design feedback — if players churn at a consistent point in the experience (e.g. level 12), that is a design failure, not an audience quality problem.

Open questions

  • Clark’s lifecycle model is not empirically validated in the book — how does it compare to published player retention research (e.g. Limelight Networks, Newzoo player behaviour studies)?
  • The boundary between “Engaging” and “Earning” is treated as fuzzy and player-driven. Is there a design technique for accelerating conversion without triggering the coercive pattern concerns Clark identifies?
  • How does the lifecycle model apply to single-session or very short-session games (hypercasual, puzzle) where the “Engaging” stage may span only minutes?