单人项目管理—心得和教训

引言

单人独立开发可以说是最自由的一种形式了，如果再加上不以开发游戏为主业，往往就会诞生一些…………永远做不完的作品。

对游戏开发有热情的人很多，但是大家的热情通常都只存在于“自己想做的游戏”之上。这就使得业余开发的团队难以凝聚。相比开工资的专业团队，或者主创能让人信服“这样做下去能赚到钱”的团队，一群业余爱好者凑在一起往往很难团结起来做出一个较大的项目。很多情况下，我们只能选择自己单干。

因为单人开发不需要迁就任何人，想改需求就改需求，单人项目的管理比起团队要困难得多。这里笔者仅以个人开发中的经验和与他人交流的体会，谈谈单人游戏开发的一些心得和教训。（偷偷说下，很多事情笔者自己并没有做到）

立项

虽说做任何事情都得搞清楚到底要做什么。但是对单人开发而言，“到底在做什么”这个问题是很难回答的，在开发过程中需求可能会因为各种各样的原因而变化。越大的组织惯性越大，而单人则是一个念头就足够推翻整个游戏的设计。

虽然明确需求很重要，但是也不能因此而害怕改变，毕竟灵活性是单人开发最大的优势之一，开发的过程本身也是寻找并确认需求的一环，独立开发者不用像大团队那样有着明确而稳定的安排，或是小型团队那样害怕伤害队友的感情不敢改需求，可以享受甲方乱改需求的快感（虽然接锅的乙方也是自己）。

因为不需要和团队进行沟通，也不需要和赞助商之类的人交流，单人项目的项目文档并不需要对游戏的类型和玩法之类的基础信息进行详尽而严谨的描述。相比于那些能够打印出来贴在墙上的项目文档，独立开发者的项目文档是要时常进行编辑的。但是理清楚自己“现在想要的是什么”也是非常重要的。

一个在各个地方被各种人提过很多遍的方式就是“用一句话概括你的游戏”，像是“波澜壮阔的田园史诗”这样什么有用的信息都没说的也好，或是“基于卡牌系统的故事用适量的随机性来处理类牧场游戏‘每天不知道该干啥’的问题”这种像毕业设计标题一样的也好，或是干脆“这是一个银河城”也好，把最开始的时候，想到的用于概括这个游戏的一句话，写在项目文档的开头，然后不要去改它，即使项目变成了可以完全将其无视的样子也不要去改它。这句话对于把握项目的全貌有着无法取代的作用。

独立开发者往往都会对“创新”有着很大的执着，甚至会羞于提及自己的游戏像什么游戏。虽然这种心情很普通，但是“了解和自己的游戏相像的游戏”对于开发的帮助是非常大的。很多人可能会觉得“你这个游戏像 XX”不是什么好话，但是大家也都知道，自己喜爱的游戏的痕迹一定会留在自己开发的游戏之中的，那些能够激发人们“我要做个游戏”的冲动的游戏更是如此，像是 Mother 之于 Undertale，牧场物语之于星露谷。不要羞于提及自己的游戏中那些游戏的痕迹，而是要正视他们，这样可能反而更能打造属于自己的独特性。毕竟像“类银河战士恶魔城”，直接把自己模仿的游戏打进了标签，但成功的作品都有各自的特色和长处。

时间

这是项目管理最核心也是最根本的问题之一了。独立开发因为没有明确的期限，在时间安排上也会和团队项目有巨大的差异。

暑假作业和毕业设计之类的东西，存在着死线，很多人都知道暑假开始时定下的作业计划最后往往会变成漫无止境的八月的结尾。和暑假作业不同，游戏开发不仅仅是交差完事，而是精益求精，打磨是个无底洞。但同样的，我们会害怕作业和毕业设计的死线，对于独立开发这种自发的死线就不那么重视了。

“独立游戏没有准时”，对单人开发来说更加如此。大型企业有相对严格的死线，小型团队有共识，哪怕只有两个人也会对拖延有所顾忌，而单人就只有“虽然我今天什么也没做但还真是辛苦了”，对于有辛苦的本职工作的更是如此。

