Mobile Game Development Handbook | A Design Checklist from Concept to Retention and Monetization — For Indie Developers to AAA Studios

Mobile Game Development Handbook | A Design Checklist from Concept to Retention and Monetization — For Indie Developers to AAA Studios

Hello, I’m Toroneko.

One thing I have felt throughout my many years of working in the game industry is that game development is highly dependent on individuals and heavily influenced by the experience and skills of the people creating the game.

At the same time, the core elements of game development can be visualized and systematized. However, much of this knowledge remains inside individual people’s heads instead of being organized and shared.

This creates problems such as:

Even major game companies face these problems.

The situation is even more difficult for small game companies and solo developers, who often have to develop games through trial and error.

I therefore decided to create something that could serve as a game development handbook for live-service games such as mobile games and online PC games.

After users install and begin playing a live-service game, the team must continue providing events, gacha, new characters, additional progression systems, campaigns, updates, and customer support while creating reasons for players to remain engaged over the long term.

I break this structure down into what I call the following three types of motivation:

Using these three motivations as the foundation, this article explains game-development methods and design areas that developers and producers can apply across different game genres.

This handbook can be used to create the foundation of a game design.

You can then add the elements required for the specific genre you are developing, whether it is an RPG, puzzle game, idle game, card game, simulation game, rhythm game, or location-based game.

Toroneko’s Three-Motivation Framework

The following three types of motivation are important for live-service mobile games.

 

A game business will not succeed unless all three are established.

Even if one works well, the game will fail if the other two are weak.

Motivation	Role	Main Related Areas
Motivation to Install	The reason a player wants to start the game	Concept, IP, worldbuilding, characters, advertising, app store presence, and buzz
Motivation to Keep Playing	The reason a player wants to continue playing from the following day onward	Core gameplay experience, progression, rewards, events, community, and short-, medium-, and long-term goals
Motivation to Spend	The reason a player wants to pay money	Gacha, passes, packs, characters, time-saving benefits, limited availability, and the desire to own

To summarize:

• If the Motivation to Install is weak, the game cannot acquire users
• If the Motivation to Keep Playing is weak, users will churn on the first day or within the first few days
• If the Motivation to Spend is weak, the game will not generate revenue

Live-service game development therefore requires teams to design the reason to start, the reason to continue, and the reason to spend as one connected system.

This is the central point of this handbook.

Game Development Means Designing the Three Types of Motivation

Games contain many different elements, including combat, progression, rewards, UI, events, gacha, stories, and characters.

However, developing each element independently will not produce a successful game.

Teams need to understand which of the three motivations each element supports.

Development Element	Main Related Motivations	What to Review
Worldbuilding	Install and keep playing	Can it attract interest at first sight, and is it a world players will want to remain involved with?
Characters	Install, keep playing, and spend	Is their appeal created through appearance, performance, story, or the desire to own them?
Combat	Keep playing	Is the central activity that players repeat enjoyable?
Progression	Keep playing and spend	Can players feel themselves becoming stronger, and do they have a reason to continue progressing?
Rewards	Keep playing and spend	Do the results of playing provide satisfying rewards?
Gacha	Spend and keep playing	Are there desirable rewards, and do those rewards have a purpose after acquisition?
Events	Keep playing, spend, and return	Do events create a reason to play during the event period and an opportunity to return?
Store Images and Videos	Install	Can they communicate the reason to start within a few seconds?
Tutorial	Keep playing	Can players understand the game and experience its appeal?
UI/UX	Keep playing and spend	Is friction minimized when controlling the game, progressing, purchasing, and claiming rewards?
Community	Keep playing and spend	Does interaction with other users create a reason to continue?
Rankings	Keep playing and spend	Is there a reason to compete and aim higher?
Passes and Monthly Products	Keep playing and spend	Are continued play and spending connected naturally?

During development, teams need to confirm:

• What player behavior each feature is intended to generate
• Which motivation the feature supports

Focusing on these questions can significantly improve the quality of game planning, design, and development.

The following sections explain what needs to be designed within each of the three motivations.

Including these elements in planning, design, and development without major omissions creates a foundation for reducing the risk of failure.

Design Areas for the Motivation to Install

The Motivation to Install is the reason a user wants to start the game.

It is strongly influenced by the game’s concept and visual presentation.

