Book Summary: Practical Game Design – Game as a Service

The second book about game dev I’ve read this year is Practical Game Design by Adam Kramarzewski and Ennio De Nucci. This book touches numerous important topics from ideation to LiveOps. This time, I’ll try not to write a whole six posts about the book. The book has fifteen chapters and I’m going to condense them into 7 bullet points. This is the last post containing the one last point.


Book Summary: Practical Game Design

  1. Intro to Game Production Process, Creating Concept, and Gameplay
  2. Story, Interaction with the User, and the Last 90% of Game Design: Play-testing, Balancing and Polishing
  3. Creating a Live Game or Game as a Service

7. Game as a Service

In the last chapter, Games as a Service the writer invites the reader to delve into the business model. To start, the writer introduces the common lingo that is used in the industry.

7.1. Key Performance Indicators

Key Performance Indicators (KPIs) are the metrics to measure performance that is usually related to financial data and user base. The following are common KPIs for a live game.

  • Retention: percentage of users who are coming back daily to the service after the day of the first install. In rolling retention, the user’s access is not necessarily daily. D1, D7, D14, D30, and D365 respectively indicate the data of users coming back the next day, within a week, a fortnight, a month, and a year.
  • Daily Active Users (DAU) and Monthly Active Users (MAU): how many users accessing the service on that day/month regardless of the frequency, similar to rolling retention.
  • Concurrent Users (CCU): how many users accessing the service at the time exactly.
  • Conversion Rate (CVR): percentage of users who convert from free playing users into paying customers.
  • Average Revenue per User (ARPU) and Average Revenue per Paying User (ARPPU): Usually calculated monthly or daily by dividing the revenue by the total users or total paying users. Average Revenue per Daily Active User (ARPDAU) is also a common KPI related to revenue per user.
  • Lifetime Value (LTV): How much money on average that the users spend on the service for the entire time. It’s a good idea to calculate LTV with the D1 retained user data instead of the entire user to weed out users acquired by badly targeted ads.

7.2. Marketing and Analytics Terms

  • Installs: the number of installation. Paid installs: installs coming from tracked, paid ads. Organic installs: any other untracked installs.
  • K-factor: a metric for virality, that is calculated from the average number of invites sent per user multiplied by the average number of new users coming from those invites.
  • Organic Uplift: a growth of organic installs. It may come from any untracked marketing, being featured in a marketplace, increased community activity, etc.
  • Click-Through Rate (CTR): the percentage of users who interact with an ad compared with the total number of views/impressions.
  • Cost per Installs (CPI) or acquisition cost: the marketing cost per number of installs attributed from that channel. The LTV must be well above the CPI to make sure the users’ spending will cover the cost of acquiring them and everything else. To make sure CPI is low, the marketing content must be tested and compared with competitive titles with a small scale campaign budget (about $500).
  • Cost per Thousand Impressions (CPM/Cost per Mile): the online impression data can help evaluate the profitability of untracked campaigns such as prints, tv ad and billboards.
  • Minnows, dolphins, and whales: a classification of paying users based on how much they spend; terms that are borrowed from the gambling industry.
  • Session stats: the number and length of the sessions.

7.3. Game Economy Terms in Free to Play Games

  • Freemium currency: soft currency; obtained by grinding. It can only be used for basic stuff.
  • Premium currency: hard currency; bought with real money or by winning a special event. It can be used to buy premium items, skip cooldown times, and some game mechanic advantages.
  • Taps and sinks: taps are where the resources come from and sinks are where they disappear into. To avoid inflation in the game economy, keep resource creation hard and sinks irresistible.
  • Energy, fuel, keys, sanity, etc.: a resource designed to limit the time spent in the game.
  • Gacha box: items containing random rewards.
  • Drop rate: chance percentage for a particular reward.
  • Pinch point: a point where the game becomes so difficult the player might consider using pain items to get through.
  • Pay-gate: a figurative gate that locks items from being accessed without spending hard money.
  • Grinding: doing repetitive missions, tasks, or actions to get a particular award.
  • Churn rate: the number of users who stops after playing regularly for a while.
  • Drop off points: a point in the game where users decide to stop playing and not coming back.
  • Retention funnel: chronological retention data on drop off points to find which parts of the game need improvement the most.
  • Pay-to-win: games that obviously show that non-paying users don’t have a chance to win a match with paying users. While it should be extremely hard to do, non-paying users should feel like they have a winning chance to avoid the pay-to-win label.
  • A/B testing or split testing: Testing configurations or features of the game to different groups of users to test which one is better. The consequence of the test should not be monetary to avoid the users feeling cheated by the game.

