Chapter 03

看文档都是怎么说的。

在项目刚刚立项最开始的那一段时间里，假如你有幸已经参与到了制作中，就会发现很多事情基本上没人知道是怎么回事儿。总的来说，一个项目的引擎，多半都是由别的引擎增减而来。打开引擎，你会看到别的游戏的flash screen。可以说，就连负责引擎的程序都未必有个底：他们接受来自项目各个部门的要求，给这里加点功能那里添行代码。到了最后，编辑器不用说也肯定和原来大不相同了。你没办法追溯这些改动最初的想法和意愿是什么，多次重复的会议也会让你一脑子糨糊，但是文档会安静地躺在sharepoint或者共享文件夹里面，除非有人动它，否则决不会自己个乱成一锅粥。就算是有人捣乱，你也可以根据上面的署名和更改人找到罪魁祸首，跑到他的座位前面一把揪住他的领子，大声质问他这个功能或者那个特性到底是什么意思，怎么实现。

有一段时间我对很多美工的沟通能力挺纳闷的：他们几乎没法儿和公司的洋人们进行有效率的交流，基本上多半是My name is wendy的程度。后来有人一语道破梦中人：关卡设计要写文档的啊！文档能力，尤其是英文文档能力，被作为许多海外或跨国公司招聘时对应聘者硬性的需求之一而重视。根据我的经验，一次项目伊始的培训会议，比方讲，“如何使用Unreal引擎”，在它结束的时候，平均每个与会者只会记住会议内容的百分之三十。具体哪百分之三十固然因人而异，不过大部分都是最开始的那些。考虑到这样的会议往往会持续两个小时左右，通常又会以英文召开，这个数字可能要再打一个折扣。你可能会做这样的联想：就好像是战争，只要牢记培训中所学到的一切，你就能活着做完这个项目的说法纯属扯淡。当然不出意外，不违反公司章程，你多半总能活着做完项目，不过这和是否牢记住了培训内容无关。因为公司不大可能设立一个职位，专司项目引擎的教学与应用。它是那么多变，活像是午夜时分地铁架桥下满是涂鸦的廊洞，可以被程序在一天之内就改得面目全非，没法儿指望一次性的宣讲就能让大家掌握所有将来可能发生的情况。理想的情况下，与会者都尽可能地记住了互不相同的部分，并且在会后互相教授。即便如此，也要浪费大量的时间和精力，其效果差不多相当于和每一个与会者单独开上两个钟头，让人昏昏沉沉的会。因此最好的——尽管未必是最有成效的方式，经过多年经验总结的方法论：看文档，就成了这种问题的解决之道。

即便是一个制作周期少到可怜的小项目：11月立的项，来年2月份就要Alpha，也有数不清的文档。排除人们在这种风险不大周期短的小项目里做各种管理实验的因素：Scrum、数据分列、多平台同步开发、高清低清模型branch、RLD……各个部门也有大量的文档要写：引擎、GPP、游戏设计、关卡设计、美工、QA、人事、管理、模型、音效、数据管理……说起来讽刺，如此多的文档需求量，搞到最后实在是超出了饱和度，导致的结果反而是文档来不及写，真正放在sharepoint上的文档远远不够制作队伍参考和学习的。当然，我们有这样一个人卯足了劲把重要的文档挑选出来优先撰写，以保证制作的基本需要，不过总的来说还是杯水车薪。更要命的是，大家因为实在找不到文档，所以干脆就把这个写文档的人当作活文档，旦分有任何不明白的都会去问他，从而造成这个人更加忙碌，更加没有时间写文档的恶性循环局面。是了，这个人就叫做技术指导。

就个人而言，我十分喜欢技术指导的活。你可以认为是好为人师的虚荣心作祟。没有什么能比联合多方力量解决一个问题，然后告诉大家：“嘿，哥们儿们！打今儿起咱们就可以用spawner生敌人，不用再一个个费劲地拖进编辑器里面去了！”于是所有人都很高兴，弹冠相庆更叫人心旷神怡的事了。而在此之前，基本上你若是多放了些什么东西，出于数据整齐的考虑，打算删掉多余的副本，那么这种电子洁癖多半会要了你的命。有些引擎喜欢把数据结构在出人意料的地方多放那么一份，会导致在进行删除操作的时候丢失连接和参照，不知情的人在每天常规的一百多个警告中漏看了，上传了，一下子就能把数据结构破坏掉，阻滞所有人的工作进度。当然这部分是因为个人工作态度的问题，部分则是因为基于成本控制而自主编写的引擎代码，肯定不如商业引擎结构严谨功能完善纠错率高所致。我知道你们在想什么，“干吗不打从一开始就把事情给收拾好呢？”这种念头并不鲜见。我认识一个资深的美工，在三四个大项目之后还会对反复的工作进度大肆抱怨：他们怎么不一开始就把事情弄好呢？这个习惯直到他成为美工技术指导后还残留着，我总能看见他和关卡设计的Leader在争论，为什么不能一开始就计划好？为什么不能一次性的弄好？为什么不在出问题之前就杜绝？为什么要把地图做这么大？！为什么……你瞧，我并非蔑视美工这个工种，只是这种追究过往责任而不是着眼于解决目前问题的工作方式，实在是对进度无益。假如事先能够有一份详尽的，或者至少尽量详尽的文档，也许情况会要好转许多。