The following areas affect whether the game can make users think, “I want to play this.”

Design Area	What to Review
Game Concept	Can the game’s appeal be communicated in one sentence? Can users immediately understand what kind of game it is?
Genre	Does the actual experience match what users expect from the genre?
Target Audience	Is it clear who the game is for, including age, gender, preferences, and expected play time?
IP and Subject Matter	Can the game reach existing fans while also acquiring new users?
Worldbuilding	Does the setting, visual presentation, or atmosphere attract interest at first sight?
Characters	Is there something about the characters that immediately attracts attention? Is the game designed so players can find a favorite character?
Art	Is the artwork appealing enough to stop users when they see it in an advertisement or store listing?
Gameplay Screens	Can users understand what they will actually do in the game?
Store Images	Do they reduce concerns before installation and create a reason to start?
Store Video	Can it communicate controls, pacing, rewards, and character appeal within a short time?
Advertising Message	Is there an angle that will generate a response from users seeing the game for the first time?
Pre-Registration Message	Is there a reason to register and a reason to claim the rewards?
Reviews and Ratings	Do they reduce concerns before users begin playing?
App Size and Device Requirements	Have potential concerns before installation been reduced?
Game Title and Icon	Can the game be recognized among competing titles and attract attention?

The game’s appeal must first be visible and understandable.

The team then needs external marketing initiatives that can communicate that appeal effectively.

A game whose appeal and enjoyment cannot be understood until after playing will struggle to create Motivation to Install, making user acquisition more difficult.

The appeal that can be understood before starting the game therefore needs to be designed during development.

Design Areas for the Motivation to Keep Playing

The Motivation to Keep Playing is the reason users want to continue playing the next day, the day after that, and beyond after installing the game.

If this motivation is weak, users will not remain in a live-service game.

The following design areas affect the Motivation to Keep Playing.

Design Area	What to Review
Core Gameplay Experience	What activity will users repeat? Is the center of the gameplay clear?
First Session	Can users understand the objective and reach the game’s appeal within the first few minutes?
Tutorial	Can users understand the game through play without being overwhelmed by explanations?
Early-Game Progression	Can users experience growth, rewards, and a sense of achievement on the first day?
Combat, Action, Puzzle, or Other Core Gameplay	Does the central gameplay feel satisfying?
Player-Character Progression	Can users feel that their characters have become stronger?
Rewards	Can users understand and appreciate the value of the rewards?
Daily Content	Is there a reason to play every day?
Weekly Content	Is there a reason to return each week?
Events	Is there a reason to play during the event period?
Login Bonuses	Do they create a reason to log in and play?
Missions	Do users know what to do next, and do the missions create a reason to play?
Story	Does the story create a reason to continue playing to see what happens next?
Character Progression	Is there a reason to continue developing favorite characters?
Guilds and Cooperative Features	Is there a reason to continue playing with other users?
Rankings and PvP	Is there a reason to compete and aim higher?
Collection	Is there a reason to collect items or complete a collection?
Long-Term Goals	Is there something to pursue over several weeks or months?

The Motivation to Keep Playing is created through the core gameplay experience and the play cycle.

Some games attempt to create this motivation primarily through reward distribution.

This may improve visible KPIs in the short term, but it becomes increasingly difficult to sustain over the long term.

Reward distribution alone does not address the core issue.

The reason to continue playing is created through a combination of the gameplay itself, progression, characters, events, community, and long-term goals.

Design Areas for the Motivation to Spend

The Motivation to Spend is the reason users want to pay money.

Live-service games need to create the following within the game design:

• A reason to want something
• A reason to feel that something is lacking
• A reason to purchase now

Attractive products and attractive sales presentation alone cannot create genuine Motivation to Spend.

The following design areas affect the Motivation to Spend.

Design Area	What to Review
Role of Monetized Products	Is it clear what users are expected to spend money on?
Gacha	Are there desirable characters, equipment, or items?
Character Value	Is value created through performance, appearance, story, or the desire to own the character?
Equipment Value	Is there a reason to obtain and improve equipment?
Skins and Costumes	Is there a reason to spend money on appearance?
Pass Products	Are continued play and spending connected?
Monthly Products	Is there a reason to purchase them every month?
Starter Packs	Are they attractive enough to purchase during the early game?
Limited-Time Products	Is there a reason to purchase now?
Sales and Campaigns	Does the offer feel worth more than its price?
Pity and Exchange Systems	Do they reduce concerns about spending?
Free-to-Play Rewards	Is there a meaningful range of content that can be played without spending?
Monetization Pressure	Does the sales approach create frustration or churn?
Price Tiers	Do low-, medium-, and high-priced products each have a clear role?
Purchase Flow	Can users make a purchase at the moment they want the item?

