手游设计理念典型遵循了设计哲学的两个基本学派：
- 基于迭代的设计=只是用一些核心的机制，然后继续迭代，直到开发出一些有趣的东西，这是一种在开发之前所使用的比较原始而且并不广泛应用的设计方法。
- 基于规划的设计=在开发之前思考所有的功能点，每一个关键的场景，所有基本功能的依赖关系和交互。
一般来说迭代设计的设计者们通常来自PC领域，他们常预售具有很高娱乐性的一次性的付费游戏，也有来自设计休闲类游戏的游戏从业者用迭代法设计具有高留存和低盈利的游戏。
在我看来，我们有太多的人采用了基于迭代的设计并持续下去。这些人采取了MVP（最小可行性产品）的观点，他们把MVP方法看成一个核心，一个支柱和一个不去充分思考所有功能的可怜的借口。使用这种方法的人们通常会做以下这样的评论：
- “我们可以之后再迭代”
- “现在别担心盈利问题，我们就是需要让它好玩”
不幸的是，非技术人员不理解游戏代码并不是一个弹性资源，它不像搭建和重建乐高积木。不像培乐多彩泥，没有大量的资源消耗很难做出本质上的改变：因为代码是相对缺乏弹性，尤其是游戏代码通常涉及大量的硬编码。
在这里我将要采取一种稍微极端的观点，我认为很多基于迭代方法的免费游戏领域，手机戏游设计者不一定适合付费模式，很危险的，并且由于它们的惰性可能摧毁整个游戏团队。
对于开发一个可行性的产品，在手游开发过程中新的口头禅不应该是关注“MVP”中的“Minimum”（最小），而应该更多其他的东西。
Kim定律：在具有***可行性计划的基础上开发最小可行性的产品。
对于那些不愿投入时间，不愿付出努力思考他们设计的人来说，手游领域太难了。
我常常看到以下类型的情景：
- 不是精心设计，并且不具备详细说明的半成熟想法移交给开发部门
- 太多的设计者追逐***最畅销的游戏设计，并且试图把新的功能应用在现有的游戏中，而这些功能并没有任何意义。
- 没有深入的思考一个游戏中所有的功能应该如何在一起运作并且如何相互关联，相互依赖。
对于上面这类的游戏设计者们，我有以下建议：
- 停下来吧！太危险了！你在摧毁开发，正在浪费宝贵的时间，也在浪费资源，而这些资源如果在有更好的计划的情况下原本可以被更好的利用。加快设计=延误整体开发。在半成熟的功能方面急于求成会导致最终的成本浪费，做好你的工作！
那么我们如何更好的设计呢？
其实所有的设计都归结于下面这些关键任务：
- UI: 确保UI能够准确表达你正在设计游戏的特点，并提前制作所有关键示意图。
- 用户引导：确保每个新功能都有使用场景和用户界面，在上交到研发之前在你脑中先进行游戏测试。我的意思是：移动UI和游戏设计：体验场景变化和用户引导
- 边缘情况：思考所有主要的边缘情况。边缘情况是什么？是在正常游戏流程之外的情况，但是仍需要设计。确保在边界范围内没有主要的问题。
- 系统影响：思考这个功能将对你的游戏平衡和经济有何影响。在你的游戏中这个又是如何影响其他系统的。UI对于游戏中的其他部分有何影响，确保它是一致的。
- 设计影响：这个新功能将对整体用户核心循环，设计目标和盈利有何影响，如果你在一个PVP游戏中增加一个新的PVE功能，这可能是毁灭性的。这将很影响盈利和预估游戏的盈利。（基于货币化的游戏设计：ARPDAU--传送门点这里）做之前先想好！
***，在某些情况下，迭代方法比计划方法更有意义，比如突然想到尝试一种新游戏类型的重点和关键部分。更进一步说，这不是关于全局规划。你应该尽可能多的做一些上面提及的规划练习，为了你的游戏功能，游戏类型，目标等等。所以先确定具体情况适合你的***可行性计划，没有一个***的答案可以回答所有的情况。
但某些情况下，对于以下类型的游戏通常想要做更多的规划：
更复杂：越复杂、越相互依赖，越系统化，那么就越需要理解你的功能如何影响游戏中的其他功能。
更多UI：越多UI越复杂，但你也有更多的场景放更多的UI
更多的系统：通常你的游戏有越多的硬代码那也意味着有更多的系统。在很多情况下推出的游戏，尤其像刀塔传奇，在游戏中我们看到很多系统，比如多人PVE和基于留存的系统。
图形概述：什么时候使用迭代设计vs.规划设计
总结：
我希望这个文章可以帮助你们通过更好的规划获得更多成功产品的机会。
知道在什么情况下应该更多的规划设计而不是迭代设计。
在游戏开发制作过程中使用上面的练习来减少迭代，大部分的规划都应在游戏前期创作阶段完成，这一阶段成本是***的。