这又回到最初的问题了：我们是否有足够的人手和时间来写完备的文档？在文档不能提供百分之百的帮助以及解决问题的时候，我们是否在对毫不留情地使唤技术指导这件事上，无需抱有人道主义的怜悯？答案是非常肯定的。一个胜任的技术指导，往往忙得口吐白沫，一额头虚汗，还得不停地给各路人马打黑工，平均每天重复三遍某个特性或功能的调用和使用方法。因为和项目预培训会议一样，文档能够灌输给目标对象的，也只有其内容的百分之七十到八十——这个数据是在文档语言为英文，受体以平均工作热情边阅读边在编辑器里实践的条件下统计出来的。也就是说，那些“哦shit是一个英文文档，这怎么看啊！”“金山词霸呢，金山词霸呢？！”或者“办公室好热……”“午饭没吃饱……”“好想打DoTA……”“好我明白了！嗯……咦，第一步是干什么来着？”他们从文档里面获取的信息将更少。这个时候，一张满头虚汗、口吐白沫的脸盯着你，手把手地告诉你应该这样做和那样做，并且在完事之后若有所指地加一句：“文档里都写了呀！”的时候，其威慑效果将会尤其明显——哥们儿您瞧我这头汗，这嘴沫子，劳驾能受累看看文档么？

因此你看，文档能力是如此地重要，以至于那些抱着不切实际的“策划”念头的毛头小伙子们，总以为只要生花妙笔口若悬河，有精妙的设计和划时代的点子，写个长篇累牍就能拯救游戏业……时代又不是腰花儿，哪儿能那么容易就被吴下阿蒙给划开？正确而出色的文档往往显得十分整齐、有条理，但同时非常枯燥。与其说是一份攻略，倒不如说是说明书，而且还是日产电器类的说明书。不厌其烦地告诉你每一步该怎么做，可能会遇到的一百零一个问题，这些问题的解决方式，并且统统配图。同样地，它会显得比较蠢，把著者和读者都置于一个理解和阅读能力的最低限度，这样保证所有人都能读懂它，并且按部就班地就能在工作中实现。从现在开始，事情就和闪闪发光的创意、灵光乍现的设计以及打破常规的新尝试一点儿关系都没有了。游戏设计师的文档讲述的都是关于某些物体的长、宽、高，主角能跳多高、跑多快、从几米高的距离落下来就得摔死而从几米高的距离落下来则只会受伤；关卡设计的文档则是关于如何设置物件的属性，开关量在什么地方，怎样连接不同的路点，该怎么关联触发器的逻辑；美工会读到关于贴图规格，UV的展法，地图大小的限制，靠用单位大小来测量参考图物件比例的小窍门；GPP和程序的文档可能最多最长，在引擎研究的路上他们可谓从项目开始就一路走来，你进办公室的时候几乎都能看到上个月他们编撰出来又废弃掉的代码以微弱的电磁型态在空中飘散。甚至连人事都有一份文档：如何在经济危机的大环境下技巧性地辞退员工，包括一套翔实的流程表和措辞模板，甚至连对方的各种可能反应和表现都有专门针对性的对策。

自然可以理解，既没有色情描写，又缺乏引人入胜的行文，难怪即便出色的文档在灌输信息时也会有可观的损耗比。最好的办法，从长时间的实践总结而言，无非就是将文档置为总在最前，后台开着编辑器，按着上面说的一步步做来。待到唯手熟耳的地步，做他一百多个pokect mockup，进行填鸭式的理论-实践转换。随着项目经验的增多，你会发现虽然不能说每次需要做的事情都是大同小异，但起码能够举一反三。至少，一个三天两头就要换引擎的工作室多半是在瞎折腾。这个时候我们需要做的事情无非就是根据经验——通常我不会用揣测这个字眼——来判断程序写在引擎里面的函数可能是怎样的运作机制，现有地图里的gameplay大概是通过什么方式来实现的，脚本事件该是如何一个制作步骤。然后尝试，失败，再尝试，再失败，喝口茶，上个厕所，尝试，还是失败……直到成功或者碰巧找到一个恰好知道这都是怎么回事的人。摸着石头过河是一个比较不专业的说法，一般我们会美其名曰“调试”。它将是伴随整个关卡设计师项目生命最为痛苦，也最不可避免的噩梦。