Effective monetization design requires the following three elements:

• A reason for users to want the item
• A reason for users to think, “I would be willing to buy it now”
• A reason for users to feel that purchasing it will make the game more enjoyable

Design Areas Commonly Required for Live-Service Games

The previous sections explained design areas based on the three types of player motivation.

The following sections cover the fundamental design areas required for game development.

The necessary features, patterns of play, and reasons to spend differ between RPGs, puzzle games, idle games, card games, simulation games, rhythm games, and location-based games.

Use the following areas as a checklist to prevent important omissions during game design and development.

Game Concept Design

Design Area	What to Review
One-Sentence Game Description	Can someone immediately understand what kind of game it is?
Primary Appeal	Is there a reason to choose this game?
Target Audience	Is it clear who should play the game?
Play Context	Is it clear when, where, and for how long users are expected to play?
Competitive Difference	Can the difference from existing titles be explained?
Reason to Continue	Can the team explain why users will continue playing?
Reason to Spend	Can the team explain why users will pay money?
Development Scope	Can the game be completed with the planned team size and development period?
Live-Operations Scope	Can the team continue providing updates after launch?

Core Gameplay Experience Design

Design Area	What to Review
Core Activity	What action will users repeat?
Controls	Can the game be played comfortably on a smartphone?
Decision-Making	Does the core gameplay give users opportunities to think and make decisions?
Success Experience	Does success feel satisfying?
Failure Experience	Does failure make users want to try again?
Pacing	Can the game be played in short sessions without unnecessary frustration?
Presentation	Does the presentation make gameplay results feel satisfying and exciting?
Replayability	Is there a reason to repeat the same activity?
Sense of Progression	Can users feel a difference before and after playing?

First-Time User Experience Design

Design Area	What to Review
First Launch	Will users churn because of waiting times or loading immediately after launch?
Initial Introduction	Are the world, objective, and required actions communicated?
Tutorial	Is it short enough while still explaining the game’s appeal and systems?
First Battle or First Play Session	Can users experience the game’s appeal during their first session?
First Reward	Can users understand the benefit and value of the reward?
First Progression Experience	Can users feel that they have become stronger?
First Gacha	Does it create anticipation for characters or items?
First-Day Goal	Do users know what they should accomplish on the first day?
Early Churn Points	Has the team identified where users leave and prepared countermeasures?

Play-Cycle Design

Design Area	What to Review
Login	Is there a reason to launch the game?
Play	Is the gameplay flow easy to understand, and does it create a desire to play again?
Reward Acquisition	Do users receive rewards for playing, and are the rewards appropriate?
Progression	Is it clear where rewards should be used? Does progression feel satisfying?
Replay	Is there a reason to play again?
Goal Renewal	Are new goals continually provided?
Return Login	Is there a reason to launch the game again on the following day and beyond?
Long-Term Progression	Is there a reason to play for several days or weeks?

Progression-System Design

Design Area	What to Review
Progression Targets	Is it clear whether users are developing characters, equipment, facilities, skills, or other elements?
Progression Materials	Is it clear what users need to collect?
Progression Stages	Are there stages such as levels, evolution, awakening, or limit breaking?
Progression Impact	Can users feel that they have become stronger?
Progression Cost	Are the required materials and currency amounts appropriate?
Progression Priorities	Can users determine what they should develop first?
Long-Term Progression	Are there progression goals lasting several weeks or months?
Progression Blockers	Does the team understand what may prevent users from progressing?
New-User Support	Can users who start later catch up?

Reward Design