或许有些人会有“一年没做好就去找工作”“毕业之前做完”“做完这个游戏就回老家结婚”之类的期限。没有这种期限的自由开发者，只能手动造一个死线出来。在其他人面前“承诺”一个死线，或者阶段性成果完成的时间表出来，在 indienova / 微博等地方吹牛比较安全，在众筹网站吹牛可能会导致死线压力变得更具体，笔者没有试过众筹所以也不好说那样有没有用。

即使再老道的开发团队，也很难正确估算游戏开发的必要的时间，但他们能制定出相对宽松，能确保完成整个项目需要的时间。对于独立开发者而言估算时间的精确性要低得多，但同时估算时间的必要性也没那么高，时间安排上可以相对宽松。这是出于工作积极性和情绪的考量，每天都能按进度完成任务，相比跟不上进度，积极性会相差很多。不过这也和个人有关，需要大家结合自己的经历来考量。

“完整项目经验”对于时间的安排的能力是非常关键的，不管多小的项目，哪怕是 48 小时的 Game Jam，从0到1完成一个完整游戏的经验，对于一个完整游戏的进度安排也是十分有帮助的。

提到“完整项目经验”，独立开发者或许应该把“儿时梦想”级别的设想暂时搁置，先去做几个没那么梦想的游戏练手，毕竟大多数独立开发者，做出来的前几个游戏的完成度和品质都比较一言难尽，而从中得到的经验则是无比宝贵的。要是真有以之为人生理想级别的设想，可以先尝试做机制类似的“原型”作品，一开始经验不足的时候直接上手做出来一个不够完善的作品，然后因为角色/故事已经用过了没法重新做，就容易失去热情。

计划

和专业分工的团队不同，单人开发势必要一个人负责各个方面的任务。就像暑假作业数学做不下去了做英语，英语做不下去了做物理一样，任务的多样性可以保持积极性，画画画累了写程序，程序卡 Bug 了做设计，设计不知道怎么下手了就画画，以“其他的工作”作为调剂进行休整，相比专注于一项任务，可以保持更长时间的工作效率。

但是这样子也会降低专注度，尤其是程序，分散程序工作可能会导致经常要花时间去理解自己之前写了什么鬼东西，或者是出现同一个功能的变量写了三次，三次的名字还都不一样的情况。

在任务安排上，将任务明确地细分，可以经常性地通过“完成一个个小任务”来提高积极性。任务划分太大，可能会感到无从下手，一个个零散的任务可以一步一步做下去。但是因为单人开发，尤其是缺乏完整项目经验的时候，对于任务的预估往往会有巨大的误差，难以准确地划分任务。

因此，在制作出了一个包含了每条任务及各个任务对应的工作量的计划表之后，我们要对“对任务工作量的评估”进行评估，简单的方式就是记录下每天完成的工作量与实际花在开发上的时间，对于工作中的业余开发者来说每天能抽出的时间可能不太稳定，我们可以结合实际情况以三天或者一周为单位计算工作量。观察一个周期内的工作进度推进是否稳定，并作出相应的调整。

美术

美术是很多独立开发者之所以没有成为独立游戏开发者的原因，大家通常都觉得画画是件很困难的事情，但实际试过之后，画画会比想象中的简单不少。（当然了，如果有不会画画的人觉得画画是件很简单的事情，那画画肯定会比想象中的难）

大家不用把画画当成非常困难的事情，要画到职业画师的水准当然是很困难，但画到顺眼/看得过去/画风独特的程度并没有那么难，就像《东方 Project》的 ZUN 绘那样，只要下决心去画，总归是不会在树上吊死的。

相信自己能画的信心很重要，这倒不是什么精神论，而是相信的人会去画，不相信的人不会去画，这么一个单纯而根本的区别。比起一开始就觉得“哎呀我不行的我得去找可以用的素材”的人，愿意捏着鼻子硬画的人……虽说也画不了多好吧，但他们能把游戏做出来，而前者通常都会放弃。

美术的下限可以先用方块凑数，上限可以像达芬奇那样花四年画一幅肖像，各种素材都可以慢慢打磨。素材的尺寸和 UI 设置相比更为关键，尺寸的改动往往会牵扯到很多素材，虽说为了调整尺寸再画一遍能够画得更好，不过能够避免的大改还是尽量避免为好。