7.4. Monetization Vectors for Free to Play Games

The writer lists four emotion-driven vectors that keep the monetization model running, i.e. time, difficulty, playable and non-playable content.

The time vector is driven by anticipation and impatience. Time resource may take the form of an actual timer or is abstracted into a resource; e.g. energy or sanity. Users can pay to skip timers or by time resource.

The difficulty vector is driven by mastery and frustration. The difficulty can be introduced gradually, suddenly, or both. The gradual rise of difficulty helps to sell permanent upgrades as long term solutions. The sudden spike of difficulty can sell one-time items that help the player to overcome that one hard level. The difficulty vector is risky to exploit because a difficult point can turn into a drop off point and too many upgrades can steal the feeling of mastery.

The playable contents vector is driven by joy, curiosity and boredom. Playable contents can be permanent like map expansions, episodes after the first trial one, and more playable characters. The temporary playable content can also be sold, but the value and the time-limit of the content should feel fair.

The non-playable content vector is driven by pride, shame, amusement, and jealousy. Usually, the contents are cosmetic items or optional services like an account name change, server migrations, private chat channels, and so on.

7.5. Managing Game Economy Dynamics in a Free to Play Games

To maximize LTV, the writer proposes that the game developer should pick monetization strategy, adjust products bought with real money over time accordingly, and control player progression.

Things to consider in picking a monetization strategy is to understand the players’ profile and how much value you can sell. The players’ profile should tell if they have the money and are willing to spend it on microtransactions, collectables, or a complete game. The game developer’s ability to produce the level of content quality and quantity for the content also put a cap on how much the players can spend on the game.

The writer explains gacha and bundles as examples of free to play game products. The writer starts with the pillars of gacha design. They are the content’s quantity and quality, the player’s capacity to collect the content, the desirability of the content, the sustainability of content production, and the duplicate handling in the players’ collection. The writer emphasizes that gacha is all about the experience, so the act of opening the gacha packaging should involve perfectly flowing animation and actions. The act shouldn’t feel like a chore as it will be done hundreds of times. There should also an option to bulk open gacha boxes. Being consistent with gacha rarity rule is important. It helps players quickly react and buy a new class of gacha box because the rarity rule is known. The writer also mentions kompu gacha regulation in Japan and box gacha content rule.

Purchasing bundles with real money is a quick and simple way for players to obtain resources by bypassing the use of premium currency. Themed content bundles with sensible price are one of the best ways to generate revenue. The price should respect the expected value of the contents. The writer shows an example of calculating the expected value of the content in the section titled Utilizing EV in Bundle Creation. Then, the writer discusses the ways to find the best price point for bundles. One of the ways is to offer the same type of content but in different quantities. The writer also lists the rules of thumb for creating bundles. They are:

  • The bundle should be available for a limited time to create an urgency to buy. The bundles containing the best contents should be scheduled to avoid them competing with each other.
  • The number of options should not overwhelm the players. The developer can target select bundles to groups of players with similar purchasing behaviour instead of exposing all bundles to everyone.
  • The premium currency in bundles should be limited, so the players don’t feel the need to save it across bundle purchases. The act of spending the reserved premium currency can leave the players disappointed.
  • The bundle’s pricing should maintain the expected value of the content. The developer must avoid discounting too much (>30%) and too often.
  • The best content for bundles answers the players’ desires more than practical needs. Use the data of purchase history and wishlists to determine which content is the most desirable.

