作者：Christer Kaitila

你今年可以制作12款游戏，听起来很不可思议？不，试试这个已经有人实践过的简单游戏开发方法，你就会发现每月一款游戏并非神话。

McFunkypants方法

在此我将与各位分享我自己的游戏开发方法。当然，这并非制作游戏的唯一系统，它只是一个充满我个人建议和技巧的工具箱，我就是用它来战胜包括“拖延症”、功能蔓延、孤注一掷以及无限乐观主义在内的诸多恶魔。

在2012年我成功实现了在12个月内制作12款游戏的目标。令人惊讶的是，这并非那么困难的目标，我在此所花费的精力甚至比过去几年的许多失败项目还要少。

那么这其中有什么区别呢？这是一个更为成熟，更有经验，更为务实和更不乐观主义的方法。不要误会，乐观主义本身并没有什么错。事实上，我还鼓励大家怀有乐观主义的心态。如果没有乐观主义，我们没有人会涉水游戏开发领域。没有乐观主义，你永远一事无成。在此我只是主张以更低调谦逊的方法制作项目。

在此要声明，我所分享的技巧并不一定适用于每个人，但如果你能够因此而成功实现一个月开发一款游戏的目标，那我就会备感欣慰。

设置多个终点

90%的游戏项目永远无法见到天日。我个人经历就足以证明这一点。我制作游戏也有20多个年头了，在所有我满怀热情，计划周全，穷尽想法开始制作的游戏中，仅有一小部分最终获得发行。这是我多年的心病。我是一个优秀的程序员，也能够制作一些得体的美工，也有足够的想法支持自己的计划，但究竟何时可让游戏见光却真是一个难以捉摸的目标。

为什么？因为真正执行所有这些令人兴奋的计划总会遇到各种我无法预料的挑战。另外，我对每个项目所怀有的热情也总会随着终点来临而逐渐消退。这个过程会很困难，你会花光所有资金，但却还是超过了截止日期，开发乐趣也就荡然无存了。剩下的就只有许多开发者称之为“墙壁”的埋头苦干了。

墙壁是软件开发项目中不那么有趣的一个节点。此时你已经为一切容易执行的内容编完程序，剩下的就是一些杂活：修复漏洞，棘手的代码，重复返工，超过你控制范围的事情，遗漏的关卡或音效，安装问题，用户测试，你无法重制的报告漏洞，以及应用商店审核等。

完成一个游戏项目好比是攀向一座高峰。运气够好的话，你只要穿着运动鞋，带着雄心就行了——但这通常会导致灾难性的失败。但我这些自由攀登的山峰上，我一开始就会准备好绳索，研究眼前的石壁，记录可能很棘手的片段，测量自己的步伐。

降低风险：经常保存

想象一下如果一次都不保存就直接完成游戏会是怎样。这正是许多游戏开发者制作软件的习惯——孤注一掷，不是让它横空出世就是将其彻底抛弃。中间没有任何商量的余地，不考虑任何意外情况。这是注定会失败的方法。

你这样反复数次后，就会开始看到一个模式：没有保存习惯，一条路走到黑的乐观主义计划通常风险极大。为何不降低风险，在开发过程中设置多个保存点？

从开工到结束

在此我将以自己在某个周末编写的游戏为例解析这些要点。

1.头脑风暴阶段

头脑风暴最棒。我喜欢草草记下大量关于道具类型、宝藏、任务、角色姓名、关卡理念或构建模块等大量列表。这很有趣，也是一种开始制作游戏的绝佳方法。但这里有个潜在问题：头脑风暴本身注重的是数量而非质量。我甚至可以将头脑风暴戏称为“废话连篇”的过程。

如果你的每个项目都要从大规模的头脑风暴入手，很好。但最好要确保不要等到你已经将原计划列表中99%的内容纳入“下一版本”计划列表时才开始动工。

2.制定两个列表：需求和渴望

有一个削减常规游戏开发头脑风暴那种大规模、功能蔓延、过于乐观基调的绝佳方法就是，缩小范围评估各个要点，例如：

*原创性

*可行性

*开发难度

*美工需求

*玩法趣味性

*编程趣味性

筛选你的列表，摒弃大多数想法。将其中多数想法（游戏邦注：尤其是最困难的理念）保留到以后的项目。

针对每个打勾的项目，自问它是一个必须选项，还是优化选项？对于第一个原型，要集中关注其根本元素，因为没有这些元素原型就不会具有可行性。

其次要思考：每个项目的执行难度有多大？这是否需要大量编码或内容？此时可以大胆以一种懒惰的方法执行计划，因为你不久就会发现自己不得不将许多最棒的想法搁置一边，因为执行这些理念需要耗费大量工时。所以此时无需太勤快，选择那些最容易创造的基本功能即可。

