作者：Christer Kaitila
你今年可以制作12款游戏，听起来很不可思议？不，试试这个已经有人实践过的简单游戏开发方法，你就会发现每月一款游戏并非神话。
McFunkypants方法
在此我将与各位分享我自己的游戏开发方法。当然，这并非制作游戏的唯一系统，它只是一个充满我个人建议和技巧的工具箱，我就是用它来战胜包括“拖延症”、功能蔓延、孤注一掷以及无限乐观主义在内的诸多恶魔。
在2012年我成功实现了在12个月内制作12款游戏的目标。令人惊讶的是，这并非那么困难的目标，我在此所花费的精力甚至比过去几年的许多失败项目还要少。
那么这其中有什么区别呢？这是一个更为成熟，更有经验，更为务实和更不乐观主义的方法。不要误会，乐观主义本身并没有什么错。事实上，我还鼓励大家怀有乐观主义的心态。如果没有乐观主义，我们没有人会涉水游戏开发领域。没有乐观主义，你永远一事无成。在此我只是主张以更低调谦逊的方法制作项目。
在此要声明，我所分享的技巧并不一定适用于每个人，但如果你能够因此而成功实现一个月开发一款游戏的目标，那我就会备感欣慰。
设置多个终点
90%的游戏项目永远无法见到天日。我个人经历就足以证明这一点。我制作游戏也有20多个年头了，在所有我满怀热情，计划周全，穷尽想法开始制作的游戏中，仅有一小部分最终获得发行。这是我多年的心病。我是一个优秀的程序员，也能够制作一些得体的美工，也有足够的想法支持自己的计划，但究竟何时可让游戏见光却真是一个难以捉摸的目标。
为什么？因为真正执行所有这些令人兴奋的计划总会遇到各种我无法预料的挑战。另外，我对每个项目所怀有的热情也总会随着终点来临而逐渐消退。这个过程会很困难，你会花光所有资金，但却还是超过了截止日期，开发乐趣也就荡然无存了。剩下的就只有许多开发者称之为“墙壁”的埋头苦干了。
inde_developer(from david-amador.com)
墙壁是软件开发项目中不那么有趣的一个节点。此时你已经为一切容易执行的内容编完程序，剩下的就是一些杂活：修复漏洞，棘手的代码，重复返工，超过你控制范围的事情，遗漏的关卡或音效，安装问题，用户测试，你无法重制的报告漏洞，以及应用商店审核等。
完成一个游戏项目好比是攀向一座高峰。运气够好的话，你只要穿着运动鞋，带着雄心就行了——但这通常会导致灾难性的失败。但我这些自由攀登的山峰上，我一开始就会准备好绳索，研究眼前的石壁，记录可能很棘手的片段，测量自己的步伐。
降低风险：经常保存
想象一下如果一次都不保存就直接完成游戏会是怎样。这正是许多游戏开发者制作软件的习惯——孤注一掷，不是让它横空出世就是将其彻底抛弃。中间没有任何商量的余地，不考虑任何意外情况。这是注定会失败的方法。
你这样反复数次后，就会开始看到一个模式：没有保存习惯，一条路走到黑的乐观主义计划通常风险极大。为何不降低风险，在开发过程中设置多个保存点？
从开工到结束
在此我将以自己在某个周末编写的游戏为例解析这些要点。
1.头脑风暴阶段
头脑风暴最棒。我喜欢草草记下大量关于道具类型、宝藏、任务、角色姓名、关卡理念或构建模块等大量列表。这很有趣，也是一种开始制作游戏的绝佳方法。但这里有个潜在问题：头脑风暴本身注重的是数量而非质量。我甚至可以将头脑风暴戏称为“废话连篇”的过程。
如果你的每个项目都要从大规模的头脑风暴入手，很好。但最好要确保不要等到你已经将原计划列表中99%的内容纳入“下一版本”计划列表时才开始动工。
2.制定两个列表：需求和渴望
有一个削减常规游戏开发头脑风暴那种大规模、功能蔓延、过于乐观基调的绝佳方法就是，缩小范围评估各个要点，例如：
*原创性
*可行性
*开发难度
*美工需求
*玩法趣味性
*编程趣味性
筛选你的列表，摒弃大多数想法。将其中多数想法（游戏邦注：尤其是最困难的理念）保留到以后的项目。
针对每个打勾的项目，自问它是一个必须选项，还是优化选项？对于第一个原型，要集中关注其根本元素，因为没有这些元素原型就不会具有可行性。
其次要思考：每个项目的执行难度有多大？这是否需要大量编码或内容？此时可以大胆以一种懒惰的方法执行计划，因为你不久就会发现自己不得不将许多最棒的想法搁置一边，因为执行这些理念需要耗费大量工时。所以此时无需太勤快，选择那些最容易创造的基本功能即可。
提取你最喜欢，并且最容易执行的单个核心游戏机制理念。把一件事情做好，总比只完成一堆半成品要强。
这就是所谓的“最小可行产品”理念。
3.编写“电梯游说稿”
当你自己描述这个最小可行产品，也就是能够用一句话描述整个基本游戏理念，最多只强调一两个方面，那就是时候进行润色了。
要假设你需要在电梯中向一名主流游戏发行商高管讲述自己游戏的可行性。你只有10秒时间，那么你可以在如此短暂的时间中充满热情、兴趣而富有感染力地描述自己的游戏，从而获得一笔可观的预付特许使用金和一份发行合约吗？
写下这个电梯游说稿。进行修改编辑。使其简明扼要。要假想你是在为游戏包装盒写文案，想象一名玩家拿起这个盒子并转一面会看到什么文字。他们有成百上千款其他游戏可供选择，但他们决定给你几秒时间以便他们做出决定。那么你的文案能否成功推销游戏？
如果你向一位好友（或者一名陌生人）朗读这个文案，他们会感兴趣，兴奋还是怀有极大热情？如果对这些问题你都能给予肯定回答，那就说明你走上正轨了。
以下是我为最近制作的一款游戏所描述的电梯游说稿：
“你是个坏蛋。有两名情人极想拥抱对方，你的任务就是通过建围墙来拆散他们。这是一款基于A-star寻径的回合制策略谜题游戏。”
4.绘制粗线条的故事板漫画
下一步，就是在你开始编程或创造大量内容库之前，绘制游戏运作的草图。你不需要什么美术技能，只需要画一些黑白线条的缩略图即可。此时你的目标是以可视化形式呈现整个游戏由始至终的情况。
在一张纸上绘制一系列面板，先画一个类似以字幕或者主界面的东西。在之后的面板中绘制下一幕场景。这可以是游戏介绍，也可以是第一个关卡。总之就按照你玩游戏的顺序一幕幕接着画下去。你需要绘制的面板越多，就表明你制作游戏时需要完成的任务量越大。因此，最好在一张纸上完成所有东西。最好不要超过12个面板。
以下是我最近编写的《Pathos》这款谜题/策略/战术游戏中的游戏机制草图：
mockup(from gamedev)
我用了各类游戏标题的变体假装A-star寻径算法，并加入许多《龙与地下城》RPG风格的图片，因为这正是我的灵感来源。我喜欢奇幻世界地图，并认为这将成为一个理想的关卡选择屏幕。
制作一个快速故事板的原因是，它会让你更准确地描述出游戏内将发生的情况。此外，它还可以视觉化地列出内容。例如，你在一个屏幕中可以放置多少个按钮，虚拟角色有多大，移动方向，积分或命值条应放置在哪等等。这些缩略图是一种从设计师角度看待游戏的绝佳方法。它们可以在你编程的时间提供许多帮助。例如，通过这种简单的布局你就知道自己需要绘制多少图标或按钮图像，关卡美术内容有什么需求，游戏将呈现什么面貌。
如果你的漫画现在看起来还不像是有趣的游戏，那么你可能就得先弄清楚需要进行哪些调整再继续投入开发。如果漫画看起来无休无止，那么你就需要提醒自己这种工作量过于庞大，你得削减过场动画或关卡、玩法元素的数量。
同电梯演讲一样，这种一页式的粗线条故事板也是去粗取精的好方法。将它展示给朋友看，看看他们是否会喜欢玩这种游戏，他们是否认为这值得你投入时间。
5.制作无美工的早期可玩版本
下一步就是在第一天就制作一个可玩游戏。没有字幕，只有一个关卡，以及基本的玩法机制。
它不需要很棒，也不需要很完整，当然也不需要那么有趣。这个步骤就是你的最佳武器。让你挑战自我创造一个能够在最初几小时编译和运行的代码库。这个版本应该能够接受输入，移动、具有动画，并触发一些声音。
你越早完成这种早期可玩版本，就越有可能成功。这将成为你的首个“保存点”——这相当于你攀峰的时候可以在半途休息的一个高地，经代表游戏的前景。由此开始，你就可以根据自己的需要润色游戏，因为你知道自己已经拥有一个“可行”的版本了。
以下就是我这个项目的初级原型。它含有简单可行的寻径元素，没有美术，只有一些彩色的方形。
prototype(from gamedev)
到达这一阶段需要投入大量编程时间。我估计这个项目开发周期中有半数时间投入于令游戏呈现上图这种效果的阶段。这种无美术的方法很适合编程：它更节省时间，可以助你找到漏洞，迫使你关注游戏的“感觉”。
无美工的原型还有另一大优势：在之前的游戏中，我会用Photoshop制作好看的模型，并搜集大量可爱的精灵以备游戏所用。在开发完成后，总要更换、调整或抛弃大量的美术内容。我在编程之前浪费了太多时间制作游戏的美术内容。现在我已经明白技术规格以及不断发展的玩法机制意味着，你一开始做的许多内容最后都不会派上用场。
6.开始润色MVP的外观
当你所制作的游戏机制开始运行时，你就可以为自己的最小可行产品（MVP）进行润色。在这个阶段，你还是没有一个主菜单或字幕，但游戏规则及移动方式应该已经到位，以覆盖主要机制。
现在你可以开始为精灵准备特定的像素尺寸，决定布局，颜色方案以及你需要在屏幕上呈现多少贴图，并开始将高质量的美术内容注入游戏世界。这也是试验游戏运行性能以及处理技能局限性（例如保持良好的帧率，让游戏不超过带宽或纹理大小）的时候。
在我的示例项目中，我只使用了一些占位符精灵。每一个与另一个之间的距离都要经过测量：
screenshot(from gamedev)
7.解琐成就！
好消息是，这就是你的下一个“保存点”！你已经拥有一个“可行”的游戏。你可以点击屏幕看到一些发生情况。这里没有人物只有一个关卡，但至少它是你可以展示给好友让他们试玩的东西。你已经有了一些可以编译的内容。
此时我们的目标是功能，也就是一些你可以暂时中止，但却已经有些可以试玩的东西。它可能与有趣根本就沾不上边，或者外观极为丑陋，但这一点都不重要。至少，你有一个没有编程错误的代码项目，并且它能够传递一些内容。
你只有当你完成这个“初级可玩版本”时你才有可能到达终点，因为这时你才可能推出令人信服的产品。
8.一次只专注于一项功能
现在核心玩法机制已经到位，你就可以着手开发更有趣味环节了。也许你会选择先添加一些关卡，编写一些对话，或者为自己的游戏世界开发一些角色。也许你还认为游戏应该含有一个很棒的粒子系统，很酷的音乐，或者高分排行榜。那么，现在就可以开工了！
但要记住一件事：一次只能专注于一件事情。要专注于一项任务，直到其基本成型后才能继续处理下一项。
此时你可能厌倦了老是做同一件事情，需要先暂停一下。这也无妨，但要保持自律状态，还是要继续完成最小的一个系统，直到它进入那种准备就绪的状态。
例如，在执行战斗、命值或粒子特效时，要专注于角色移动和碰撞检测，直到你确信角色能够移动、撞到墙壁，回应键盘、鼠标或摇杆的控制输入。
此时你才能着眼于武器，跳跃等高级移动功能，检测玩家是否接触到熔岩并且受伤等开发内容。
尽量以线性方式展开工作，你会发现自己不需要同一时间处理多个问题。你可以一次仅专注于一项任务，而不是被50个不同类的漏洞所淹没。这是保持动力、注意力和热情的关键。同时遇到太多需要解决的问题，最容易令你因为受挫而心生退意。
正如有漏洞的堤坝一样，只有一个漏洞尚能修补，而如果是50个漏洞同时出现，如果你还不能修复一个漏洞就要奔赴另一个挑战，你很快就会发现自己处于一团糟的境地，这会让你产生极大的恐惧感。
9.继续向保存点前进
在游戏开发生涯中，你每完成一个MVP或可玩原型，或游戏的可发布版本，你都相当于是创造一个保存点。
要记住将这些可玩版本保存在工作文件夹之外的地方。使用版本控制方法，将其置于你的备份硬盘中。以邮件形式发送给游戏测试者。无论此时你在做什么，都要确保自己如果搞砸了一切，还有退路可走。
要坚持以创造多个迭代性优化，以及逐渐增强运行功能的可执行文档为目标。如果你经常忘了备份游戏，必要的时候可以公开情况，这样你就会开始紧张了。
一般来说你将会有很长一段时间用于寻找漏洞。当你发现游戏已经基本上没有功能性问题时，要保存一个备份，这就是你的另一个保存点。
以上提到的线性、迭代方法也适用于你的美术内容或游戏关卡。一次性完成一个关卡的润色。这样如果你没有时间、资金、耐心或者热情去完成所有的99个关卡时，至少你已经有三四个准备充分，值得骄傲的关卡。
简单地说，此时一定要确保你手头上已经有一个随时可以上线的游戏版本。毕竟，谁也不知道明天和意外哪个会先到。为了预防万一，你最好不要在这些保存点上出现差错。
迭代、性线、按步骤，一次一个任务的开发方法就是12个月制作12款游戏的成功秘诀。
10.到达终点！
当你到达一定保存点时，你的游戏将会呈现很棒的效果。此时，你才能确定项目大功告成的时间。要认识到你永远无法将最初头脑风暴文件的一半功能添加到最终成品中。但这些内容很可能变成你第二个版本的元素。
以下是我这个示例项目的成品。此时我已经准备推出游戏。我更改了名称，添加了一些很棒的美工，为我的关卡编辑器编写了一个分析程序，并找了一些音效和音乐内容。这是一款游戏，具有可玩性，我为它而骄傲。我将其称为《Pathos》，下面就是它的最终面貌。
title-screen（from mcfunkypants)
pathos-map(from mcfunkypants)
canvas(from mcfunkypants)
记住：要接受自己的局限性
所有的游戏开发者都是充满激情、创意的人。不幸的是，正是这种无穷的热情和创意让我们深陷麻烦。作为乐观主义者，我们都总会为项目抱有一个远大的期望：心目中的游戏成品就像薄煎饼一样畅销。
这个项目的每个环节听起来都像你真的能够轻松做到一样——事实也确实如此。但是，如果你将每个任务加起来，就会发现制约因素并不在于你的能力，而在于你的时间有限。
记住你在主机上玩的多数游戏，背后都有持续投入数年时间的上百名全职开发人员。如果你是试图与这些团队相抗衡的单人开发者，你就得计算清楚他们的工作时间远超过一名独立开发者终身寿命。
你还得接受一个事实，你一开始的目标不可以太高（游戏邦注：除非你想投入数年开发一款游戏），这样才有可能完成项目。要考虑到优秀独立游戏平均利润也不过数千美元，你不可以在游戏上投入成百或上千小时，除非你笃定这款游戏一定会成为惊世之作。你需要设计那种只需20或50小时工作就成完成的游戏。
无论如何，可以大胆假设——但要小心求证。要创造最小可行产品，如果得到测试人员的认可，那就添加更多内容，并将其称为2.0版本。
记住：要接受不完美
完美实际上是一种不可能达到的境界。你得收敛你的骄气接受自己的不完美。如果忽略了这一点，你就可能把这自己一直绑在这个项目上。记住，你可以一直制作续集。在项目妥当时就可以发布游戏，虽然你可能觉得它还可以不断完善。因为这不但可以为你减轻压力，还可以让你获得一些成就感，但游戏到达玩家手中时，他们可能还会提出一些你永远无法想到的新建议。
记住：尽早发布，经常更新
在你没有时间，精力，资金或动力的时候，那就发布已经完成的版本，吧。如果你坚持那套保存点系统开发方法，你就该在项目任何阶段都有一个可玩版本，即便你的功能清单上还有许多内容尚未落实。这没有关系。
“尽早发布，经常更新”已经是被许多成功开发者反复证明的真理。你需要玩家反馈，现实世界的测试。在暗无人处编程，直到游戏最终见到天日，这是一种错误的观念。首先，你只是通过自己有限的视解看待自己的游戏。因为长时间看同一件事物时，你的大脑就开始麻木了，需要他人不同的眼光和视角来补充见解。
你可能会发现一些机制，虽然在理论上看很棒，但落实之后却很无聊或令人受挫。
除此之外，尽早发布并经常更新的游戏可以获得更多曝光度。你更有机会进入“最值得关注的新游戏”榜单，可以吸引粉丝。你可以让更多人测试自己的游戏，并获得将影响游戏设计的有用建议。
玩家可能会提供一些让你意外的批评或称赞。而你认为很重要的功能可能却会遭到冷遇，你认为不重要的元素反而博得众人青睐。总之要关注公众对游戏的反应并及时作出回应。这可以为你节省时间，免去一些棘手问题。这也会为你未来的游戏发布找到方向。最重要的是，这可以为你带来新粉丝，支持者和更大的动力。
现在开始编程吧！
既然你已经有了一点动力，了解了我个人的游戏开发方法，我鼓励你现在就下线开工吧。调查或计划得太久可能会浪费时间和精力。有时候你需要的只是创建一个新文件夹，创造一个空白的项目，并开始编码。发动你的游戏开发引擎吧！
如果你遵从了这个基本的游戏开发方法，我相信你会有不少收获。其中最主要的就是减少压力，让你的开发过程更有趣，更实际，这种保存点系统也更可能获得玩家反馈。最后，将项目分解为更小的部分，你就有可能在今年每个月都发布一款游戏了。
原文发表于2013年1月24日，所涉事件及数据以当时为准。