作为一名独立游戏开发者，在制作游戏过程中尽量多学些东西这一点极为重要。我认为这一过程包含以下几个步骤：
1.想法
2.原型
3.迭代
4.测试
5.完工
我希望针对这个过程的每个阶段提供一些对你们有所帮助的建议，以便你们加快开发速度，提升游戏质量。
逐步进阶的过程
首先，要注意到这并非线性的“瀑布”过程。它非常有组织。你通常是先从一个理念开始，接下去就是以无序方式开始创建原型、迭代和测试。这有助于你进行试验，克服僵化的游戏设计，从而推动游戏的积极发展。
indie game developer()
步骤1：想法
初级游戏设计师有时候会认为这是整个过程中最重要的一步，并且会因为一个正在探索中的想法而中止整个开发过程。因此，他们很容易出现过度设计的倾向（游戏邦注：例如编写出庞大的游戏设计文件），自不量力地将项目放大，高估游戏理念的价值。这也会让设计更为僵化，长期来看也会对游戏造成消极影响。
虽然想法很重要，但最重要的还是认识到如果不制作原型并测试想法就根本学不到什么经验。你会发现自己脑中的想法听起来确实很有趣，但试玩原型之后可能就会觉得很糟糕。你还可能发现一个根据听起来很“无趣”的理念所制作的原型反而非常有趣。
在这个阶段，你要明确自己的目标和局限性。例如，“制作一款有趣的游戏”就不能算是一个明确的目标，而“在一个月内使用‘Flowers’主题，并更好地使用新COM系统制作一款游戏“才能算。这第二个例子还显示了约束条件。有些适用于多数人的约束条件包括在特定时间内，以及在自己的技能范围内制作游戏。约束条件可以让你想出更多主意，但通常你可以针对每个游戏项目进行一些自由取舍。
提到想法，我们通常会提到灵感一句。要记住灵感无处不在，例如你的生活，其他媒体，游戏设计理论，它甚至可以是随机生成的！最重要的是知道“灵感”并非没来由的念头！当你“获得灵感”时，你的大脑可能会被蒙蔽，从而难以看到这个想法的糟糕之处。你要做的就是再多给自己一些时间，无论它现在听起来有多好，至少也要想个三四天后再将它写下来。
在低级阶段，重要的是专注于理念中的机制。记住，你是在编写一款游戏，而不是一个故事，所以你需要玩法！如果你不能想出这个故事的好玩法，也许最好使用其他媒介形式表达这个故事。
当你有一个想法并且酝酿了足够的时间（而该想法听起来仍然很不错）之时，下一件要做的事情就是将其精简为最基本的形式。从而发现你最看中该理念的哪些元素。你得找到令该想法如此具有吸引力的最原始、核心的元素。这是你创建原型的切入点，因为你的整款游戏都要依赖这些元素。
这里还有个悲观的提示，要记住你终有一天会死。将此牢记在心，把它当成你制作的最后一款游戏。
步骤2：原型
如果你还是坚持使用某个想法，我还是要强调：你只有制作出了原型才能看到该想法的可塑性。所幸这通常就是游戏开发过程中最有趣的步骤，因为你可以在此看到自己的想法成真！但若要有效使用你的理念，那就一定要准确创建原型。
在创建原型过程中，你一定要勇于面对失败。如果你害怕失败，你就永远不会发布游戏。我喜欢将原型保存在不同于源代码控制的开发文件夹以及桌面文件夹中，只是因为这可以突出创建原型需要实现的临时可玩性。如果你搞砸了，就要告诉自己这正是你预料中的情况，这没有关系！
除了直面失败，你还需要加快创建自己的原型，因为在你成功之前很可能遭遇多次失败。你可以通过优化代码来提高速度。这里我并不是指实现性能上的优化，而是“寿命”优化。你希望以最大化重用和简化的方式编程，这意味着要创建一个充满可重用代码的游戏库，并制作一个你可以复制和重用的游戏模版。这个游戏模版应该包括一个拥有渲染精灵的开放窗口，输入和可行的生成文件等。这是为了方便起见！
此外，你还要避免使用创建原型的“更简便”方法，而是坚持使用你自己最熟悉最拿手的工具，因为这可以加快创建原型的效率和速度。我大部分原型是用C++编写的，因为我对这一语言有4年的接触经验。
在你碰到任何一行代码前，要确保你已经明确了原型所需解答的问题。而这些问题应该极为简单，并包含游戏理念最重要或最具“风险”的部分。理想情况下，你应该在一些显而易见的地方写下问题，这样就不至于让自己脱轨。只要原型解答了这一问题，你就可以继续向下一个问题进军了。
当你终于做出了能够肯定想法的原型之后，要找到肯定它的核心元素，并摒弃其他所有冗余内容。精简就是优秀设计的核心。
步骤3：迭代
此时，你已经制作了不少次可确定自己想法潜力的原型，也已经确认了想法的技术可行性，以及在编码时如何执行这一理念。你还发现了自己最喜欢这一理念的哪些元素，并删除了那些与游戏体验不相干的内容。如果你没有实现这些目标，那就回去重新制作更多原型吧！
我所提到的迭代，是指开发和优化最终产品。你应该避免使用原型作为成品代码，因为原型是为回答某个问题，而非整款游戏而量身制作的内容。在这个开发环节，你要使用自己最可持续的编码技能来创建整个游戏成品。原型阶段还不是让这些技能上场的时候独立游戏开发者，因为原型迟早会被抛弃。
迭代应从最重要元素向最不重要元素入手（像原型一样）。如果你在尚无可运行的主游戏机制之前编写界面或图像代码，你就真是犯了大错！没有人会在乎你的图像或菜单，他们在乎的是玩法！要先制作“玩具”，最后再动作制作菜单，以及润色其他元素。
虽然现在你是在编写“最终”代码，但还是要进行一些试验。在进行这些试验时一定要小心谨慎，一不留神就可能漏掉之前所专注的核心元素。要确保你清楚为何游戏具有吸引力。十有八九不是因为你有逼真的布偶物理机制。你的试验应该与产品相分离（如果你使用源控制方法，这就很棘手了）并且易于取消。你在这种试验阶段应该专注仅优化核心元素！如果试验与核心元素存在明显分歧，那就写下来并在之后制作原型。
当你开发一个新模块时，一定要再它完成和可行时再继续开发另一个模块！这很困难，因为你可能已经疲于应付新系统中的漏洞，但重要的是完成该模块。这一点之所以重要是因为漏洞的叠加会导致整个系统崩溃。
另一个原因是你在创建组块的过程中可能会忘了之前知道的事情，所以就需要再回头花些时间进行调整，并可能因此犯错。完成模块也可以让你获得更多动力。在你“完成”一个组块并发现其中存在漏洞时，要立即修复它，否则你就将其搁置一旁，之后忘得一干二净。
Keep_It_Simple__Stupid
不要在时机未成熟时进行优化！作为一名程序员，你可能已经听过KISS（注：即“Keep It Simple,Stupid！”简写）这一理念。要严格贯彻这一原则！Jonathan Blow讨论过算法和数据结构，以及它们如何针对运行性能或内存进行优化，但并非“终身优化”的问题。更重要的是在一个月内结束以20 FPS的速度运行的游戏，而不是在一年内完成以60 FPS速度运行的游戏。
在迭代周期编码时，你得辨别出可以在未来游戏中重用的系统，并将它们添加到自己的库中，而不是让它们仅运用于原来的游戏。这不但可以优化你的库，还可以加快之后的游戏（和原型）开发速度。不要试图重用那些过于专门化的系统。
在通过迭代扩充你的游戏库时，还要专注于那些能完成而非运行表现，并且能够鼓励代码重用独立游戏开发者，缩短开发时间的功能。例如，碰撞检测和分辨率就极有用处，值得你花时间去执行，但执行一个“优化”的碰撞路径就不是了。记住，只有在你需要时才进行制作！在功能方面的例子，我最近执行了自己的COM（或CES）系统，因为我发现这更便于进行代码重用。当然，你会遇到运行性能方面的问题，但动态的、可移植笥和重用性元素在终身优化时可以弥补这些不足！
如果你已经进行到了这一步，就没有必要抛弃项目了！当然，你已经通过代码错误学到许多经验，完整的重新编码对项目也有好处，但不要再浪费自己的时间了！许多初级游戏开发者总是在开发中期抛弃项目，这也正是为何他们仍是新手的主要原因！你已经遇到了一个所谓的“瓶颈”状态，此时你并不想再继续推进项目开发进程。一定要挺过去，否则你之前所做的一切都白费功夫了！我已经发布了7款游戏，其中2款甚至一度将遭遇死刑。但我挺过来了，并从错误中汲取了许多经验。你一定要完成整个项目，不要轻易言弃！
迭代很大程度上会受到下一个环节的景，即玩法测试。
步骤4：玩法测试
得承认，我在玩法测试中遇到过许多麻烦。你很难正确处理这一问题，但如果处理得当，就会极大提升你的游戏。玩法测试很明确，所以我在此要列出一些能够让你更有效率的原则：
首先，尽早和经常测试！怎么测试都不算太多！在原型阶段就要开始测试，发布时也同样不例外。你会发现自己原先认为很完美的游戏内容，其他人却完全看不明白，所以不要闭门造车地开发游戏！
其次，要奉行多样化原则！这包括人群和技术。要尽量在多种设备和操作系统上测试。我有一款游戏在自己的两台电脑（拥有完全不同的配置）上运行都很理想，但在多数其他人的电脑上却出现了崩溃性的漏洞！针对人群进行测试时，不要局限于某一群体，让大家都来玩玩游戏，无论对方的性别、年龄或兴趣！你的测试对象越多样化，你的用户也就会越广泛，你的游戏就会越有包容性。
不要浇灭测试者的热情。他们试玩一会儿之后，可能就会带有偏见，尤其是在他们已经看过游戏早期版本之时。你得让测试者拥有清醒的状态和头脑，所以要经常更换测试者。
观察是你在测试过程中最需要掌握的一项技巧。要观察测试者何时说话，何时停止说话，何时在游戏中挂掉，何时获得成功，何时不再玩游戏等。多数人的表现情况都一样，即使你也在场。观察也是你在测试过程中唯一需要做的事情。不要给予测试者任何背景，或者向其解释情况，对其提供帮助等，你只负责观察，并及时做记录。
在他们完成测试后，可以向他们提出以下三个问题：
1.（对这款游戏）你喜欢什么？
2.你讨厌什么？
3.有什么困惑？
这可以让你获得关于应该重视和改变哪些地方的清晰反馈。此外，玩家给你提供优化游戏的建议时2d游戏素材，不要关注建议本身，而要琢磨他们为什么要提供这个建议。
步骤5：完工！
到了这一步，你就可以准备完成游戏了！最后10%的开发过程总让人感觉像是90%3D场景，但你一定不要放弃！记住即使是“90%完工”的游戏也是无用之物！完成是指你突破瓶颈，让所有松散的环节连成一片。此时可以回头看看自己究竟走了多远，前面还有多长路程。总之，马上就要到终点了。
虽然你已经快完成了，还是要在多个平台进行测试。你得测试一切内容，甚至是“说明”文件也不例外！
你得缩短玩家发现你游戏的路径，尽你所能降低一切门槛，让他们更方便地查看你的游戏。这里的关键就是方便。
如果你想知道为何自己的游戏看起来仍像是个“业余”项目，那有可能是因为它润色不够。在菜单或加载屏幕等一些极小的细节上有瑕疵，而正是这种细节让玩家产生了这种感觉。记住，玩家最先看到的就是这些内容，所以一定不能在此出差错。研究一下“专业”游戏项目，以及它们看起来“更专业”的原因。润色很大程度上要取决于自己的感觉，所以你需要自己去体会，但它确实值得你花时间。
如果你还是为自己的游戏质量而“惭愧”，或者知道它有严重的缺陷，那就尽己所能修复问题。完成你的项目，从错误中学习经验，在下一款游戏中发挥更佳表现。
总结
祝贺你完成了游戏！现在再做一次，但要避免再犯影响游戏质量的错误。
在此我将每个步骤的核心理念概括如下：
1.想法
1）原型仍然很重要
2）设置一个明确的目标和约束条件
3）多花点时间
4）找到验证该想法的核心元素
5）要全力以赴
2.原型
1）不惧失败
2）尽快制作原型，尽量让代码更便捷
3）使用你已经知道的工具
4）明确原型所需解答的问题
3.迭代
1）制作高质量的代码
2）从最重要到最不重要的元素入手
3）试验，但不要遗忘核心元素
4）完成模块再推进工作（例如消灭所有漏洞）
5）KISS/终身优化/不要在时机未成熟时优化
6）在游戏库中增加重用代码
7）仅向游戏库添加可提升开发速度或加强性能的功能（不要为追求速度而编码）
8）此时一定不要放弃！
4.玩法测试
1）尽早和经常测试
2）多样化你的测试群体
3）替换测试者
4）提问
5.结束
1）挺过去
2）测试，测试，测试
3）降低开始玩游戏的障碍
4）进行润色
5）发布游戏并汲取错误教训