提取你最喜欢，并且最容易执行的单个核心游戏机制理念。把一件事情做好，总比只完成一堆半成品要强。

这就是所谓的“最小可行产品”理念。

3.编写“电梯游说稿”

当你自己描述这个最小可行产品，也就是能够用一句话描述整个基本游戏理念，最多只强调一两个方面，那就是时候进行润色了。

要假设你需要在电梯中向一名主流游戏发行商高管讲述自己游戏的可行性。你只有10秒时间，那么你可以在如此短暂的时间中充满热情、兴趣而富有感染力地描述自己的游戏，从而获得一笔可观的预付特许使用金和一份发行合约吗？

写下这个电梯游说稿。进行修改编辑。使其简明扼要。要假想你是在为游戏包装盒写文案，想象一名玩家拿起这个盒子并转一面会看到什么文字。他们有成百上千款其他游戏可供选择，但他们决定给你几秒时间以便他们做出决定。那么你的文案能否成功推销游戏？

如果你向一位好友（或者一名陌生人）朗读这个文案，他们会感兴趣，兴奋还是怀有极大热情？如果对这些问题你都能给予肯定回答，那就说明你走上正轨了。

以下是我为最近制作的一款游戏所描述的电梯游说稿：

“你是个坏蛋。有两名情人极想拥抱对方，你的任务就是通过建围墙来拆散他们。这是一款基于A-star寻径的回合制策略谜题游戏。”

4.绘制粗线条的故事板漫画

下一步，就是在你开始编程或创造大量内容库之前，绘制游戏运作的草图。你不需要什么美术技能，只需要画一些黑白线条的缩略图即可。此时你的目标是以可视化形式呈现整个游戏由始至终的情况。

在一张纸上绘制一系列面板，先画一个类似以字幕或者主界面的东西。在之后的面板中绘制下一幕场景。这可以是游戏介绍，也可以是第一个关卡。总之就按照你玩游戏的顺序一幕幕接着画下去。你需要绘制的面板越多，就表明你制作游戏时需要完成的任务量越大。因此，最好在一张纸上完成所有东西。最好不要超过12个面板。

以下是我最近编写的《Pathos》这款谜题/策略/战术游戏中的游戏机制草图：

我用了各类游戏标题的变体假装A-star寻径算法，并加入许多《龙与地下城》RPG风格的图片，因为这正是我的灵感来源。我喜欢奇幻世界地图，并认为这将成为一个理想的关卡选择屏幕。

制作一个快速故事板的原因是，它会让你更准确地描述出游戏内将发生的情况。此外，它还可以视觉化地列出内容。例如，你在一个屏幕中可以放置多少个按钮，虚拟角色有多大，移动方向，积分或命值条应放置在哪等等。这些缩略图是一种从设计师角度看待游戏的绝佳方法。它们可以在你编程的时间提供许多帮助。例如，通过这种简单的布局你就知道自己需要绘制多少图标或按钮图像，关卡美术内容有什么需求，游戏将呈现什么面貌。

如果你的漫画现在看起来还不像是有趣的游戏，那么你可能就得先弄清楚需要进行哪些调整再继续投入开发。如果漫画看起来无休无止，那么你就需要提醒自己这种工作量过于庞大，你得削减过场动画或关卡、玩法元素的数量。

同电梯演讲一样，这种一页式的粗线条故事板也是去粗取精的好方法。将它展示给朋友看，看看他们是否会喜欢玩这种游戏，他们是否认为这值得你投入时间。

5.制作无美工的早期可玩版本

下一步就是在第一天就制作一个可玩游戏。没有字幕，只有一个关卡，以及基本的玩法机制。

它不需要很棒，也不需要很完整，当然也不需要那么有趣。这个步骤就是你的最佳武器。让你挑战自我创造一个能够在最初几小时编译和运行的代码库。这个版本应该能够接受输入，移动、具有动画，并触发一些声音。

你越早完成这种早期可玩版本，就越有可能成功。这将成为你的首个“保存点”——这相当于你攀峰的时候可以在半途休息的一个高地，经代表游戏的前景。由此开始，你就可以根据自己的需要润色游戏，因为你知道自己已经拥有一个“可行”的版本了。

以下就是我这个项目的初级原型。它含有简单可行的寻径元素，没有美术，只有一些彩色的方形。

到达这一阶段需要投入大量编程时间。我估计这个项目开发周期中有半数时间投入于令游戏呈现上图这种效果的阶段。这种无美术的方法很适合编程：它更节省时间，可以助你找到漏洞，迫使你关注游戏的“感觉”。

