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 any team with limited resources/opportunity should prioritize what’s most critical to maximize the success of the game.
Unfortunately, the most standard 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.
That’s not to say that gameplay prototyping isn’t important, rather that the developer should realize what the key risks for a game’s success are and to focus on those. It may be gameplay prototyping but 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!):
- Develop a clear vision of the game design
- Estimate the game’s financial characteristics
- 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 is simply a table that lists what the top 3 or 4 risks that could prevent a game from becoming successful are and to also list the planned “prototypes” to help prove out or mitigate those risks to the degree possible. Not all risks can be completely mitigated but this practice will, at a minimum, help a dev team better characterize and better understand a games risks 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 and from a fairly seminal presentation on game prototyping Alex pointed me to 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.
An example of what a Key Risks Table for this kind of game could like is shown below:
|Key Risk||Hypothesis Statement||"Prototype" / Mitigation|
|Control Scheme||The control scheme will make the game a significantly better user play experience than current games on the market||Build a quick throwaway prototype in Unity that demonstrates the control scheme and compare with existing games on market|
|Strength of IP||The Hot Wheels brand will drive significant organic installs to the game making the game profitable||- Create a base financial model to estimate organic downloads via comps.
- Conduct a FB ads test to determine relative interest in the concept and IP to modify our model
|Monetization Potential||The systems design in the game will help the game achieve best in class LTV of over $0.75||- Estimate LTV based on system design surfaced from Key Screens and study of Monetization Table|
|Importance of Real-time, Synchronous Gameplay||Players will dramatically prefer playing a real-time, synchronous racing game against other players rather than playing a PVE based racing game or an async ghost mode game.||- Focus group test with gameplay prototypes or wireframes|
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 to help 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 when much of a mobile game’s design 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.