手机游戏设计通常都遵循了以下两种主要设计原理：
迭代设计=先获得一些核心机制然后保持迭代直至你创造出一些乐趣；这是开发前一些最初且未进行扩展的设计；
计划设计=在开始任何开发前思考所有功能，每个关卡页面，主要功能间的所有关系与互动。
通常情况下迭代设计师都是来自PC世界，即习惯于销售基于特定费用且带有较高乐趣元素的预先包装好的非免费游戏内容。他们通常是来自休闲设计领域，即致力于带有较高留存率与较低盈利性的游戏。
在我看来，有太多人在迭代设计方面做得太过火了。这些人都奉行了有关MVP（最简化可实行产品）的宗教观，并将MVP方法当成一种支柱以及未足够思考功能的撇脚借口。这一方法的采纳者经常会做出如下评论：
“我们可以在之后进行迭代。”
“现在不用担心盈利，我们只需要创造出乐趣便可。”
不幸的是，非技术性设计师并不能理解游戏代码不是一种灵活的资源。这与创建并重建乐高积木是不同的。与培乐多不同的是，你不可能不花费任何成本而做出重要的改变：因为代码（游戏邦注：特别是包含许多硬编码的游戏代码）是相对缺乏弹性的。
我将在此采取一种相对极端的看法并强调许多手机，免费游戏领域的迭代游戏设计师正处于一种危险的状态并且有可能因为自己的懒散而摧毁整支游戏团队。
手机游戏开发过程的新咒语不应该是专注于MVP，而应该着眼于更多内容。
Kim理论：
基于***可行计划而开发最简化可实行产品。
对于那些不愿意投入时间和精力去思考自己的设计的人来说，手机游戏领域会非常艰苦。
我经常会看到如下情境：
将一些未经过有效设计或完善的半成品理念落实开发；
太多设计师追逐着最畅销的游戏设计并尝试着将新功能带到现有的游戏中，但事实上这些功能却一点意义都没有；
未真正思考游戏中的所有功能是否能够有效地合并在一起以及它们之间是如何相互关联与互动。
对于所有遭遇这些情境的设计师来说，你们该听听以下建议：
停下来吧！你真的非常危险。你正在摧毁整个游戏开发。你正在浪费宝贵的时间和资源（如果能够做出更好的计划你便能够有效节约这些时间与资源）。加速设计=延迟整体开发。急于添加一些全新的半成品功能只会提高开发成本。
所以我们该如何更好地进行计划？
这主要归结为以下几个关键任务：
-
UI：确保UI能够支持你正设计的功能。事先为所有关键页面创造示意图。
-
用户流：在提交开发前确保每一个新功能都拥有自己的页面，并且事先测试用户流。
-
边界情况：思考所有主要的边界情况。什么是边界情况？边界情况是常规游戏流以外但却仍需要进行设计的一些游戏情况。确保在边界情况中不会出现弹无虚发的情况。
-
系统影响：想想这些功能将如何影响你的游戏平衡与经济。这对于你的游戏中的其它系统会有何影响。UI对于游戏中的其它部分会有何影响。确保所有内容相一致。
-
设计影响：这一新功能将如何影响整体的用户核心循环，设计目标和盈利？如果你添加了新PVE功能到一款PVP游戏中，这将造成巨大的伤害。这将如何影响盈利以及你所预期的游戏盈利。请好好想一想这一问题吧！
***，存在一些互动方法能够使计划方法变得更有意义的情况。尝试一种全新的游戏方法，并且该方法具有重要风险。此外，这并不是关于过度计划。你应该按照我上述的建议执行计划，如此才能确保你的功能，游戏类型，目标等等都具有意义。你所面临的特定情境将决定你所采取的***化可行计划。并不存在适用于所有情境的唯一答案。
根据不同情景，你通常需要为如下游戏类型制定更多计划：
-
更复杂的：更多复杂性，相关性并包含更多系统；你需要理解你的功能将如何影响游戏中的所有内容。
-
更多UI：与复杂性相关但更加与你所拥有的屏幕相关。
-
更多系统：通常情况下，如果你的游戏更加硬核，那就意味着游戏拥有更多系统。在很多游戏发行案例中，如《DOTA Legends 》（以及许多复制品），我们便看到了PVE以及基于用户留存等多种系统的存在。
图像概述：何时使用迭代vs计划设计？
Screenshot(from gamasutra)
总结：
我希望本文能够帮助你们通过进行更好地计划而提升产品的成功几率。
你们需要根据不同情境了解何时应该侧重计划而何时又该侧重迭代。
利用上述实践去减少游戏开发的制作阶段的迭代次数；并且应该在前期制作阶段便完成大多数计划工作。