无美工的原型还有另一大优势：在之前的游戏中，我会用Photoshop制作好看的模型，并搜集大量可爱的精灵以备游戏所用。在开发完成后，总要更换、调整或抛弃大量的美术内容。我在编程之前浪费了太多时间制作游戏的美术内容。现在我已经明白技术规格以及不断发展的玩法机制意味着，你一开始做的许多内容最后都不会派上用场。

6.开始润色MVP的外观

当你所制作的游戏机制开始运行时，你就可以为自己的最小可行产品（MVP）进行润色。在这个阶段，你还是没有一个主菜单或字幕，但游戏规则及移动方式应该已经到位，以覆盖主要机制。

现在你可以开始为精灵准备特定的像素尺寸，决定布局，颜色方案以及你需要在屏幕上呈现多少贴图，并开始将高质量的美术内容注入游戏世界。这也是试验游戏运行性能以及处理技能局限性（例如保持良好的帧率，让游戏不超过带宽或纹理大小）的时候。

在我的示例项目中，我只使用了一些占位符精灵。每一个与另一个之间的距离都要经过测量：

7.解琐成就！

好消息是，这就是你的下一个“保存点”！你已经拥有一个“可行”的游戏。你可以点击屏幕看到一些发生情况。这里没有人物只有一个关卡，但至少它是你可以展示给好友让他们试玩的东西。你已经有了一些可以编译的内容。

此时我们的目标是功能，也就是一些你可以暂时中止，但却已经有些可以试玩的东西。它可能与有趣根本就沾不上边，或者外观极为丑陋，但这一点都不重要。至少，你有一个没有编程错误的代码项目，并且它能够传递一些内容。

你只有当你完成这个“初级可玩版本”时你才有可能到达终点，因为这时你才可能推出令人信服的产品。

8.一次只专注于一项功能

现在核心玩法机制已经到位，你就可以着手开发更有趣味环节了。也许你会选择先添加一些关卡，编写一些对话，或者为自己的游戏世界开发一些角色。也许你还认为游戏应该含有一个很棒的粒子系统，很酷的音乐，或者高分排行榜。那么，现在就可以开工了！

但要记住一件事：一次只能专注于一件事情。要专注于一项任务，直到其基本成型后才能继续处理下一项。

此时你可能厌倦了老是做同一件事情，需要先暂停一下。这也无妨，但要保持自律状态，还是要继续完成最小的一个系统，直到它进入那种准备就绪的状态。

例如，在执行战斗、命值或粒子特效时，要专注于角色移动和碰撞检测，直到你确信角色能够移动、撞到墙壁，回应键盘、鼠标或摇杆的控制输入。

此时你才能着眼于武器，跳跃等高级移动功能，检测玩家是否接触到熔岩并且受伤等开发内容。

尽量以线性方式展开工作，你会发现自己不需要同一时间处理多个问题。你可以一次仅专注于一项任务，而不是被50个不同类的漏洞所淹没。这是保持动力、注意力和热情的关键。同时遇到太多需要解决的问题，最容易令你因为受挫而心生退意。

正如有漏洞的堤坝一样，只有一个漏洞尚能修补，而如果是50个漏洞同时出现，如果你还不能修复一个漏洞就要奔赴另一个挑战，你很快就会发现自己处于一团糟的境地，这会让你产生极大的恐惧感。

9.继续向保存点前进

在游戏开发生涯中，你每完成一个MVP或可玩原型，或游戏的可发布版本，你都相当于是创造一个保存点。

要记住将这些可玩版本保存在工作文件夹之外的地方。使用版本控制方法，将其置于你的备份硬盘中。以邮件形式发送给游戏测试者。无论此时你在做什么，都要确保自己如果搞砸了一切，还有退路可走。

要坚持以创造多个迭代性优化，以及逐渐增强运行功能的可执行文档为目标。如果你经常忘了备份游戏，必要的时候可以公开情况，这样你就会开始紧张了。

一般来说你将会有很长一段时间用于寻找漏洞。当你发现游戏已经基本上没有功能性问题时，要保存一个备份，这就是你的另一个保存点。

以上提到的线性、迭代方法也适用于你的美术内容或游戏关卡。一次性完成一个关卡的润色。这样如果你没有时间、资金、耐心或者热情去完成所有的99个关卡时，至少你已经有三四个准备充分，值得骄傲的关卡。

简单地说，此时一定要确保你手头上已经有一个随时可以上线的游戏版本。毕竟，谁也不知道明天和意外哪个会先到。为了预防万一，你最好不要在这些保存点上出现差错。

迭代、性线、按步骤，一次一个任务的开发方法就是12个月制作12款游戏的成功秘诀。

10.到达终点！

