Mobile Game Design: Iteration vs. Planning, MVP = Dangerous!

Mobile game design typically follows two primary schools of design philosophy:

1. Iteration based design = Just get some core mechanics in and then keep iterating until you get something fun; some initial but not extensive design before development

2. Planning based design = Think through all of the features, every key screen, all of the dependencies and interactions between primary features before beginning any development

Generally iteration based designers often come from the PC world where folks are used to selling pre-packaged non-F2P games that have a high fun factor for a fixed one time fee. They also often come from the casual design space working on games with high retention and often low monetization.

In my view, we have way too many people who have taken iteration based planning too far. These are people who have adopted a religious view about MVP (minimum viable product) and have taken the MVP approach to the point that it has become a crutch and a poor excuse for not doing enough thinking through features. Adopters of this approach often make comments like:

• “Oh we can just iterate on that later.”

• “Don’t worry about monetization now, we just need to get it fun”

Unfortunately, non-technical designers don’t understand that game code is not an elastic resource. It’s not like building and rebuilding lego blocks. Unlike play-doh you can’t make major changes without significant cost: Because code (and especially game code which typically involves a fair amount of hardcoding) is relatively inelastic.

I’m going to take a slightly extreme view here and say that I believe that many iteration based game designers in the mobile, F2P based gaming space (not necessarily applies to paid apps) are dangerous and can destroy game teams with their laziness.

The new mantra for mobile game development process should not be about “MVP” with a focus on the “minimum” for developing a viable product but there should be something more.

Kim’s Law:

The mobile game space is too tough for people who aren’t willing to put in the time and effort to think through their designs.

Too often, I see the following types of scenarios:

• Half baked ideas that aren’t well designed or well specified get handed over to development

• Too many designers chasing the latest top grossing game design and trying to adopt new features into an existing game where those features don’t make any sense

• Not enough thought about how all of the features in a game work together and how they interrelate and have dependencies on each other

For all of you game designers that fall in this category I have the following message:

• Stop it! You are dangerous. You are burning out the devs. You are wasting precious time and resources that could have easily been saved with better planning. Speed to design = Delays to overall development. The rush to jam in new half baked features will incur eventual cost. Do your job!

So how do we do better planning?

Really it all comes down to the following key tasks:

1. UI: Make sure that the UI can support the feature you are designing. Make wireframes for all of the key screens in advance.

2. User Flows: Make sure every new feature has every screen and user flow accounted for and play tested in your head before the spec and before you hand it over to dev. What do I mean? See here: Mobile UI and Game Design: Screens vs. Flows

3. Edge Cases: Think through all of the major edge cases. What are edge cases? Edge cases are play situations that are outside of the normal flow of gameplay but still need to be designed. Make sure there are no major gotchas in the edge cases.

4. System Impact: Think through how this feature will impact your game balancing and economy. How does this impact other systems in your game. What about the UI to other parts of the game? Make sure it’s all consistent.

5. Design Impact: How will this new feature impact the overall user core loop, design objectives, and monetization? If you’re adding a new PVE feature to a PVP game this can be DEVASTATING. How will this impact monetization and your estimated game monetization (See: Monetization-based Game Design: ARPDAU Contribution). Think it the f*** through!

Finally, there are cases where iterative approaches situationally make more sense then planning based approaches. Experimenting with a new type of gameplay comes to mind where that part is the focus and key risk. Further, it’s not about OVER planning. You should do as much of the planning exercises I mention above as makes sense for your feature, the type of game, your objectives, etc. So your specific situation will determine the appropriate Maximum Viable Planning you do. There is not a cookie cutter answer for all situations.

But situationally, you typically want to do more planning with the following types of games:

• More complex: The more complex, interdependencies, and systems you will need to understand how your feature impacts everything else in the game.

• More UI: Related to complexity but the more screens you have

• More Systems: Generally the more hard-core your game is will typically mean more systems. In many cases with the launch of games like DOTA Legends in particular we are seeing lots of systems in games such as multiple PVE and retention based systems.

Graphical Overview: When to use Iteration vs. Planning based design?

In summary:

• I hope this message can help some of you out there increase your product's chance for success through better planning

• Know when situationally you should be more planning based vs. iteration based

• Use the exercises above to reduce iteration during the production phase of your game development; most of the planning should be done in your game's pre-production phase where wires and specs are cheap