Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
February 25, 2020
arrowPress Releases

If you enjoy reading this site, you might also want to check out these UBM Tech sites:


"Key Risks" Based Mobile Game Pre-production

by Joseph Kim on 01/23/17 09:42:00 am   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


I initially published this post in my personal blog Check it out to learn more mobile gaming design techniques, analysis, and industry opinions.


Mobile game pre-production teams often focus on the wrong activities. An early focus on playables in software or building a game's core loop may be useful but may not be the best approach. Any team with limited resources should prioritize what's most critical to maximizing the success of a game.

Unfortunately, the most common approach I encounter shortcuts or skips planning and the pre-production process completely. Instead, many developers would rather jump directly to focusing on gameplay. In particular, most former console developers are guilty of this shortcutting.

To be clear, I fully understand the importance of gameplay prototyping in general. However, developers need to consider how to prioritize scarce resources. Developers should first identify key risks for a game's success and then focus resources on those risks as a priority. Gameplay prototyping may turn out to be the primary key risk, but without careful consideration, it may actually be something else entirely.

Let's take a step back for a moment and first think about the key objectives for pre-production. In my view, it should be as follows:

Primary Objectives of Pre-Production (Planning!):

  1. Develop a clear vision of the game design
  2. Estimate the game's financial characteristics
  3. Identify, characterize, and mitigate as much as possible the key risks for the game's success

Based on these objectives, I typically ask for (as a publisher) or develop (as a studio/dev) the following types of deliverables during Pre-Production:

Clear Vision
  • Key Screens/Flows
  • High Level GDD
Financial Characteristics
  • Monetization Table
  • Simple Financial Model
Key Risks
  • Key Risks Table

I've written to some degree about some of these deliverables before:

Let's now focus on the Key Risks aspect of pre-production and the specific deliverable I'm calling the Key Risks Table (KRT).

The Key Risks Table:

The Key Risks Table simply lists the top 3 or 4 risks that could prevent a game from becoming successful. Further, we also then suggest "prototypes" to help prove out or mitigate those risks to the degree possible. Not all risks can be completely mitigated. However, this practice will help a dev team better characterize and understand those risks. It's critical to understand and mitigate as much risk as possible before proceeding further with a big budget game production.

This practice of focusing on key risks during pre-production was conceived from conversations I had with game designer Alex Mandryka. In particular, Alex pointed me to a fairly seminal presentation on game prototyping by Chris Hecker called Advanced Prototyping.

The results from the "prototypes" developed from the KRT should help a team either:

  • Determine the current game doesn't make sense and to then abandon the project in favor of another project
  • Modify the game design or other aspects of the game to make the game more capable of achieving success
  • Confirm whether the risk will not be an issue

Let's look at a specific example just for the purpose of illustration: imagine we are thinking about developing a synchronous, real-time multiplayer PVP mobile car racing game based on the Mattel Hotwheels IP.

Example Key Risks Table (KRT):

An example of what a Key Risks Table for this kind of game could like is shown below:

Control Scheme The control scheme will make the game a significantly better user play experience than similar current games on the market
  • Build a quick throwaway prototype in Unity or Flash that demonstrates the control scheme, compare with existing market emulation targets
Strength of IP The Hot Wheels brand will drive significant organic installs to the game enabling the game to be profitable with low LTV (~$0.50)
  • Create a base financial model to estimate organic downloads via comps (e.g., Sensor Tower data)
  • Conduct a Facebook ads test to determine relative interest in the concept and IP to modify our model
Monetization Potential The specific systems design will enable the game to achieve best in class monetization for its genre (~$0.75)
  • Compare relative monetization of systems design to other games in its genre or comparable systems in other genres
  • Build out monetization table and use best judgment to form LTV hypothesis
Importance of Real-time, Synchronous Gameplay Players will dramatically prefer playing a competitive, real-time, synchronous racing game against other players rather than a PVE based game or an async, ghost-mode based game
  • Focus group test with gameplay prototypes or high production value wireframes
  • Facebook ads test with clear messaging of sync vs. async racing

These are just examples, but the point of the exercise should be clear:

  • Agree upon what the key risk for the game's success actually are
  • Determine how to best mitigate or better characterize the risk through various "prototypes".

Note that the "prototypes" could be other games on the market, wireframes, software prototypes via Flash or Unity, or anything else that helps drive better clarity on the risk.

Also, note that I described the Key Risks as specific hypothesis statements. I like these types of binary points of view. A binary perspective helps to crystallize the focus of the prototypes and to drive towards a specific true or false conclusion.


A team should be very careful about spending any time on development before having a deep understanding of a game's key risks. Often, much of a mobile game's design and execution risk can be mitigated by very cheap means e.g., paper and pencil or through digital wireframes. Hence, it's important to understand what those key risks are and then to design quick and dirty approaches to understanding those risks better.

Related Jobs

Double Fine Productions
Double Fine Productions — San Francisco, California, United States

Multiplayer Programmer
Double Fine Productions
Double Fine Productions — San Francisco, California, United States

Senior Gameplay Programmer
Double Fine Productions
Double Fine Productions — San Francisco, California, United States

Gameplay Programmer
Insomniac Games
Insomniac Games — Burbank CA or Durham NC, California, United States

Mid to Senior Engine Programmer (Tools)

Loading Comments

loader image