当你到达一定保存点时，你的游戏将会呈现很棒的效果。此时，你才能确定项目大功告成的时间。要认识到你永远无法将最初头脑风暴文件的一半功能添加到最终成品中。但这些内容很可能变成你第二个版本的元素。

以下是我这个示例项目的成品。此时我已经准备推出游戏。我更改了名称，添加了一些很棒的美工，为我的关卡编辑器编写了一个分析程序，并找了一些音效和音乐内容。这是一款游戏，具有可玩性，我为它而骄傲。我将其称为《Pathos》，下面就是它的最终面貌。

记住：要接受自己的局限性

所有的游戏开发者都是充满激情、创意的人。不幸的是，正是这种无穷的热情和创意让我们深陷麻烦。作为乐观主义者，我们都总会为项目抱有一个远大的期望：心目中的游戏成品就像薄煎饼一样畅销。

这个项目的每个环节听起来都像你真的能够轻松做到一样——事实也确实如此。但是，如果你将每个任务加起来，就会发现制约因素并不在于你的能力，而在于你的时间有限。

记住你在主机上玩的多数游戏，背后都有持续投入数年时间的上百名全职开发人员。如果你是试图与这些团队相抗衡的单人开发者，你就得计算清楚他们的工作时间远超过一名独立开发者终身寿命。

你还得接受一个事实，你一开始的目标不可以太高（游戏邦注：除非你想投入数年开发一款游戏），这样才有可能完成项目。要考虑到优秀独立游戏平均利润也不过数千美元，你不可以在游戏上投入成百或上千小时，除非你笃定这款游戏一定会成为惊世之作。你需要设计那种只需20或50小时工作就成完成的游戏。

无论如何，可以大胆假设——但要小心求证。要创造最小可行产品，如果得到测试人员的认可，那就添加更多内容，并将其称为2.0版本。

记住：要接受不完美

完美实际上是一种不可能达到的境界。你得收敛你的骄气接受自己的不完美。如果忽略了这一点，你就可能把这自己一直绑在这个项目上。记住，你可以一直制作续集。在项目妥当时就可以发布游戏，虽然你可能觉得它还可以不断完善。因为这不但可以为你减轻压力，还可以让你获得一些成就感，但游戏到达玩家手中时，他们可能还会提出一些你永远无法想到的新建议。

记住：尽早发布，经常更新

在你没有时间，精力，资金或动力的时候，那就发布已经完成的版本，吧。如果你坚持那套保存点系统开发方法，你就该在项目任何阶段都有一个可玩版本，即便你的功能清单上还有许多内容尚未落实。这没有关系。

“尽早发布，经常更新”已经是被许多成功开发者反复证明的真理。你需要玩家反馈，现实世界的测试。在暗无人处编程，直到游戏最终见到天日，这是一种错误的观念。首先，你只是通过自己有限的视解看待自己的游戏。因为长时间看同一件事物时，你的大脑就开始麻木了，需要他人不同的眼光和视角来补充见解。

你可能会发现一些机制，虽然在理论上看很棒，但落实之后却很无聊或令人受挫。

除此之外，尽早发布并经常更新的游戏可以获得更多曝光度。你更有机会进入“最值得关注的新游戏”榜单，可以吸引粉丝。你可以让更多人测试自己的游戏，并获得将影响游戏设计的有用建议。

玩家可能会提供一些让你意外的批评或称赞。而你认为很重要的功能可能却会遭到冷遇，你认为不重要的元素反而博得众人青睐。总之要关注公众对游戏的反应并及时作出回应。这可以为你节省时间，免去一些棘手问题。这也会为你未来的游戏发布找到方向。最重要的是，这可以为你带来新粉丝，支持者和更大的动力。

现在开始编程吧！

既然你已经有了一点动力，了解了我个人的游戏开发方法，我鼓励你现在就下线开工吧。调查或计划得太久可能会浪费时间和精力。有时候你需要的只是创建一个新文件夹，创造一个空白的项目，并开始编码。发动你的游戏开发引擎吧！

如果你遵从了这个基本的游戏开发方法，我相信你会有不少收获。其中最主要的就是减少压力，让你的开发过程更有趣，更实际，这种保存点系统也更可能获得玩家反馈。最后，将项目分解为更小的部分，你就有可能在今年每个月都发布一款游戏了。

原文发表于2013年1月24日，所涉事件及数据以当时为准。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

#1GAM: How to Succeed at Making One Game a Month

Christer Kaitila

You can make a dozen games this year. Sound impossible? It’s not. Try this simple game development methodology from someone who has pulled it off and see for yourself that 12-in-12 is a reasonable goal.

The McFunkypants Method