Design Area	What to Review
First-Time Rewards	Do rewards received immediately after playing feel valuable?
Standard Rewards	Is there a reward for each play session?
Daily Rewards	Are daily rewards available, and do they have value?
Weekly Rewards	Are weekly rewards available, and do they have value?
Event Rewards	Are the rewards valuable enough to motivate participation?
Ranking Rewards	Are the rewards valuable enough to motivate competition?
Gacha Rewards	Does the reward pool contain desirable items?
Material Rewards	Are they connected to progression?
Free-to-Play Rewards	Is there a reason for non-paying users to continue playing for rewards?
Payer Rewards	Does spending provide value that users can accept?
Surplus Rewards	Is there a use for excess materials and items?

Game-Economy Design

Design Area	What to Review
Free Currency	Are acquisition volume and usage destinations designed appropriately?
Paid Currency	Is there a reason to purchase it and a place to spend it?
Progression Materials	Are acquisition and required quantities balanced?
Resource Sinks	Are there places to spend currency and materials?
Supply Volume	Is excessive distribution reducing value? Is the economy balanced?
Scarcity	Does scarcity support player goals without creating excessive frustration or stress?
Exchange Shop	Is there a use for excess materials?
Inflation Control	Can the in-game economy remain functional during long-term operation?
Paid-Currency Design	Are the differences and benefits of paid and free currency understandable?
Late-Starting Users	Has the burden on users who start later been reduced?

Character and Item Design

Design Area	What to Review
Character Role	Does each character have gameplay value, story value, visual appeal, and a clear role?
Rarity	Does rarity feel meaningful and justified?
Performance Differences	Are differences in strength easy to understand?
Attributes and Matchups	Do they affect team composition and strategy, and are they balanced?
Collectability	Is there a reason to collect the characters or items?
Favorite-Character Appeal	Is there a reason for users to become attached to them?
Ongoing Additions	Can the team continue adding new characters and equipment?
Protection of Existing Assets	Will older characters avoid suddenly losing all value?
Rerun Value	Is there a reason to bring back previous characters and items?

Gacha and Sales Design

Design Area	What to Review
Gacha Contents	Is it clear what users are pulling for?
Reward Pool	Does it include desirable rewards?
Rates	Is the design acceptable to users?
Pity System	Does it provide reassurance and acceptable value relative to the amount spent?
Exchange System	Is there a system that allows users to move closer to obtaining the desired reward?
Limited Availability	Is there a reason to pull now?
Reruns	Can previous assets be reused?
First-Purchase Discount	Does it create a reason to make the first purchase?
Packs	Can users purchase products based on specific objectives?
Passes	Are continued play and spending connected?
Monthly Products	Is there a reason to purchase them every month?
High-Priced Products	Do products for high-spending users provide acceptable value?
Sales Frequency	Are too many offers creating frustration?

Event Design

Design Area	What to Review
Event Objective	Is the event intended to improve retention, reactivation, spending, or visibility?
Duration	Is the event neither too long nor too short?
Participation Requirements	Can new users participate?
Rewards	Is there a reason to participate?
Difficulty	Can a broad range of users play the event?
Repeatable Content	Is there a reason to replay it?
Rankings	Is there a reason to compete?
Story	Does the event offer a story with its own appeal?
Gacha Integration	Are the reasons to obtain items and play the event connected?
Rerun Operations	Is the event structured so it can be reused?
Event Announcement	Can the reason to participate be communicated before the event begins, and is it being communicated?

UI/UX Design

Design Area	What to Review
Home Screen	Can users quickly access important information?
Menus	Can users reach the feature they need?
Progression Screen	Are upgrade effects and required materials clear?
Team-Building Screen	Can users select characters and equipment easily?
Battle Screen	Are the current situation and controls understandable?
Reward Screen	Is it clear what the user obtained?
Shop Screen	Is it clear what users should purchase, and is the product appeal communicated?
Gacha Screen	Can users review the reward pool, rates, and pity system?
Event Screen	Are participation requirements, rewards, and time remaining clear?
Notifications	Can information be delivered at the necessary time?
Claim Flow	Can users easily claim rewards, mission rewards, and gifts without overlooking them?
Purchase Flow	Can users proceed easily to purchase when they want an item?

Live-Operations Design

