Games as a Service Development
Summary
Games as a Service (GaaS) development refers to the production methodology, team structures, and release cadences required to build and sustain a live-service game — a game that is not shipped once but continuously operated, updated, and extended after launch. Oscar Clark’s Games as a Service (Clark, 2014, see source-games-as-a-service) dedicates two chapters (12 and 13) to the production dimension of this philosophy, adapting agile/scrum methodology to the games context and arguing that the entire production mindset must shift from “delivering a product” to “sustaining a relationship.”
This page covers the production and process dimension. For the design frameworks (player lifecycle, monetisation, social design) see player-lifecycle, f2p-monetisation-design, and six-degrees-of-socialization.
Key ideas
Core vision and pivoting
Clark argues that a live-service game must begin with a clearly articulated core vision — a concise statement of the fundamental player experience that the service promises to deliver. The core vision:
- Is not a feature list; it is a promise about how the player will feel.
- Acts as the decision filter for every feature prioritisation and pivot decision.
- Must be held stable even as individual features are added, cut, or changed.
Pivoting — changing direction in response to playtesting, analytics, or market feedback — is presented not as a sign of failure but as a required capability (Clark, Games as a Service, see source-games-as-a-service, drawing on Eric Ries, The Lean Startup). The condition for a valid pivot is that it serves the core vision; a pivot that abandons the core vision is a restart, not a pivot.
Minimum Viable Product (MVP)
The MVP in the games context is the smallest playable version that can:
- Demonstrate the core mechanic loop (see game-loops) in playable form.
- Be tested by a real audience (internal, alpha, or closed beta).
- Generate actionable data about whether the core value proposition is working.
Clark is explicit that the MVP is not the launch product — it is the product at the point where real testing can begin (Clark, Games as a Service, see source-games-as-a-service). The risk of over-building before testing is that you may have built the wrong thing in great detail. The MVP philosophy argues for testing the most fundamental assumptions first.
In game development terms, the MVP typically includes:
- One complete playable loop of the core mechanic.
- Basic art (placeholder acceptable at this stage).
- Enough of the progression system to validate the engagement model.
- Analytics instrumentation for the key lifecycle transitions.
Post-MVP, the development cycle becomes iterative: test with small audience → measure → decide whether to deepen the current mechanic or unlock the next layer.
Triangle of Development
Clark applies the classic “iron triangle” of project management to game development (Clark, Games as a Service, see source-games-as-a-service): the three constraints are time, quality, and features (scope). Any two can be held stable while the third must flex. For a live-service game, this triangle governs every sprint decision:
- Fixed time (regular release cadence) + fixed quality (platform certification requirements) = variable features (scope cut to meet the deadline).
- Fixed features + fixed quality = variable time (slippage).
- Fixed time + fixed features = variable quality (tech debt and bugs accumulate).
Clark’s recommendation for live-service development: hold time constant (regular, predictable release cadence builds player and stakeholder trust) and negotiate between features and quality per sprint.
Agile and scrum applied to live-service games
Clark advocates an agile approach structured around scrum (Clark, Games as a Service, see source-games-as-a-service):
Core roles:
- Product Owner — holds the vision, prioritises the backlog, represents the player and business interests. In games this is often the creative director or a dedicated live-ops producer.
- Scrum Master — facilitates the sprint process, removes blockers, runs ceremonies. Not the same as a lead developer.
- Development team — cross-functional (design, engineering, art), self-organising within the sprint.
Sprint ceremonies:
- Sprint Planning: select work for the sprint from the backlog.
- Daily stand-up: 15-minute blockers and progress check.
- Sprint Review: demonstrate completed work to stakeholders.
- Sprint Retrospective: process improvement within the team.
Specific to live-service games:
- The backlog must contain both new feature work and live-ops maintenance (bug fixes, content updates, seasonal events).
- “Releases without releases” — Clark uses this phrase for techniques that decouple deployment from player-visible release: feature flags, A/B flags, content that is deployed but not yet visible (Clark, Games as a Service, see source-games-as-a-service). This allows continuous integration and deployment without each deployment being a full release event.
- Server roll-back must be planned for from the start; a deployment that breaks the live game must be recoverable within minutes, not hours.
Testing layers
Clark describes a layered testing approach for live-service games (Clark, Games as a Service, see source-games-as-a-service):
| Test type | Purpose | When |
|---|---|---|
| Unit testing | Verify individual components in isolation | Continuous (CI/CD) |
| Integration testing | Verify components work together | Before each build |
| End-to-end testing | Full player journey simulation | Before releases |
| Alpha audience | Internal and trusted external playtest | Post-MVP |
| Beta audience | Broader external playtest; data-generating | Pre-launch soft launch |
| AB testing | Compare variants in live population | Post-launch |
Clark flags a specific caution on AB testing: running AB tests that affect lifetime value requires very long observation windows — a change that improves short-term conversion may damage retention, and this will not be visible in a short-cycle test (Clark, Games as a Service, see source-games-as-a-service).
Team size and specialist roles
Clark notes that live-service mobile games — unlike AAA console products — have often been built by small teams (5–15 people), and that this is an advantage rather than a constraint (Clark, Games as a Service, see source-games-as-a-service). Small teams:
- Have lower coordination overhead.
- Can pivot faster.
- Have less institutional inertia when player data suggests a change.
The counterbalancing risk is that small teams tend to have fewer specialists, meaning each person covers more disciplines. Clark recommends that at minimum, a live-service game team has clear ownership of: design, engineering, analytics, live operations, and community management. These can be covered by the same individuals across multiple roles, but the responsibilities must be explicitly assigned.
Infrastructure considerations
For games that require a server-side presence (persistent state, multiplayer, analytics, monetisation):
- Thick client vs thin client: a thick client holds significant game state locally (faster, offline playable); a thin client pushes most state to the server (more controllable, harder to cheat). Most mobile live-service games occupy a position between the two.
- Cloud deployment: Clark references AWS EC2 and Azure as the dominant platforms of the era (Clark, Games as a Service, see source-games-as-a-service); the choice is now broader (GCP, dedicated game backends via Playfab, Unity Gaming Services, Nakama).
- HTTPS / TLS for all communication: Clark is explicit that all player data transmission must be encrypted — both for security and for the trust relationship with players.
- DDOS resilience: live games are targets; the server architecture must be designed for resilience under load, not just normal operation.
In practice
For a student or indie studio starting a live-service project in Unity:
- Define the core vision in one sentence before writing any code.
- Build an MVP — one complete loop of the core mechanic — before adding any social, monetisation, or metagame features.
- Instrument analytics from the first playable build. Key events: session start/end, first-minute milestone, first core loop completion, first failure, tutorial completion, first purchase prompt shown.
- Establish a sprint cadence (1–2 weeks is standard for small teams) and stick to it. Do not slip sprints — instead, cut scope.
- Plan your server infrastructure early even if you start without one. Retrofitting server-authoritative state into a client-heavy game is painful.
- Use Unity Gaming Services (UGS) for analytics, remote config (feature flags), and leaderboards without building custom backend infrastructure.
Relevant Unity packages/services: Unity Analytics, UGS Remote Config, UGS Leaderboards, Unity IAP, Unity Notifications, Unity Relay & Lobby (for multiplayer).
Evidence
Clark’s production framework draws on Eric Ries (The Lean Startup, 2011), Geoffrey Moore (Crossing the Chasm, 1991/2014), and standard scrum methodology (Clark, Games as a Service, see source-games-as-a-service). The application to games is Clark’s synthesis from production experience at Sony (PlayStation Home), Applifier, and games advisory work. The PRINCE2 project management framework is mentioned as an alternative to agile but not recommended for live-service work.
This page should be read alongside sprints for the detailed production cadence conventions used in the programme’s project modules.
Implications
- Live-service development is not “game development with updates” — it requires fundamentally different production structures, team roles, and success metrics.
- Launch is the beginning, not the end — the production pipeline must be designed for sustained operation from day one; retrofitting live-ops infrastructure after launch is extremely costly.
- Analytics is not optional — a live-service game that cannot measure its player-lifecycle transitions is flying blind. Instrument before launch.
- Feature flags and staged rollouts reduce release risk significantly — they allow problems to be caught and rolled back without a full emergency patch.
Lovell’s Production Framework: Dev Agency, Live Agency and the Minimum Awesome Product
Nicholas Lovell’s Pyramid of Game Design (Lovell, 2018, see source-pyramid-of-game-design) offers a complementary production framework that deepens Clark’s model in several ways.
Dev Agency vs Live Agency
Lovell distinguishes two fundamentally different production modes that coexist within any live-service organisation:
| Dev Agency | Live Agency | |
|---|---|---|
| Mindset | Startup — eliminating uncertainty | Corporate — optimising what is known |
| Goal | Find the fun; validated learning | Operate and improve a working game |
| Measured by | Learning milestones; KPI validation | Revenue, DAU, retention metrics |
| Risk type | Operational (will players enjoy this?) | Financial (are we spending efficiently?) |
| Appropriate stage | Concept → soft launch | Post-marketed launch |
The core insight: features that are appropriate Live Agency tools (daily login bonuses, live events, push notifications, social sharing) should not be included during Dev Agency because they obscure whether the Core Loop actually works. A game that retains players because of login bonuses has not demonstrated natural retention; remove the bonus and the game may collapse.
“By putting in systems like login bonuses or achievements, you can obscure the true retention metrics of your game.” (Lovell, The Pyramid of Game Design, Ch. 12)
This creates a productive tension with the common publisher expectation that games should ship with all retention features from day one. Lovell argues this is Live Agency thinking applied prematurely to a Dev Agency stage.
The Product Spectrum: From MVP to MAP
Where Clark introduces the MVP (Minimum Viable Product) as the correct target, Lovell defines a more granular spectrum:
| Stage | Definition | Purpose |
|---|---|---|
| Minimum Feasible Product (MFP) | Can we build this at all? Proof of technical concept | Eliminate technical risk |
| Minimum Viable Product (MVP) | Does this create the desired player behaviour at the smallest possible scale? | Validated learning; Lean startup stage |
| Minimum Desirable Product (MDP) | Is this fun enough that players would want more of it? | Player-facing test of the Base Layer |
| Minimum Awesome Product (MAP) | Is this good enough to launch? A game stripped to its essential experience | Soft launch candidate |
The MAP is the correct target for soft launch. It is deliberately stripped of all features that can be retrofitted easily (login bonuses, social features, seasonal events). This allows the soft launch to answer the fundamental question cleanly: Is the lifetime value of my customers good enough to justify spending marketing resources on this title?
The MAP is not the final product. It is the minimum product that has found the fun and can demonstrate the Core Loop working in live conditions.
The PRIC Evaluation
A practical prioritisation tool for deciding what to include in the MAP (soft launch) versus what to leave for post-launch:
| Letter | Criterion | Question |
|---|---|---|
| P — Publicity | Will this feature create positive or negative attention? | Some features (pay-to-win boosts) create backlash if added post-launch but are accepted if present from day one |
| R — Retrofit | How hard is it to add this later? | Features deeply embedded in the economy or UI are expensive to retrofit; features that sit on top of the core can be added easily |
| I — Impact | What KPIs will this feature move, and by how much? | High-impact features belong in the MAP; features that only marginally improve metrics belong post-launch |
| C — Cost | How expensive is this feature to implement? | High cost relative to impact argues for LATER |
The default assumption is LATER. A feature should be in the MAP only if it cannot be meaningfully added post-launch, is essential for testing the Core Loop, or would create significant backlash if added after soft launch.
Examples:
- Daily login bonuses → easy to retrofit, low impact on Core Loop validation → LATER
- Core monetisation boosts (if they affect player fairness perceptions) → negative publicity if added later → NOW
- Challenge systems that are the primary currency delivery mechanism → embedded in economy, high impact → NOW
- Social features for a game that is not socially dependent → can be retrofitted → LATER
The 40:20:10 Retention Benchmark
Popularised by Supercell, this benchmark represents the minimum retention quality before marketing spend is justified:
- D1 retention: 40% (40% of Day 0 players return exactly one day later)
- D7 retention: 20%
- D30 retention: 10%
Lovell notes this benchmark suits mobile games designed for daily return patterns. It is less appropriate for PC/console games or games with weekly play rhythms (where measuring D7 may catch many players on a non-play day).
The 40:20:10 rule should be measured with only natural retention present — no login bonuses, live events, or social hooks that could artificially inflate the numbers.
Open questions
- Clark’s framework was written in 2014, before the widespread adoption of battle passes, season passes, and content roadmaps as primary engagement structures. How do these change the production cadence model?
- Small-team live-service development has become significantly easier with UGS, Playfab, and similar BaaS platforms. Does this change the minimum viable team composition?
- How do the scrum ceremonies translate to the very small indie team (1–3 people)? Is a formal sprint structure useful at this scale, or does it become process overhead?
- Lovell describes a clean hand-off between Dev Agency and Live Agency. In practice, many studios run both simultaneously. What organisational structures support this?