I’m going to share with you my personal game development methodology. I don’t claim to have invented the world’s only system for reaching the finish line – far from it. This is merely a spellbook, a toolbox filled with my own personal tips and techniques that I use to battle the demons that try to prevent me from launching a game. These demons include feature creep, all-or-nothing design, and unbounded optimism. These are tricks I’ve developed in the course of succeeding where I had failed in the past.

You see, in 2012 I achieved the lofty goal of creating 12 games in 12 months. Surprisingly, it wasn’t all that hard: it didn’t take any more work than my many failed projects had in previous years.

So what was the difference? A more mature, more seasoned, less wide-eyed and less optimistic approach. Don’t get me wrong: there’s nothing at all wrong with optimism. In fact, I encourage it! Without it, none of us would be gamedevs. Without some optimism you’ll never get anywhere. I just needed to approach my projects with a slightly more humble mindset.

I’d like to share some of my tricks and tips with you here. I ask that you consider each of them, yet feel free to accept or reject them as you see fit. No one technique can work for every person, but if you take away a single technique or mindset that helps you pull off the One-Game-A-Month goal of 12 games in a single year, then I’ll be happy.
OneGameAMonth motivation and techniques

Join us!

Try using these tips in your next game project. Perhaps they will help you out too. Maybe you’ll come up with your own best practises that are different or better. That’s great! Like with most advice, the key is to consider the message, accept or reject each point as you personally see fit, and adopt (or adapt) those practices which appeal to you.
Reach the Finish Line More Often

90% of game projects never see the light of day. My own personal experience confirms this. I’ve been making games for over twenty years, and of all the games I started – filled with enthusiasm, a detailed plan, and infinite brainstorms worth of ideas – only a small percentage were ever released. This caused me years of heartache. I was a good coder, I could produce acceptable artwork, I had enough good ideas to feel confident about my plans, and yet that wonderful state where the game is ready for the public was an elusive target.

Why? Because actually implementing all these exciting plans always involved challenges that I hadn’t predicted. Plus, the enthusiasm I had for each project would typically wane as the finish line approached. The going would get tough, the money would run out, the due date would pass me by, and the fun would end. All that would remain was that slog though the final stretch that many devs call the wall.

The wall is the point in a software development project where it is no longer fun. All the easy-to-implement things have been coded, and what remains is the busywork: bugfixing, tricky bits of code, repetitive tasks, parts that rely upon things outside your control, that one missing level or sound effect, installation issues, user testing, that reported bug which you can’t reproduce, and app store submissions.

Finishing a game could be thought of as analogous to climbing a mountain. With luck, you can do so with nothing more than sneakers and ambition – but this generally results in catastrophic failure. Instead of free-climbing my mountains without a thought or a plan, I started bringing ropes and holds, studied the rock wall beforehand, took note of sections that would be tricky, and paced myself.

How? Reduce Risk: Use Save Points!

Imagine having to finish an entire game without a single game save. This is how many game developers create software: all-or-nothing, no safety net, you either hit it out of the park or crash and burn. No middle ground. No accounting for unplanned contingencies. This is a sure fire way to unintentionally aim for failure.

After you do this a few times, you will start to see the pattern: optimistic plans without save points along the way are extremely risky. Why not lower the risk and give yourself multiple exit points along the way?

Start to Finish

Let’s dive in. I’m going to use a game I wrote in a weekend as an example to illustrate many of these points. This real-world example should help to prove this works.
1. The Brainstorm Stage

Brainstorming is the best. I love jotting down vast lists of item types, treasures, quests, character names, level ideas or building blocks. It is fun, and it’s a great way to start working on a game. But there’s a hidden trap: brainstorms are, by their very nature, about quantity, not quality. I like to joke that an acronym for brainstorm is B.S.

If you do begin each project with a huge brainstorm, great. But don’t start working on your game until you’ve thrown 99% of what made it onto your initial list into the “save it for version two point oh” wishlist.

2. Make Two Lists: Needs and Wants

One great way to pare down the massive, feature-creepy, overly optimistic tome that is a typical gamedev’s brainstorm is to rate each bullet point on a few scales, like:

Originality

Viability

Ease of development

How much art it would require

How fun it sounds to play

How fun it sounds to code

Sort your list and discard the vast majority of your ideas. Save most of them (especially the hardest ones) for later.

For each item in your top picks, ask one final question: is this a must have or a nice to have? For the first prototype, focus solely on the essential, couldn’t-possibly-work-without-it features.

Secondly, think: how difficult will each item be to implement? Does it require a lot of code or content? Don’t be at all ashamed to plan in a lazy way right now: you will have to be disciplined enough to put many of your greatest ideas on the back burner simply because implementing them will take a large number of hours of work. Be lazy: choose the most essential features that are easy to create.