Design Area	What to Review
Update Frequency	How often will new elements be added?
Event Cadence	Is there a monthly and weekly operating cycle?
Gacha Cadence	Is there a cycle for new, rerun, and limited gacha?
Content Additions	Can new forms of gameplay be added?
Announcements	Can information be delivered to users appropriately?
Bug Response	Is there a structure for responding quickly?
Customer Support	Can the team respond to user inquiries?
Update Plan	Are short-, medium-, and long-term updates planned?
Operational Workload	Can the team sustain the required workload?
Asset Production	Can the team continue producing characters, events, banners, and announcements?
Rerun Plan	Can previous events and products be reused?
New-User Initiatives	Can the team support the retention of users who start later?
Reactivation Initiatives	Is there a reason for churned users to return?

KPI and Tracking Design

Design Area	What to Review
Installs	Can the number of acquired users be measured?
First Launch	Can the number of users who launch the game after installation be measured?
Tutorial Completion	Can the team identify where users leave?
D1 Retention	Can the team confirm whether users return the day after starting?
D3 and D7 Retention	Can the team confirm whether users remain during the early game?
D30 Retention	Can the team confirm whether users remain during the medium term?
Payer Conversion	Can spending behavior be measured?
ARPU	Can revenue relative to DAU be measured?
ARPPU	Can average spending per paying user be measured?
LTV	Can lifetime spending over a defined period be measured?
Event Participation Rate	Can the team confirm whether users are playing the event?
Gacha Usage Rate	Can the team confirm whether users are engaging with the gacha?
Shop Purchase Rate	Can the team confirm whether products are being purchased?
Churn Points	Can the team identify where users leave?
Reviews	Can the team monitor dissatisfaction and user evaluations?
Purchase Flow	Can the team identify which screens lead to purchases?
Reward Claims	Can the team confirm whether rewards are being claimed?

Design Areas to Review by Development Phase

The areas that need to be reviewed differ between planning, prototype development, full production, alpha and beta builds, CBT and OBT, and post-launch operations.

Reviewing both the design and the state of development during each phase improves the quality of the final game.

What to Review During the Planning Stage

Review Area	What to Review
Reason to Install	Can the team explain why users will want to start?
Reason to Continue	Can the team explain why users will continue playing?
Reason to Spend	Can the team explain why users will pay money?
Core Gameplay Experience	Is it clear what activity users will repeat?
Target Audience	Is it clear who will play the game?
Competitors	Which titles will the game be compared with, and can it compete?
Development Scope	Can the planned game be completed?
Live-Operations Scope	Can the team continue updating the game?
First-Time Experience	Can users understand the game’s appeal immediately after starting?

What to Review in the Prototype

Review Area	What to Review
Core Gameplay Experience	Can the team confirm through actual play that the game is enjoyable?
Controls	Can the game be played comfortably on a smartphone?
Pacing	Can it be played without unnecessary frustration?
Sense of Achievement	Does playing produce satisfaction and a positive feeling?
Sense of Progression	Can users feel that they are becoming stronger?
Replay Motivation	Is there a reason to play again?
Development Reproducibility	Can the design described in the plan be reproduced in the actual implementation?
UI and Controls	Are they understandable and easy to use?

A prototype does not need to have the same visual quality as the completed game.

The key point is to confirm whether the central gameplay—the core experience—works.

The team should prioritize whether the game is enjoyable when played and whether there is a reason to play repeatedly over graphics and presentation.

What to Review During Full Production, Alpha, and Beta

Confirm whether the planned content has been implemented.

Review Area	What to Review
First-Time Experience	Can users experience the game’s appeal after installing it?
Progression Design	Is there a reason to progress?
Reward Design	Are gameplay and rewards connected?
Monetization Design	Is there a reason to want the products, and is there a purchase flow?
Event Design	Have post-launch events been designed?
UI/UX	Is the game understandable and easy to use?
Tracking Design	Has the required tracking been implemented?
Live-Operations Preparation	Are the assets and materials required after launch being prepared?
Progression Balance	Can users progress and play without excessive frustration?
Economy Balance	Are currency and material values functioning properly?
Operational Workload	Can the team sustain the required workload?
Development Progress	Has the planned content been implemented?

Definitions of full production, alpha, and beta differ between game companies.

For this reason, they are grouped together here rather than divided into detailed stages.

These stages sit between the prototype and CBT or OBT.

It is therefore useful to repeat both the prototype review items and the CBT or OBT review items during full production, alpha, and beta.

What to Review During CBT and OBT