音频

音乐和音效要自己做出能用的水平就比较困难了，但是音乐和音效相比美术，有很多公共领域的古典乐等资源可以使用，或者是很多素材商店的资源包。作曲的技术比较困难，但是“安排合适的音乐”这项技术对外行人来说更为重要，在平时可以多进行积累，把潜在的可用 bgm 当工作时的 bgm 使用以感受气氛，寻找合适安排的地方，或者干脆依据音乐来设计场景也是可行的。虽然这话让使用雨声和室内环境音做 bgm 的笔者来说可能不太合适。

设计

设计大略可以分为核心机制和内容增补两个方面，包括美术等工作的安排都要建立在核心机制的确立上。或许核心机制会常常改变，但是一开始必须要有一个完整可用的核心机制方案，以此为基础设置之后的任务。

就像在核心机制确定前先凭感觉做成就系统最后不得不删掉一大堆不在游戏机制最终定案内的成就，或是设计了对逃跑的敌人有特效的招式但是到最后发现敌人逃跑的机制已经没了一样，内容的填充要基于核心机制的确立，“可能会有所变化”的任务可以放在“会导致变化”的任务后面。

大家可能都会害怕核心机制的改变导致之前做的工作被浪费，但不要为此把“之前做的工作”放在权衡”要不要改变核心机制”的天平上，那是团队需要面临的困扰，独立开发者应该把改变核心机制的灵活性发挥到最大，毕竟优秀的游戏往往不是一开始就顺利地设计好，而是在不断地改变和打磨中成型的。

程序

感谢现代科技的光速发展，大多数个人作品都可以省略优化的环节，使用粗糙的算法实现想要的效果，相比一切都要斤斤计较的 FC 时代，现在的开发者要容易很多。

在实现方面是非常容易的，尤其是有相对专业的编程技术的人，在功能的实现上很难遇到多大的问题，即使是没有什么基础的人，只要本着“没有一万个 if 解决不了的问题，如果有就再加一万个”的精神，大多数功能都能顺利实现。但是在 Debug 上就会遇到很多麻烦了，解决已知的 Bug 容易，而难以复现甚至不知道是否存在的 Bug 要麻烦得多。

对没有专业基础的程序来说，最常见的问题是不重视模块化，直接复制粘贴公式和函数之类的东西，常常会出现“要改动一个数字，需要改动好几个地方‘的现象，增加了工作量倒不是问题，遗漏某处的修改导致本应相同的部分出现了差异则会导致很多问题。凡是改一个数字需要改两个地方的情况，最好尽可能地把它们修改成只需要改一个地方就行的形式，包括 UI 坐标等变量。

对每个发现的 Bug，以及做出的修改都要进行详尽的记录，在处理同类 Bug，或者因为修改 bug 而导致的 Bug 会非常有用。

即使再单人的单人项目，在“测试“这项工作上还是要寻求大家的帮助。大家会提出很多根本没有考虑到的问题，或者发现因为对自己的游戏太熟根本发现不了的 Bug。（比如笔者的朋友就拆掉了一个笔者从来没拆过的建筑触发了 Bug）

完成之后

独立开发者，都会有个通病。

做完一个游戏之后，心累得不想再看到这个游戏，但是对做别的游戏则充满了动力。毕竟单人开发者大多数是“点子”驱动的，做新的游戏的动力远大于打磨和完善旧作的动力。不管是有潜力的点子也好出色的故事也好，短时间内都提不起劲去进一步加工。如果旧作大受欢迎还好说，反响一般的游戏，吸引力是比不上“尝试新的作品的”。就像 Game Freak 就算背负骂名也要抛下宝可梦去做 Town 一样，对本就热衷于做游戏的独立开发者，做游戏的重要性是远大于完善游戏的。当然，恶性 Bug 和承诺是一定要处理的。

完善旧作还是开发新作先放一边，对旧作进行的总结和思考是必要的。回顾整个开发过程，总结记录下开发过程中遇到的问题和解决的方式，不管是要完善也好新作也好，都能从中得到无可取代的经验。