What are are aiming for when you attack your giant brainstorm is to pare it down to the absolute essentials only. Distil your idea to the single core game mechanic you like the most that would be easy to implement. Do one thing well, not a dozen things half-baked.

This will be your MVP: your minimum viable product.

3. Write the Elevator Pitch

Once you’ve described the MVP to yourself – which means being able to describe the entire basic concept of the game in one paragraph, with one or two features at most – it’s time to refine it.

Pretend you need to convince a major publisher executive of the viability of your game during a chance meeting in an elevator. You have ten seconds. Can you describe your game so enthusiastically, so interestingly, so mindblowingly that in that brief moment you could score a huge upfront royalty payment and publishing contract?

Write this elevator pitch down. Edit it. Make it shorter. Pretend, instead of the above scenario, this would be the text copy of the back of your game’s box if it was sitting on a store shelf. Imagine a gamer picking up the box and turning it around. They have hundreds of other games to choose from, but they’ve decided to give you a dozen seconds of their time to considering yours. Does this pitch sell the game?

If you read it to a friend (or even better, a stranger) are they intrigued? Excited? Enthusiastic? If you can say yes to these questions you know you’re on to something good.

Just for fun, and to illustrate all my points, I’m going to show you my work-in-progress for a recent game I made. The elevator pitch at the beginning went something like this:

You are the villain. Two lovers desperately want to embrace each other. Your mission is to keep them apart by building walls that drive them farther apart without ever making it impossible. A turn-based strategy puzzle game based on A-star pathfinding.

4. Draw a Stick Figure Storyboard Comic

The next step, before you start coding or creating vast libraries of content that may or may not make it into your final game, is to do a rough sketch of the game in action. You do not need any artistic skills: these can be black and while crayon stick figure thumbnails. What you’re aiming for is a visual representation of the entire game – from beginning to middle to end.

Draw a bunch of panels on a  piece of paper and start with a rough approximation of what the title screen or main menu will look like. In the next panel, draw what happens next. An intro? Level one? Continue as if you are making a play-by-play of the game itself, from moment to moment. The more panels you need to create to fully visualize your game the more work you will be assigning to yourself. Therefore, aim to fit the entire thing on a single page. Less than a dozen panels is wise – but the sky’s the limit.

I’ll show you my work-in-progress shots of a puzzle/strategy/tactics game I programmed recently called Pathos. To begin, here’s the rough sketch that I used to plan the game mechanic quickly:

OneGameAMonth motivation and techniques

As you can see, I’m a big fan of puns. I played with all sorts of game title variants that played off the a-star pathfinding algorithm, and I threw in a lot of Dungeons and Dragons RPG-style imagery, since that is what inspires me. I love fantasy world maps and figured it would be the ideal level select screen.

The reason that making a quick storyboard is important is that it will give you a more concrete description of what actually happens in the game. Moreso, it lays things out visually. How many buttons can you fit on one screen? How big is the avatar? What direction is the movement? Where is the score or health bar? These thumbnails are a wonderful way to see the game from a designer’s perspective. They will also help you during coding in numerous ways. For example, you’ll now know roughly how many icons or button images you need to draw, what the levels art will require, and even what the game will look like – from a basic layout perspective.

If your comic doesn’t look like a fun game now, then you’ll have saved yourself weeks or months of work by knowing already that some changes will need to be made. If the comic seems to go on forever, then you’ll see the obvious warning signs that the workload is too large and you need to reduce the quantity of scenes or levels or gameplay elements.

Just like an elevator pitch, this one page stick figure comic-style storyboard is an ideal BS filter. Show it to friends. Do they want to play this game? Do they think it would be worth your time to turn into a reality?

5. Make a No-Art Early Playable

The next major handy tip for this challenge is to make a playable game in the first day. No title screen, only one level, and just the primary gameplay mechanic.

It won’t be great, it won’t be finished, and it certainly won’t look that great or be all that fun. That said, this step is your best weapon. Challenge yourself to create a codebase that compiles and runs in the first few hours. Make it so that you can accept inputs, move around, animate something, and trigger some sounds. This prototype, lousy a game as it may be, is going to be your best friend.

The sooner you can have a working early playable prototype, the more likely you are to succeed. It will be your first “save point” – a resting plateau on the way to the top of the mountain that you can fall back on. It represents a vision of the working game. From here on you will be able to polish your game for as long as you like with the knowledge that you have something in hand that “works”.

Here’s what the first prototype looked like. It was a simple example of pathfinding in action, with NO ART – just colored rectangles.

OneGameAMonth motivation and techniques

