|
诸行无常 ――网络游戏设计经验谈
文：刘勇（新疆人在流浪），授权GameRes独家发布，请勿转载！
系列：新疆人在流浪：诸行无常（第一章、职场篇）
新疆人在流浪：诸行无常（第二章、玩家篇）
新疆人在流浪：诸行无常（第三章、管理篇）
新疆人在流浪：诸行无常（第四章、心得篇）
新疆人在流浪：诸行无常（第五章、设计篇）
新疆人在流浪：诸行无常（第六章、心态篇）
新疆人在流浪：诸行无常（第七章、结束语）
3. 管理篇
3.1. 零容忍（完）（重点）
3.1.1. 解释
项目的成败，取决于对问题的容忍。 零容忍，是一种态度，即对游戏中一些出现的问题和BUG……必须解决，决不回避的态度。 任何事情……决定效率的一个重要指标，都是对问题的态度。所有机构的成熟与否，都是找到应对问题，实施“零容忍”的机制。 ……
但在实际的游戏开发中，我们却通常很难做到“零容忍”。主要有如下几方面原因： 1、核心开发者缺乏管理素质，总是在忙而缺乏系统的规划。 2、一些问题在报批之后，有时无法立刻解决，或是目前解决起来代价较大。于是暂时“放一放”。之后，这个问题的“关注度”就逐渐减少，一段时间大家习惯了之后，就淡出视野。 （不得不说，这是团队的通病，许多时团队的成败就在于能否克制这一点。） 3、主管或主策划对问题不重视，他们通常会优先处理一些正在进行的事物或是比较习惯做的事物。 如果QA不够强势，就很难推动对问题的关注。 ……
对许多成功的游戏公司来说，“零容忍”已经不是一种态度，而是前提了。对于他们来说，从来不存在“改不改”的问题，只存在“事故有多大”的问题。
3.1.2. 一些“零容忍”的案例
1、２００６年６月，《MU》出现恶性外挂。玩家在游戏中可以以任何攻击力进行全屏攻击。 在当时，这个外挂之恶属于史无前例。但令人无法容忍的是，当时负责这个游戏的韩国开发公司却不知什么原因完全无视……
三周后，当这个问题开始解决的时候……经受了致命打击的《MU》也从此缓缓的退出历史舞台。 与他一起退出的，还有几乎所有的韩国游戏。 由于对游戏中BUG的轻视，问题反应的缓慢……曾经称霸一时的“泡菜游戏”将中国市场拱手让给中国本地游戏。
2、在中国，任何一家网游公司，在游戏中出现重大问题时，是一定第一时间解决。 任何时间，任何时刻，任何公司……当游戏中发现重大问题时，相关的工作人员（程序、策划、运营）必须解决问题才可以回家。 在当时，这个制度的确立，是中国网游能够击败韩国游戏的前提。
3、在腾讯，用户反馈的设计问题会直接报审。 如果经过确认后不做修改，属于“运营事故”。 之后即使是修改了，也会被追究责任，不单相应人员会被处罚，连领导都会“连坐”。 我曾经亲眼见过一次，在星期日凌晨两点，项目主策、总监、程序、市场总监赶到单位，连夜解决了一个问题。至第二天早晨１０点离开。 （而这个“问题”，仅仅是一个越级打怪会造成经验下降之类的小问题。在大多数公司，甚至根本不会被理会。）
4、在巨人，史玉柱会经常泡在游戏中，一旦发现问题和可改进之处，就会召集相应人员紧急会议（通常是在晚上９点），然后布置下修改意见。由相关人员连夜完成并测试……后半夜更新。
5、在某个成功的页游团队（“凡人”），负责人每天都在玩别人的游戏。当看到好的设计之后，就会立即组织讨论……然后连夜开发。
第二天，这个设计就会出现在自己的游戏中。
3.1.3. 黑皮书
“黑皮书”，是目前管理项目问题一个最为有效的办法和制度。
大至由如下几个步骤形成： 1、当版本提交测试后，收集意见和问题。 2、所有意见和问题汇总后收录，删除相同的内容，将有效内容汇集成册。 3、组织核心策划、程序，对内容进行评审。凡是被认可的内容均会收录在《黑皮书》中。 （目前不能执行的内容也会收录，记录为“挂起”，但要设置“唤醒”的时间。） 4、组织团队人员，对《黑皮书》上的内容进行分析，给出解决验收的时间表。 5、若因突发事件，不能完成黑皮书内容，须事先进行沟通。给出延后的时间表。 6、按时间验收黑皮书内容，若未完成且没有事先沟通者，按事故论处。 7、事故会作为考评的依据，在腾讯的作法是通报批评，并处罚金。 在菲音的作法是减少评分，影响的是年终奖。 ……
本人曾多次使用过《黑皮书》的管理方式，事实证明，在严格执行黑皮书内容，绝不容忍的情况下，项目组进展顺利。效率极高。
但在有时“有情可缓”、“暂不执行”的情况下，项目却经常陷入泥沼……效率极低。
3.1.4. 绝不容忍
1、绝不容忍当问题出现时，不去弄清楚原因。 2、绝不容忍当问题原因清楚时，不去规划时间点。 3、绝不容忍当时间时当出现DALEY时随意放过。（这点最关键，决定项目生死） 4、绝不容忍版本自己没跑过就扔给测试人员。 5、绝不容忍在版本推出的时期，相关人员不在岗位。 6、绝不容忍在版本的问题的时候，相关人员不去处理。 7、绝不容忍在项目有问题的情况下将项目的重心放在增开新功能。 8、绝不容忍在没有重大理由的情况下推翻自己制定的时间表，包括开发时间表和修订时间表。 9、绝不容忍策划游戏开发过程中突出奇想，修改需求。 10、绝不容忍对“习惯”、“麻木”的态度对待暂时解决不了的问题。
3.2. 规划（完）（重点）
3.2.1. 说明
指在游戏开始之前，对整个游戏进行规划。划出红线，确定什么能做什么不能做，什么能卖什么不能卖。
3.2.2. 案例：
某页游（名字保密，但群里人都知道），上线后数据一直不错。很快就破了千万，还在继续上升。 但在某天，该游戏却突然遭遇了滑铁卢，整体数据一下子一落千丈。 原来，当时游戏中有一种高级材料，是玩家的终级追求。只在副本中有限掉落。为了获得这个材料，许多玩家不惜重金砸装备、宠物……
但这次改版中，为了让玩家能快速升级，将这件终级材料变成可以直接出售的了。 ……
结果是灾难性的，这个更新一出。人数立刻掉了一大半，收入也降到之前的1/5。更糟糕的是，这次事件让玩家对游戏中的“劳动的价值”和“充值的意义”产生了怀疑。导致游戏后期一撅不振。 ……
教训：游戏设计中，需要规划出什么能卖什么不能卖。而且轻易不要突破。
3.2.3. 初期规划内容清单
1、功能清单，游戏中有多少个系统？ 2、规划出程序、策划、美术的工作量。 3、物品编号规则 4、参数表，罗列游戏中所有数据，包括取值上限 5、装备规划表，每件装备（包括坐骑、称号）对应的属性加成效果、升级效果、关键字效果、加星效果……以及投放等级。 6、经济系统，规划中游戏中的每件物品的消费、投放、掉落、兑换渠道及消费价值。 7、材料规划表，每件材料的投放、价值、应用对象 8、活动、副本规划：规划每个副本的投放时间、游戏定位、投放（刷）定位、性价比……以及每日成就中的价值。 9、总规划表：游戏中每个阶段（新手阶段、平台阶段）的时间、开放系统、收费项、玩点、交互设计 10、技能职业表 ……
建议相关策划在项目开始前将这些规划内容全部背下，并进行考试。
3.2.4. 阶段性规划内容
1、白皮书：每周项目进展情况，需要问责。 2、黑皮书：游戏中所有问题的收集整理，以及修改的时间点。
3.3. 团队中需要有人知道每人每天在做什么（完）
3.3.1. 说明
对团队的管理，是以掌握每个策划、美术、程序每天的工作进度为项目管理的成功的重要因素。 通常PM（有些项目为主策划、总监）每天上班后用半小时左右掌握整个团队中每个人的进度，同时提醒每个人今日提交或即将提交的工作内容……对整个团队的进度影响会非常大。
3.3.2. 案例
1、某项目（项目名保密）因管理混乱，整个团队陷入泥淖，五个月的时间内没有出新的版本。整个团队迷失了方向，人心惶惶。 2、新的PM上岗，将整个项目的问题整理汇总，整理成《黑皮书》。 3、根据黑皮书，规划出项目组中每个人的任务的前后顺序、完成时间。 4、PM每天上班时的第一件任务，就是跟组里每一个打招呼，提醒他今天的工作内容以及确认《黑皮书》中的内容是否可以按期完成。 5、三天后，《黑皮书》中的内容消化了一多半。 6、两周后（好像是一周后），整个团队结束了混乱期，重新开始了迅速高效的开发状态。
3.4. 活要见人，死要见尸（完）（重点）
3.4.1. 解释
人，是指交出的工作。 尸，是指下一个启动点或是提交点。 ……
活要见人死要见尸，包括两个意思： 1、任何工作项必须交出或给个合理的说法，不能不明不白。 2、指对一个暂时DALEY的工作内容设置一个“唤醒点”。 ……
此外，活要见人死要见尸，还有“零容忍”相关的内容。
3.4.2. 说明
在游戏开发过程中，因种意外会导致一些工作内容无法按期完成。这时一定要为这些发生DELAY的内容设置下一个提交点。 若是无法安排，则设置一个“唤醒点”，到时候一定要将该工作项目插入。 大多数项目组中，当一个BUG或工作内容被三次以上延期时，组内就会产生明显的懈怠情绪。 而且在排期时，因一些不可预见力（程序无法预估底层修正的时间）可能会导致你无法给出精确的时间。 于是一些应该做的功能和一些需要修正的BUG就被一次次的DALEY，直到大家开始麻木，变得熟视无睹。
3.4.3. 应用实例
1、小张（化名，真名隐去）是项目组的PM，周一开会时清点项目的上一周的《白皮书》时，发现某BUG没有修订。 2、这时与程序沟通，发现程序因版本中有更优先的内容需要实现，于是该BUG推后。 3、小张与程序沟通，预估了该任务的完成时间，于是约定十天后重新启动这个BUG的修复工作。 4、十天后，这时程序发现程序底层出了问题。于是约定将此BUG继续延后，程序无法给出时间……于是暂时约定为一周。 5、一周后，底层问题没有解决，于是再次延期。 6、经过多次延期，这时系统已经发生了很大变化。这时有许多新的BUG介入。 小张没有忘记那个BUG，仍然将其与新的BUG放在一起，重新排期。 并将其优先级放在新功能之前。 7、最终，在于新功能开工之前，程序修正了这个BUG。 ……
说明： 在这个过程中真正重要的是，小张作为一个PM，在同一个功能屡次后延的情况下，没有懈怠、没有放弃……没有被牢骚或是其它的不良情绪影响。只是固执一次又一次的将对同一个功能进行规划、排期……直至完成。 在大多数项目中，如果不这么做，这个BUG可能是永远不可能完成的。几次推进之后，相关人员开始发牢骚……在抱怨的同时，这个BUG也就开始在大家的脑海中被遗忘了……和其它的BUG一起……越积越多。 在遇到项目内容DELAY，甚至是连续DELAY的情况下……是继续公事公办？还是停下抱怨？ 将近一半以上项目的成败，就在这一念之间。
3.4.4. 案例
1、某页游公司的某个游戏中（项目名：《九天仙梦》），测试发现一个问题，于是提交给项目组。 2、项目组程序手中有事儿忙，没时间处理，于是先放了一下。 3、在忙完这个事儿之后，一些新的紧急任务下达，相关程序继续投入到强烈的加班状态之中。 4、一段时间过去了。 5、整个项目组不知何时已经处于如下状态： a) 每个版本都出现很多问题，玩家报怨，外人感觉到团队问题很大。 b) 团队每个人眼中都看不到问题了。 甚至连测试都提不出问题了，一些明显的BUG和设计问题都视而不见。 c) 大家都在拼命上功能，功能越来越多，但项目的问题却越来越多。 …… 6、项目陷入困境，不得已公司空降了一个制作人接手整个项目的管理。 …… （补充：这项目浴火重生之后，已经达到2KW的月入。）
| 
发表于 2014-7-18 17:00:15
发表于 2014-7-18 17:20:26
