短时间游戏开发指南

英文原文名称是：#1GAM: How to Succeed at Making One Game a Month，作者McFunkypants拥有20多年的游戏开发经验，也是OneGameAMonth活动的发起人和组织者。因为文章较长，我在此将文章的要点进行了总结，适合不愿意读长文的人或者是作为速查手册。

文中论述的游戏开发方法并不局限于“每月一游戏 OneGameAMonth”，对于短时间、小规模的游戏开发过程都是有指导意义的，它可以简单归纳为下列步骤：

1. 精简第一版游戏内容
2. 完成没有任何美术资源的MVP（最小可用原型产品）
3. 不断迭代开发且每次只专注于一项内容
4. 尽早发布，频繁发布
5. 有始有终

我的亲身经历

在Ludum Dare #25的时候我使用了类似本文的开发流程：快速完成极为丑陋的原型，然后不断丰富和完善游戏。这使我的整个开发过程显得格外轻松有趣、得心应手，而这个游戏也是我历届参赛作品中完成度最高、内容最丰富的。而那些从画面入手的游戏，虽然开始的时候轻松愉快，但最后总是会在某些方面完成度很低，而且后面的开发过程往往非常紧张仓促、令人焦虑，完全谈不上有趣……

游戏是多样化的，游戏开发者是多样化的，做游戏的方式也是多样化的，没有“最佳路径”，但本文的作者确实结合自己多年的独立游戏开发经验给出了一套不错的方法，在此推荐给大家。

现实：绝大多数独立游戏最终以难产告终

客观原因：独立游戏开始容易做完难——初期的激情转瞬即逝，剩下的开发过程往往艰难而枯燥。

主观原因：all-or-nothing开发思路——要么完成，要么一无所获，不给自己留后路，一旦半途而废最终什么也得不到。

解决方法：频繁存档——在通往游戏最终版的过程中设置多个存盘点，每一个存盘点都对应一个可发布的版本。

具体操作流程

1.头脑风暴

头脑风暴是个收集点子的好办法，但是在开始制作前请用下面的方法精简掉99%的点子。

2.两个清单：必不可少 & 锦上添花

作用：精简游戏内容，得出MVP（最小可用原型产品）需求列表

操作方法：通过初选和终选两部对头脑风暴结果进行评分和取舍。

初选，筛选点子的评分依据

• 艺术资源需求量（美术&音乐）
• 感觉它好玩吗？
• 感觉编程实现它好玩吗？

终选，通过者进入必不可少清单，落选者进入锦上添花清单

• 没了它游戏就无法运作了
• 开发相对容易

“必不可少”需求清单 = 最小可用原型产品（Minimum viable product – MVP）
“锦上添花”需求清单 = 2.0版

3. 撰写电梯游说稿

作用：进一步精简游戏核心内容，初步检验游戏品质。

操作方法：把MVP的需求清单撰写成一段简短、激动人心的“电梯游说”稿。或者把他想象成游戏包装盒背面的游戏简述，它能否吸引玩家购买？

电梯游说稿举例：

你是一个坏人。有一对恋人想见面。你的任务是使用障碍物把他们隔开，阻止他们相见。这是一个基于A星寻路算法的回合策略游戏。

4.游戏流程故事板

作用：通过故事板数量衡量并精简工作量，模拟试玩，了解美术资源需求

操作方法：电梯游说稿的漫画版，画在一张纸上，别超过10幅图，可以给朋友看看。

要点：出现以下情况可以考虑放弃后续开发：

• 无穷无尽的故事板——内容过多
• 看起来不好玩

5.无美术核心玩法游戏原型（MVP）

作用：检验核心游戏机制。

操作方法：无选关界面，1个关卡，仅包含核心游戏机制

要点：此时别在美术上浪费任何时间，早期美术资源都会在最终版被遗弃。

6.美化MVP（首个存盘点）

作用：完成具备核心玩法，画面勉强过得去的版本，从现在起随时可以发布最终版了。

操作方法：加入部分美术资源（可以只是临时性的资源），测试游戏性能

7.不断完善游戏，但每次只专注于一项工作

作用：一步一个脚印向最终版前进

操作方法：从各种角度改进打磨你的游戏——游戏开发最有趣的部分开始了：游戏功能、美术音乐、文字对话……

要点：不要全面出击，每次只专注于一项内容，直至达到一个最低限度的可用状态。

8.多多存档

作用：天有不测风云，人有旦夕祸福，如果明天你因为某种原因无法继续这个游戏的开发，至少你有一个可以发布的近期版本。

操作方法：

• 安全：频繁备份、使用版本管理系统。
• 迭代式开发：每次专注于一项工作内容，频繁发布，始终保有一份可以发布的游戏版本。

9.有始有终

作用：游戏只有被玩家玩到才能体现他的价值。

操作方法：果断地结束游戏开发，将剩余功能移到2.0版功能列表，发布游戏！

• 接受不完美——你仍然有机会在后续版本中完善它。
• 尽早发布，频繁发布——获得玩家反馈，获得更高曝光量