Getting to this stage took a lot of programming time. I estimate that half the lifespan of the project was spent with the game looking like the image above. The no-art approach is ideal for programming: it saves time, helps you figure out the bugs, and forces you to focus on the “feel”.

No-art prototypes also have one other major advantage: in previous games, I would make beautiful mockups in Photoshop and gather hundreds of lovely looking sprites in preparation for the game. After development was complete, the vast majority of the art had to be replaced, resized, or thrown out. I’ve wasted thousands of hours making game-ready artwork before coding; these days I know that the tech specs and evolving gameplay mechanics will mean that much of what you make at the start won’t make it into the finished game.

6. Start Making the MVP Look Pretty

Once the game mechanic you’re working with is starting to function, you can start to add polish to your minimum viable product. At this stage, you still shouldn’t have a main menu or title screen, but the movement and game rules should be in place to cover the primary mechanic.

You are now ready to commit to a particular pixel size for your sprites, to decide upon layouts and color schemes and how many tiles you want on-screen, and to begin dropping game-quality art into your game world. This is also the time to experiment with performance and deal with all the tech constraints such as maintaining a good framerate and staying below your desired bandwidth or texture size.

Back to my example project, here’s the first working prototype, using only a couple placeholder sprites. The distance from one location to another is now being measured, and we’re ready for some actual levels:

OneGameAMonth motivation and techniques

7. Achievement Unlocked!

Good news: this is your next “save point”! You have a game that “works” in that it functions. You can click the screen and something happens. There’s no personality and only one level, but at the very least it is something that you could send to a friend and ask them to play. You have something that compiles.

What we’re aiming for here is functionality: something, anything, that you could stop working on and yet have something to show (and play!). It may be horribly un-fun or ugly as sin, but that’s not in the slightest bit important. At the very least, you’ll have a code project that compiles without errors and produces a deliverable.

Only once you achieve this “early playable” are you certain to hit the finish line, because from now on you could conceivably ship it.

8. Work on Only One Feature at a Time

With the central gameplay mechanic in hand, the world opens up to you. The possibilities are endless and the fun part begins. Maybe you’ll choose to add some levels, write some dialog, or develop some characters in inhabit your game world. Maybe you think a fancy particle system, cool music, or a high score list is essential to your vision of what the game should be. Great! Dive in!

Just remember one thing: don’t work on a little of this or that all at once. Focus on one task and finish it to the minimal basic complete state before moving on.

You may get bored of working on something and need a break. That’s fine – but attempt to be disciplined enough to keep working on the minimal system until it exists in a state that you could walk away from if need be.

For example, before implementing combat or health or particle effects, concentrate on the character movement and collision detection to the point that you can confidently say that the character moves, bumps into walls, and responds to keyboard, mouse or joystick controls.

Only then should you move on to weapons, or advanced movement like jumping, or detecting whether or not the player is touching lava specifically and needs to receive damage.

By working as linearly as you can (within reason), you will find that you are juggling fewer things at once. Your mind will be free to concentrate on a single task at a time rather than being overwhelmed by fifty different bugs in fifty different classes. This is essential to keep your motivation, concentration, and enthusiasm. Nothing makes you want to quit more than having so many problems to solve that you get discouraged.

Just like with a leaky dam, a single hole is easy to plug. If, instead, fifty different holes all appear at once – if you jump from one challenge to another without finishing the one you were working on previously – you’ll soon find yourself sitting in a huge mess of buggy code that is so complex and has so many problems scattered about that you’ll get that horrible feeling that comes with the realization that you are going to have to gut everything to fix them all.

9. Keep Hitting Save Points

In the life of a gamedev, you create a metaphorical save point any time you complete an MVP or playable prototype or released version of a game.

Remember to save this playable version of the game somewhere other than your working folder. Use version control. Zip up the game and toss it onto your backup drive. Email it to a playtester. Whatever you do, ensure that if you destroy everything from this point on, you could step back one version and ship it.

Always aim to create many iteratively improved and incrementally enhanced working, functional, executables. If you’ve gone more than a day without having a solid backup version of your game that could, if needed, be made public, then you should be getting nervous.

Naturally there will at times be long stretches where you’re hunting down bugs for hours on end. When you get to a point where the game seems vaguely functional and isn’t totally broken, save a backup. There – you’ve created another save point.

For this reason, the linear, iterative approach outlined above also holds true for your art content or game levels. Work on polishing one good level at a time. This way, if you run out of time, money, patience or enthusiasm before you finish all 99 levels you’d planning in your design document, the three or four that you did finish are good enough that you could still be proud of them.

To put it more simply, strive to at all times have a version of the game available that you could walk away from and put live. This is a safety net. After all, life might throw an unexpected crisis at you tomorrow. Sickness, family stuff, an oncoming bus – whatever the cause, you’ll always sleep better with a save point at the ready.