Review Area	What to Review
Server Load	Are there problems with concurrent connections or payment processing?
First-Time Experience	Can first-time users reach the game’s appeal?
Retention	Are there major problems with D1, D3, or D7 retention?
Purchase Flow	Can users complete purchases without problems?
Bugs	Are there progression blockers or reward-related bugs?
Store Messaging	Does the actual game match what is communicated in the store listing?
Paid User Acquisition	Are users acquired through advertising churning excessively during the first-time experience?
First-Month Operations	Are the events and products for the immediate post-launch period ready?
Customer Support	Is there a system for responding to user inquiries?

The required review areas for CBT and OBT will differ depending on how the team defines the purpose and objectives of each test.

Some teams may also conclude that retention and monetization cannot be validated accurately during CBT or OBT because the testing environment is not identical to the live service.

The team should therefore define the purpose of the CBT or OBT first and then decide what needs to be validated.

What to Review After Launch

Review Area	What to Review
Acquisition	Is the game acquiring new users?
Retention	Are users remaining in the game?
Churn	Does the team understand where and why users leave?
Reactivation	Are there paths and triggers that encourage churned users to return?
Monetization	Are users spending money?
Investment Recovery	Is there a reasonable path to recovering advertising costs?
Health	Are there significant complaints or risks of backlash, and are reviews healthy?
Events	Are users participating?
Gacha	Is the game providing what users want?
Improvement Capability	Does the team have the structure and environment required to address issues?
Updates	Are the next events, gacha, and additional features being prepared?

Important Points When Reviewing the Design Checklist

The previous sections list design areas for each development phase.

When presented as a checklist, it may appear that the objective is to include every possible feature.

However, the important point is not to include every feature.

The important question is which of the following motivations each feature supports:

• Motivation to Install
• Motivation to Keep Playing
• Motivation to Spend

Live-service games function through the multiplication of these three motivations.

A feature whose purpose cannot be explained is not necessarily required.

Even if it is developed, it may not contribute to any of the three motivations.

Developing too many features can also increase development workload, make the UI more complicated, and make the game more difficult for users to understand.

The Correct Design Depends on the Genre

The areas in this handbook are design elements that should be reviewed when developing live-service mobile games.

They are useful for building the underlying structure of a game.

However, they need to be adjusted for each game genre.

The required features, patterns of play, and reasons to spend differ between RPGs, puzzle games, idle games, card games, simulation games, rhythm games, and location-based games.

The design therefore needs to be adjusted according to:

• The game concept
• The genre
• The target audience
• The development scope
• The live-operations structure

Live-Service Mobile Games Must Be Designed With Post-Launch Updates in Mind

A live-service mobile game is not a product that is finished once it launches.

After launch, the team needs to continue providing events, gacha, characters, rewards, campaigns, and updates.

Development therefore needs to include reviews based on the post-launch live-operations phase.

Review Area	What to Review
Updates	Can new elements be added?
Additional Characters	Can the team continue releasing new characters?
Additional Events	Can the team continue producing events?
Reward Design	Can new rewards be added without damaging the game economy?
Reruns	Can previous events and products be reused?
Operational Workload	Can the team sustain the required workload?
New-User Support	Can the burden on users who start later be reduced?
Reactivated-User Support	Can the game create a reason for churned users to return?

A game developed without considering post-launch operations may perform well during the first month but become increasingly difficult to operate afterward.

Common examples include:

• A character sells well, but developing additional characters takes too long
• The content is enjoyable, but the technical or design structure makes additional content difficult to produce
• The design provides limited flexibility for live events, making it difficult to create enough variation

The team needs to connect installation, retention, monetization, and live operations from the development stage.

Conclusion

A live-service mobile game cannot succeed as a business through gameplay quality alone.

Teams need to design:

Motivation to Install × Motivation to Keep Playing × Motivation to Spend

A live-service mobile game becomes a viable business only when all three are established.

If any one of them is missing, the business will not succeed.

Developers and producers should not design combat, progression, rewards, UI, events, gacha, live operations, and KPIs as isolated elements.

They should confirm which motivation each element supports while designing the game.

The objective is not to add features without a clear reason.

The objective is to create reasons for users to want to play the game, continue playing, spend money, and remain engaged after launch.

That is the foundation of live-service mobile game development and the central message of this handbook.

Please contact me if you need support with game design.