七阶子博客: 杂文 | 游戏 | 戏剧 | 白蛇 | 文艺 | 编程 | 近期
请输入标题关键字或 yyyymmdd 格式的日期

    策划文档的价值传承——从需求文档到归案文档

    我从事游戏行业也有数年了,从策划转做服务器程序。因而对游戏策划这行颇有些怨念——此为中性词,就是想记录一下行业经验吧。

    从理论(理想)上说,策划才是游戏作品的灵魂,而技术(程序与美工)不是,它们只是(电子)游戏产业的基础而已。然而(国内)游戏策划现状却是普遍太水,这不仅是由于入门门槛低而拉低了平均水平,同时也由于游戏策划这职业本身的目标与手段不够明晰所致。这话题抛得太大,故本文试图从一个方面,策划文档这个角度来聊写一番。据我接触的几家游戏公司,不论大小,策划文档的质量都非常缺失的。

    玩游戏与做游戏(策划)是完全不同的体验。玩游戏真的只要会玩就行,当然会说就更好(比如开黑时可以带节奏或喷赢别人,获得额外的成就感),至于写神马游戏攻略,那全然是个人爱好问题。然而做游戏策划应该要求这个写技能,不是写攻略,是从设计者的角度写策划文档。

    策划文档是游戏策划独立价值的体现

    独立价值是什么概念呢?最好通过类比说明。

    例如美术的独立价值很好理解吧,一张原画就有独立的观赏性(或叫艺术价值?),就游戏工业角度论,至少就有参考性的价值,可以让萌新依葫芦画瓢。程序的代码也一样,不管是客户端还是服务端,即使没有(比如权限)另一端的代码,或没有策划配置的具体数据,那一套代码本身也内含着游戏框架、设计模式、数据结构这些基础(虚泛)的编程技术(技巧),也能反映实际游戏的具体玩法逻辑。

    这就是独立价值。任何大的整体价值,都是由独立的局部价值组合而成。尤其是在开发阶段,各部分还未能整合一体时,独立价值显得更为关键。

    然而游戏策划的独立价值如何体现,用什么来记录与承载策划们日夜加班的辛苦工作的价值?除了策划文档,似乎找不到更好的载体了。总不能在游戏上线后向玩家宣传这个游戏都是策划价值的体现,虽然游戏不好玩的时候,玩家似乎只会骂策划。

    所以,需要写策划文档。这在其他行业领域几乎是显而易见的正确的废话,与各种圈的鸡汤语录差不多。但令人惊奇的是,在做游戏时真的经常被漠视。

    然后扯点题外话,现在技术先进了,可以录音,硬盘与带宽也便宜。那么对于只会说不会(不想)写的策划文档,是不是可以录音代替?即使你说话始终像演讲或讲课那么清晰有条理,只怕也不行。因为录音需要每个接收者都花相同的时间去听完录音,这是对接收者的不友好,也不利于快速浏览或翻回去找重点。这也是微信群聊用语音存在的问题。于是,你需要更先进的技术,比如语音输入法(插播广告:讯飞输入大法好,虽然我不用),或者从录音文件语音识别转化为文稿的技术……

    然后发现,在严肃工作领域,还是踏实写文档得好。玩游戏不是件严肃的事,但做游戏应该是。

    策划文档的同步更新维护:归案文档

    业内另一个易犯的误区是,以为策划文档就是一次性的需求文档,把一些脑际大开的奇思妙想塞文档里扔给技术开发(程序与美术)就完事了。

    而在实际开发过程中,总是会有意外或其他客观条件限制,可能并不能完全实现策划想要的功能。最终效果与最初的策划需求文档越吻合,代表团队的契合度越高。但即使一开始有很高的吻合度,后面也可能需要扩展与修改,也即常说“需求总是变化的”。

    当需求有变化时,策划应该同步修改需求文档。但不知业内有多少策划有这样意识与觉悟。策划不应只是指手划脚的工作,不是成天扛把大砍刀在背后催着美术修图,催着程序修改(业务逻辑的)BUG。策划工作本身应该也是件技术活,将自己的设计思想文档化,并认真对待与尊重自己所写的文档,如果意识到之前的某个设计不适合,就应该修改自己的文档。如果连你自己都觉得反复修改需求文档太 TM 麻烦,不如直接跑到程序小哥的工位上说一声来得直接。那这就要当心了,凭什么认为程序(或美术)就该忍受修改的麻烦?己所不欲,勿施与人,这是平等协作最起码的要求。

    如果策划能坚持同步更新文档,根据实际开发与验收情况,及时调整文档中所阐述的玩法功能与实际效果。那么当系统正式完成时,文档就该是准确地反映该运行系统的功能。如此当初的需求文档就华丽地蜕变为描述性功能文档,这里不妨称之为归案文档。如果游戏中每个系统都有一份匹配的归案文档,其价值是不可估量的,尤其是对于有望长期运营的游戏项目。难道做游戏就满足于圈一波首充就拉倒,或直接就见光死?

    譬如当后期有新的策划或程序加入,有份完整的(归案)文档,接手极快。这可能对于新策划尤为重要。程序至少还有保底退路,直接去啃源代码。但是策划呢,如果没有之前的文档,就只能去玩游戏了。这就回到了最初的伪命题,策划的工作就只是玩游戏吗?有很多内在的游戏设计不该是玩几次就能体会到的。

    然后就是同类产品迭代,即所谓的换皮,业界不是秘密的秘密。如果有详细的文档传统,那么上一代产品的归案文档,就是下一代的初始需求文档。这才能算是真正的产品迭代,而不是简单的重复。

    反之,如果策划文档被当成一次性用品,开发过程中不再同步更新,那么策划文档的价值就会逐渐流失,直至蒸发殆尽。因为不能反映实际项目功能的文档,不仅无益,还有误导的害处。就如让新接手的策划,对照着旧文档玩游戏,发现矛盾重重,直接就产生恐慌性信任危机有没有。

    当初辛苦写的需求文档,在游戏上线后就完全没有了价值,这是非常可惜的。程序写的代码,哪怕写得再烂,只能要跑,在项目稳定运行后,都成了内在的一部分,默默地发挥着或大或小的价值。而不再更新的策划文档,就几乎成了垃圾文件,没了价值。

    也许这根源还在于对策划文档的价值认识不够充分,一开始就没认真写文档,就只是应付式的,逢场作戏式 onenight 一次性的文档,所以才能轻易地弃之如敝履。如果真的认真地写成的文档,作为自己的心血结晶,是不会忍心它莫名其妙就价值蒸发的。

    所以,请把策划当作一种技术活,把策划文档当作技术文档,认真地同步更新维护,纳入项目的版本控制系统(如 svn)。美术的 psd 都能提交版本控制系统,策划文档还会更大吗?诚然,程序与美术都有更成熟的工作流程,能更好地进行版本更新维护。而策划文档,似乎没有公认的规范,但这不应是拒绝维护的借口。各个团队或项目组应该探索或发展出自己的策划文档规范。

    文档缺失的示例场景

    文档缺失最极端的情况是一句话需求,“这个功能很简单,怎么实现我不管”。

    策划应不应该管实现,这要看哪个层面的实现。(电子)游戏不是普通的软件或网络应用。作为一个软件实现,策划显然是管不了的(否则要程序做什么),但作为一个游戏,其玩法功能逻辑,是应该由策划掌控的(否则要策划做什么)。

    一句话需求,是策划偷懒完全不想写具体玩法细节与逻辑的需求。如果策划与程序的默契度极高,比如多年的老战友,或许这勉强成立。这是成本嫁接的成果,你不能总指望有这么幸运。如果你的团队真的由于一句话需求完成了一个系统功能,首先恭喜,其次你不该过度消费这种信任。

    这里的建议在系统开发完成后,请反补归案文档。跳过不确定的需求文档,根据最终态的成品补充一个描叙性功能文档。这将是项目的可贵遗产。为后期运营维护与继续开发提供良好的指导。这其实有一定的合理性。因为一开始天马行空的需求文档,由于项目的实际情况都不能确定哪些做得了哪些做不了,如果要合理维护文档,就不可避免要对策划文档大加整改。而在功能做完后再整理文档,就节省了许多工作量。但是,如果完全不写策划文档,认为功能都做出来了就没有必要写文档了。那就过份了。请问策划的价值体现何在,一句话需求的含金量那么高吗?

    当然了,更常见的工作流程是先有了一份(或简或详的)需求文档再开工的,只不过在开发过程中反复修改,如果没有维护策划文档的意识,文档与产品就逐渐分离,渐行渐远。

    举个栗子。假设想要控制某个特殊掉落(抽卡、开宝箱什么的),策划自以为得意地想了个正态分布,觉得这能实现更好的用户体验。这似乎个比较有趣的想法,程序组也觉得可以做。但是实际分到做该系统的程序小哥,不幸高数挂过科,跟他解释半天理解不了什么是正态分布,让他找资料折腾个几天也未能很好地实现。于是策划为了项目进度还是什么原因,只好妥协,就简单点用平均分布好了。然后过了段时间,调了个能力比较强的程序加入,策划觉得可以搞事了,就说给我实现正态分布来看,或者也试试泊松分布?然后程序写完了,策划又觉得这概率的东西太难以验证了,怕把握不了,还是改回简单的平均分布吧。

    且不说这反复修改的来由,只说结果。如果没有及时跟踪维护策划文档,策划自己确实能肯定这系统在实际运行时采用的是什么概率分布吗?也许一年半载后的某一天,策划(或另一个策划)看着这资源掉落,“感觉哪里不对”,却忘了当初的设定。只好来找程序让他查下代码看看到底 TM 是不是正态分布。如果程序组也换人维护了,可能他也只好一脸懵逼地反问你,什么是正态分布?

    游戏系统的功能设定,本应该由策划维护文档记录与把握的。如果策划后来还要经常性地来找程序反查游戏逻辑设定,那就是策划文档价值的流失。你把雇用来的程序当作客服答疑来使了,这是人力浪费,不合理。而如果说通过放弃自己的价值,来侵占别人的价值,那岂只是不合理,简直是不和谐。

    或许这个栗子,假想的成份多些。因为现实生活中,了解正态分布的策划未必比程序多,不一定就会提这种奇葩需求。但是真实的开发环境,也许情况还要糟。因为大多数的策划案只会抄别的游戏。但是简单的抄只能抄游戏界面,抄不到内在的逻辑。于是很可能系统做完,有些逻辑策划自己还稀里糊涂,只好去问程序某某功能具体是什么逻辑。而程序在没有明确规定的情况下,能做出什么功能来只能是随机(随缘)了。然后策划也只好跟着感觉走,“感觉还行”的就接收,“感觉不对”的就继续改……

    抄游戏本来也没什么可苛责的。但是,能不能干脆把“抄”的精神进行到底。在抄完别人的游戏后,在自己的游戏做完后,对自己的游戏多一份关爱与尊重,将自己实现的游戏再“抄”成一份定稿。这样的一份归案文档,记录着自己的游戏的实际效果(比如将需求文档中的各种参考截图,都该换成自己游戏的截图啦)以及一些重要的逻辑细节。这才是真正承载了自身游戏项目的价值的策划文档,必将后用无穷。

    因此,从需求文档到归案文档的价值传承,初听起来复杂,其实也没那么复杂。需要的只是文档规范与执行力度。而且,既然是奔着归案文档的持久价值来的,那初期的需求文档可以相对简略,开始不确定的实现功能可以从简,而后面满意的成熟的产品功能越是值得详细记录。这将是整个项目乃至整个游戏团队、公司的宝贵财富,是可以独立于程序、美术三足鼎立的策划文档价值。

    用 Excel 写策划文档

    本文的最后部分,打算讲点形而下的工具论,这会更加倾向于一家之言。

    现在伏案办公的白领(码农不算)的日常工作,几乎都被 Office 三剑客一统江湖吧。 PPT 适用于演讲向的文档,比如(忽悠)拉项目;Word 适用于打印向的文档,比如呈报申请资料。而 Excel ,天生适合于电子办公文档,它不仅可用于填表,其实也可以用来写文档,所以我也推荐用 Excel 来写(组织并管理)游戏策划文档。

    用 Excel 写策划文档,有一些良好的特性。首先是页面布局非常自由,这对于像游戏策划这种充满创意的工作来说很合适。自由不代表随意,只是说你可以根据自己的项目与团队情况制定自己的文档规范。比如下面列几条简单的约定规范,仅供示例参考:

    其次,页面自由,也意味着(几乎)无限大的版面空间,你可以方便地张贴大图,比如思维导图,或者须用其他工具制作的原型图,或者就是直接的截图。想像一下,在 word 中插入大图是多不适用。当然如果真的非常巨大或庞大的思维导图,也许也不方便贴在 Excel 中。如此就只贴链接,将 Excel 当作主控的资源管理,辅以注释说明,链接到外部参考文件,包括视频录像。

    再次,也是自由的极致,就是可 VBA 编程。其实个人并不热衷 VBA ,如果这算一门脚本语言,那就是比较差劲的一门语言。但是在 Office 套件中,毕竟 Excel VBA 最出色(Word 与 PPT 也能用 VBA)。VBA 也不是只能用来算数而已。在 Excel 内保存的信息都是高度结构化,不管是数据向的纯数字,还是文档化的文本,都是可寻址、易定位的。就比如只要按一定规范标记一级标题、二级标题,Excel 就有办法统一设定其样式,字体、颜色、大小,诸如此类的,让文档更加漂亮与醒目。

    这就是说,用 Excel 写文档,潜力无限,当习惯与依赖于 Excel 写文档后,完全就有可能利用程序化工具将写文档这种粗活自动化或半自动化,提高生产效率。基础的 VBA 并不复杂,只要有实践机会都能学会。即使当前策划团队没人会 VBA ,也可以期待将来招到一个会 VBA 的策划。再或者,游戏公司好歹是 IT 企业,就是专门调个程序员过来研究 VBA 以提供技术支持,也是值得的。

    不过,最后要提醒的是,如果也用 Excel 作为配置表数据,请将文档工作簿与配置工作簿分开,当然可以在文档工作簿中加上配置的链接,但避免太强的耦合。