Remember, you can always come back to it and create a vastly improved and expanded version 2.0.

Iterative, linear, step-by-step, one-thing-at-a-time development is the secret to 12-in-12 success.
10. Reach the Finish Line!

One you’ve hit a few save points, your game is going to be in great shape. At one point, you’re going to decide that it is time to call it done. It is important to realize that you’ll never add half the features from your original brainstorm document. It is likely that many more will have moved from your version 1.0 to your version 2.0 wishlist.

Let’s return to my example project game. At this point, I’d been working on and off for a weekend and was ready to ship it and walk away. I’d changed the name, added some nice artwork, coded a parser for the data format that my level editor used, and found some sounds and music. It was a game. It was playable. I was proud of it. I called it “Pathos” and this is what it looked like. Feel free to click the image below to read more and play the game.

OneGameAMonth motivation and techniques

Pathos – a puzzle strategy game by McFunkypants – Click to play!

Remember: Accept Your Limitations

All gamedevs are enthusiastic, creative people. Sadly, it is this boundless enthusiasm and creativity that can get us in trouble. As optimists, we have in our imaginations a grand vision of what could be: that ultimate game that you just know would sell like hotcakes.

Each individual part of this grand dream project sounds like something that you could easily do – and this is probably true! However, if you add up each task, your ample ability is simply not what will limit you; it is your time that is in short supply.

Remember that most games you play on console, for example, have had a hundred people working on them, full time, for several years. If you are a solo indie attempting to compete with these kinds of teams all you have to do is a little math to realize that the human-hours of labor add up to more than one indie developer’s lifetime.

You simply have to accept the fact that you need to aim lower in order to finish unless you want to spend years on a single game. Considering that the average good indie game nets a few thousand dollars of profit, you cannot afford to spend hundreds or thousands of hours on your game unless you’re betting the farm on a life’s work or epic masterpiece. You need to design games that would take 20 to 50 hours of work.

By all means, dream big – but build iteratively. Build a minimum viable product, and if playtesters love it, add a bit more and call that version 2.0. Continue working this way for as long as you like!

Remember: Accept Imperfection

Perfection is, by definition, unattainable. You’re going to have to swallow your pride and accept imperfection. To neglect this is to chain yourself to the project for an eternity. Remember, you can always make a sequel. Releasing your game even though you know you could improve it forever is a good thing. Not only will it lift a huge weight off your shoulders and give you something to be very proud of, but once it gets into your player’s hands they may come up with new features you’d never considered.

Remember: Release Early, Release Often

When you run out of time, energy, money or motivation, launch what you have. If you’ve adhered to the save point system development methodology, you should have something playable at any stage of the project, even if there are all sorts of features left over in your wishlist or to-do list. That’s okay!

The “release early, release often” mantra is repeated over and over again by successful gamedevs for a good reason. You need player feedback. You need real world tests. Coding in a black box, hiding away in a bunker until the moment of final release, is a mistake. For one, you’re seeing your own game though your limited perspective. You’ve probably noticed times when you proofread your own emails but the world’s most obvious typos get through. This is because after a while of looking at the same thing your mind starts to grow numb to the critical eye. A fresh set of eyes sees things in a different light.

You might find that a certain mechanic, while seemingly brilliant on paper, is boring or frustrating once implemented.

Additionally, games that release early and continue to be developed are the ones that gain the greatest exposure. You generate more “newsworthy” information. You build buzz. You attract followers. You get people testing your game and gain valuable knowledge that will influence your designs.

Players might offer criticism or kudos that surprise you. Features you thought were important might be met with disinterest, while those you thought were unimportant might turn out to be everybody’s favourite. It is important to see how the public reacts to your game and react accordingly. This saves you time and heartache. It gives you direction for future releases. Most importantly, it will give you new fans, followers and a well-deserved pat on the back.

Plus, the knowledge that someone out there played and enjoyed your game is golden.

Now Stop Reading and Start Coding!

Now that you’ve been given that extra little bit of motivation and a glimpse into my personal gamedev methodology, I encourage you to get off the internet and just dive in. Planning or researching for too long can be an energy and time drain. Sometimes all you really need to do is make a new folder, create a blank project, and start coding. Fire up your gamedev engines and hit the afterburners.

If you follow this basic philosophy of game development I am confident that you will reap many rewards. The most basic will be lower stress. More enjoyment of the process, more tangible, playable builds, and more chances to get player feedback are also the benefit of this save point system. Finally, by chopping projects into small discrete sections, you are sure to be able to post a new game each and every month this year.（source：gamedev.tutsplus）