The writer continues by explaining the reasons why players are willing to spend money on the games. Some of them are opportunity, necessity, curiosity, long-term value, altruism, recognition, and peer-pressure. The developer should evaluate their players’ demographics and their relation to spending behaviours. The developer should also keep sustainability in mind by considering the players’ budget instead of maximizing short term profit and make the players regret their purchasing decision and drop off.

7.6. Game Live Operations

In the section called Live Operations, the writer starts by listing the main points of live-ops. They are content and feature update (events, bundles), balancing, customer support, and marketing. To maintain the operations, in addition to the core development team, new roles enters after a live game’s public launch starting as early as public beta or soft launch. They are the live operations manager, data analyst, community and customer support lead, marketing manager, and social media manager.

The live game matures after it runs public for 1 to 2 years, secures a stable revenue and it’s hard to distinctively grow the userbase anymore. After that, the live-ops team should be rationalized with management and automation tools. The essential tools to help a lean live-ops team are:

  1. Content Management Systems: systems that are configurable via files and editors for levels, quests, and events.
  2. Asset Streaming: systems to load new content into the game without having the player update the game manually. The game functions as an application to run content that can be downloaded later, piece by piece.
  3. Customer Relationship Management system: a system to read and write the player’s data for troubleshooting, e.g. enforcing bans, giving special gifts, account recovery, and any user-specific issues.
  4. Analytics Dashboard: a system to display and turn analytics data, usually an important and time-sensitive KPI, into actionable information. This dashboard should be as accessible as possible, e.g. displayed on the monitor in a hallway.
  5. Test environments: an isolated server or version of the game to deploy and test updates before releasing them to the public realm.
  6. Live Ops tools: a system to set up and create templates for live content such as bundles, event schedules, news blogs, and notifications.

The game must be balanced every time a playable content is added. The players need to be reassured the value of the content they bought doesn’t diminish because of the new content. To ensure balance the writer suggests:

  • Soft-launch and deploying to test environment first.
  • Use aggregated data instead of just that one complaint about balance.
  • Batch changes to avoid too much disruption in the live-ops schedule.
  • Avoid making extreme changes (positive/buff or negative/nerf) even though the players ask for it. A good way to neutralise an overpowered strategy is to nerf it by contrast; that is to show the players a new strategy that counters it by adding more content. The designer can also try shifting the meta; i.e. to plan events to encourage players to use certain strategies. The events and respective strategies can be changed periodically to keep the game fresh.
  • Keep the players updated with new changes to avoid rumours.

Planning live operations involve preparing and scheduling the following:

  • Minimum viable product on launch and the first weeks worth of contents and events.
  • A live-ops calendar for a few months ahead.
  • Content production pipeline for a few months ahead.
  • Live-ops improvement plans for a few months ahead.
  • Avoid making a rash decision that interferes with the plans.

A live-ops calendar can help in maintaining a stable schedule; in terms of content production and the players’ capacity to engage. It is a list containing the details of live-ops plans for the day. The writer provides an example of a live-ops calendar that consists of:

  • Game versions that the players have and configuration file/settings in servers. The environment must be ready for the next scheduled event.
  • Calendar of major real-world event & holiday.
  • Calendar of in-game events and details: name, start & end times, type, rewards, etc.
  • Calendar of bundle & premium content release.
  • Calendar of important updates on the game economy, e.g. gacha box content change.
  • Calendar of in-game notification and blog release dates.

The writer also proposes an example to avoid problems that require immediate fixing on the weekends. The client apps automatically download contents needed for weekend events days before, e.g. on Monday through Thursday. The content is not activated until the event starts. This way, the developer provides ample time for the store approval process and the players’ app to download the update.


That’s a lot for just one chapter at the end of the book! The topic of Live Game is new to me so I feel that a lot of the information in this chapter is important. That concludes my summary of the second technical book I read this year: Practical Game Design.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.