作者：Joseph Kim

手机游戏设计通常都遵循了以下两种主要设计原理：

迭代设计=先获得一些核心机制然后保持迭代直至你创造出一些乐趣；这是开发前一些最初且未进行扩展的设计

计划设计=在开始任何开发前思考所有功能，每个关卡页面，主要功能间的所有关系与互动

通常情况下迭代设计师都是来自PC世界，即习惯于销售基于特定费用且带有较高乐趣元素的预先包装好的非免费游戏内容。他们通常是来自休闲设计领域，即致力于带有较高留存率与较低盈利性的游戏。

在我看来，有太多人在迭代设计方面做得太过火了。这些人都奉行了有关MVP（最简化可实行产品）的宗教观，并将MVP方法当成一种支柱以及未足够思考功能的撇脚借口。这一方法的采纳者经常会做出如下评论：

“我们可以在之后进行迭代。”

“现在不用担心盈利，我们只需要创造出乐趣便可。”

不幸的是，非技术性设计师并不能理解游戏代码不是一种灵活的资源。这与创建并重建乐高积木是不同的。与培乐多不同的是，你不可能不花费任何成本而做出重要的改变：因为代码（游戏邦注：特别是包含许多硬编码的游戏代码）是相对缺乏弹性的。

我将在此采取一种相对极端的看法并强调许多手机，免费游戏领域的迭代游戏设计师正处于一种危险的状态并且有可能因为自己的懒散而摧毁整支游戏团队。

手机游戏开发过程的新咒语不应该是专注于MVP，而应该着眼于更多内容。

Kim理论：

基于最大可行计划而开发最简化可实行产品

对于那些不愿意投入时间和精力去思考自己的设计的人来说，手机游戏领域会非常艰苦，

我经常会看到如下情境：

将一些未经过有效设计或完善的半成品理念落实开发

太多设计师追逐着最畅销的游戏设计并尝试着将新功能带到现有的游戏中，但事实上这些功能却一点意义都没有

未真正思考游戏中的所有功能是否能够有效地合并在一起以及它们之间是如何相互关联与互动

对于所有遭遇这些情境的设计师来说，你们该听听以下建议：

停下来吧！你真的非常危险。你正在摧毁整个游戏开发。你正在浪费宝贵的时间和资源（如果能够做出更好的计划你便能够有效节约这些时间与资源）。加速设计=延迟整体开发。急于添加一些全新的半成品功能只会提高开发成本。

所以我们该如何更好地进行计划？

这主要归结为以下几个关键任务：

1.UI：确保UI能够支持你正设计的功能。事先为所有关键页面创造示意图。

2.用户流：在提交开发前确保每一个新功能都拥有自己的页面，并且事先测试用户流。

3.边界情况：思考所有主要的边界情况。什么是边界情况？边界情况是常规游戏流以外但却仍需要进行设计的一些游戏情况。确保在边界情况中不会出现弹无虚发的情况。

4.系统影响：想想这些功能将如何影响你的游戏平衡与经济。这对于你的游戏中的其它系统会有何影响。UI对于游戏中的其它部分会有何影响。确保所有内容相一致。

5.设计影响：这一新功能将如何影响整体的用户核心循环，设计目标和盈利？如果你添加了新PVE功能到一款PVP游戏中，这将造成巨大的伤害。这将如何影响盈利以及你所预期的游戏盈利。请好好想一想这一问题吧！

最后，存在一些互动方法能够使计划方法变得更有意义的情况。尝试一种全新的游戏方法，并且该方法具有重要风险。此外，这并不是关于过度计划。你应该按照我上述的建议执行计划，如此才能确保你的功能，游戏类型，目标等等都具有意义。你所面临的特定情境将决定你所采取的最大化可行计划。并不存在适用于所有情境的唯一答案。

根据不同情景，你通常需要为如下游戏类型制定更多计划：

更复杂的：更多复杂性，相关性并包含更多系统；你需要理解你的功能将如何影响游戏中的所有内容。

更多UI：与复杂性相关但更加与你所拥有的屏幕相关。

更多系统：通常情况下，如果你的游戏更加硬核，那就意味着游戏拥有更多系统。在很多游戏发行案例中，如《DOTA Legends 》（以及许多复制品），我们便看到了PVE以及基于用户留存等多种系统的存在。

图像概述：何时使用迭代vs计划设计？

Screenshot(from gamasutra)

总结：

我希望本文能够帮助你们通过进行更好地计划而提升产品的成功几率。

你们需要根据不同情境了解何时应该侧重计划而何时又该侧重迭代。

利用上述实践去减少游戏开发的制作阶段的迭代次数；并且应该在前期制作阶段便完成大多数计划工作。

（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转发，如需转载请联系：游戏邦）

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

by Joseph Kim

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

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

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:

Develop a Minimum Viable Product but with Maximum Viable Planning

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 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 complexity, interdependencies, and systems involved; 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 (and the many clones) 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?

Screenshot 2015-02-17 19.49.00

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(source:gamasutra)