系统策划,是国内游戏公司最为常见的策划岗位之一。同时,这又是一个经常被数值、美术、程序、UI吐槽的岗位:工作只挖坑,不填坑;写的策划文档看不懂,需求也说不明白;制作人、主策说什么就是什么,像个“工具人”......
所以,系统策划的核心价值究竟在哪?一份合格的策划文档应该是什么样的?近日,由腾讯游戏学院制作的《论道》栏目便邀请到了腾讯互娱光子工作室群《和平精英》项目组的系统主策划Jesse老师,和他聊了聊系统策划的工作方法论。
你可以通过下方与Jesse老师的对话视频,或者后面的采访文字摘录,了解这次的分享内容:
系统策划的主要工作是什么
Q 请问您怎么定义系统策划?很多人说不清楚系统策划具体是做什么的。
Jesse:回答这个问题之前,先得搞清楚游戏的系统是什么。 在我看来,在游戏里,除了具体玩法(如《和平精英》的经典模式)以外的所有内容,都能称为系统,比如任务系统、数值系统、强化系统等。如果策划这段时间的核心工作偏向于系统设计,就可以称他/她为系统策划。
Q 玩法和系统要怎么区分?
Jesse:玩法最直观的特点是能提供体验、产生反馈。如果用现实世界类比,游戏的核心玩法相当于一座城市的特色景点,比如游乐场;系统就好比是道路、停车场、环卫设施等公共设施。 如果景点特别好玩,玩家就算路上堵车、停车位不好找,可能排排队就忍了;如果景点不好玩,就算道路再通畅、周边环境再好,玩家可能也不会去。 但这并不意味着系统没用。系统就像一个放大器:如果两个景点吸引力差不多,哪边的道路更通畅、更好停车,玩家就会更倾向于选择哪边。同时,足够好的景点也需要配套足够好的交通、停车场等等,才能让更多的人都能无障碍地到达。
Q 那具体一点来看,系统策划的主要工作是什么?
Jesse:系统策划最主要的工作,就是根据当前阶段的版本目标,分析所需的系统功能,决策这些系统需要达到什么程度,把它设计出来、落实,并持续维护。
Q 「决策系统需要达到什么程度」是什么意思?
Jesse:假如一款多人对战游戏的组队系统,在研发的不同阶段分别要做多深?在原型阶段可能只需要保证玩家能正常组队、退出,而后面铺量的时候,组队系统就要做得比较完善了,比如增加邀请、踢人等功能。
Q 在此过程中,系统策划和制作人、主策划要怎么沟通?
Jesse:首先你要了解制作人或主策划对系统的设计定位和目标,核心体验大概是什么样的;其次,你还要问清楚他们期望玩家在系统中获得什么样的体验。
Q 具体要怎么沟通?
Jesse:比如你打算设计一个装备强化系统,至少要问主策划这些问题: 这个装备强化系统针对哪些用户群体?设计这个装备强化系统的目的是提高活跃还是收入?你对于玩家投入到强化系统的时间、精力成本,预期是什么样的?以及这个装备强化系统的辐射面——就是这个系统和其他系统、玩法的关联性。完全自产自销的系统,辐射面就是0。
Q 那玩家获得的体验和好处要怎么设计?
Jesse:这涉及到体验循环。装备强化系统通常有这些设计思路:第一种强化失败之后,装备直接报废;第二种设置保底机制;第三种是只升不减,通过概率控制,现在很多手游都这么做;第四种让玩家提升装备格子的等级,而不是装备,这种方式目前应用也很多。不同设计方式产生的玩家体验不同。 此外,你还得考虑这个系统在游戏中的目标定位。
Q 怎么理解?
Jesse:不同系统之间存在耦合关系。举个例子,在设计聊天系统时,你要了解玩家群体的特征,哪些人会聊天?在什么场景下聊天?聊天时用什么工具?喜欢发什么符号、表情?最重要的是,核心玩法对聊天的诉求是什么样的?这样你才能按需设计它。 比如国战SLG可能倾向于通过聊天系统帮助军团统一目标和策略,分享进展;而传统RPG特别注重社交生态,我们要把聊天系统的形式做得更有趣,方便玩家持续对话。 另外要时刻提醒自己,这个系统应该具备的作用是什么,现在的设计是否足够有效。不能想当然地说「我觉得做个点赞功能挺好」,而是要思考,点赞对于解决问题是否真的有帮助?要不要做进一步的闭环设计?
Q 沟通完之后,系统策划接下来会重点做哪些工作?
Jesse:接下来根据目标拆解功能点,梳理框架,把设计难点都解决掉,必要时借助数据和调研来论证设计。
Q 能举个例子吗?
Jesse:比如负责人告诉我,他要一个玩家体验比较好的强化系统。那什么叫做好的用户体验?要不要做保底?要不要做阶段性提升?要不要做装备替换?这些在前期都要考虑好。 如果实在想不清楚,你可以去观察同类型的优秀产品怎么做玩家体验,然后结合用户调研,确定设计方案,然后再去整理细节,包括UI交互样式、美术效果、服务器、客户端要实现的功能等等。 这还没完,你还要整理系统的风险点,提前规划好数据埋点和分析方案。
Q 风险点?
Jesse:系统上线之后,万一出现错误,你有没有规避措施? 举个最极端的例子,假如装备强化系统上线后,突然发现有个程序漏洞,你能不能立刻把系统关掉?或者能不能在保证主体逻辑正常运营的情况下,关掉有问题的模块?这都需要你提前评估风险点。
Q 这些风险点要怎么找?
Jesse:你可以考虑极端情况,设计通用的应急措施,比如这个功能有四个模块,我可以为这四个模块各做一个开关,出现问题立刻关闭相应的模块,再进行后续的处理应对。在此过程中,最重要的是要有整理风险点的意识。
Q 那如果系统顺利上线了,系统策划接下来的工作重点是什么?
Jesse:数据分析。比如系统上线后,玩家参与率不达标,或者没有达到预期目的,都得通过数据回头找问题。同时,你可能会根据游戏的功能、玩法变化,对系统做出一些调整。
怎么写文档并推动其落地?
Q 接下来想聊聊策划文档,你觉得什么样的文档算合格?
Jesse:按照我的标准,一份合格的文档必须要把玩家体验、系统规则、交互规则都说清楚,尤其是异常状况处理方案。只关注功能本身,不考虑边界条件的文档肯定不合格。
Q 什么是边界条件?
Jesse:以好友系统为例,如果用户用连点器每秒点100下「添加好友」按钮,很可能就会出问题对吧?你可能得让这个按钮有1-2秒的CD。再比如玩家添加好友时往往会顺带发送一句留言,有些游戏会允许玩家自定义留言内容,如果有玩家利用留言辱骂他人怎么办?这都属于边界条件和异常情况处理需要考虑到的点。 你提前考虑到的细节越多,对异常状况处理得越全面,说明你对策划案的思考越充分,这是合格和优秀文档之间的最大差别。然后如果能提供参考对象,并说明参考对象和实际设计的异同,有加分。 而且在我看来,合格的策划文档一定要有变更历史记录,这有利于系统的后续维护。
Q 这是大的原则,细节方面呢?
Jesse:细节都大同小异。文档要写清楚设计背景、设计目的和预期结果,不涉及功能的体验概述,然后就是系统设计详情以及对应的UI、美术、数值等等需求,这里特别容易忽略引导需求。 此外,宣传方案、容灾方案都可以附加在文档里。
Q 什么是引导需求?
Jesse:举个最简单的例子,系统上线的时候要不要加个小红点?如果系统特别复杂,要不要设计教程?
Q 明白了。那后续推动系统落地的过程中,系统策划要注意什么?
Jesse:要认识到你不是任务发布者,而要抱以合作的态度让大家理解为什么设计这个功能?想实现什么目标?然后大家一起合作解决问题,提出优化方案。
Q 如果方案遭到质疑,产生矛盾了该怎么办?
Jesse:这时一定要冷静。你首先要考虑,矛盾产生的原因是什么?是功能设计本身有问题?排期赶不上?工具不支持?还是成本太高?换位思考,寻找最优解。 第二,你要对自己的诉求要有清晰的认识,哪些系统设计可以妥协,妥协到什么程度?哪些不能妥协?有没有替代方案?不要一根筋怼下去。 第三,你需要适当了解其他岗位的基础知识,特别是跟美术和UI交互沟通时,不要说「我觉得这样不好看」,因为这是在质疑对方的职业技能。如果你懂一些专业术语,能用行话说出你的意见,他们其实都愿意和你交流下去。
Q 系统的最终效果和时间节点要怎么把握?
Jesse:每个项目组都会有相应的工作流程,你按照流程制定好时间计划,保持频繁的沟通和验收。这没有什么技巧,不要偷懒,到点就按时验收。
系统策划如何避免成为“工具人”?
Q 最后聊聊职业发展相关的话题。你们一般会怎么招系统策划?
Jesse:不同面试官注重的点可能不一样,逻辑思维能力、表达能力、游戏经历大家应该都会看,也会重点关注候选人的项目经历,以及他/她在项目中的沉淀和总结,这些总结一定要是由他/她思考并亲自设计的内容,而不只是参与过的项目。 此外,我会关注面试者应对挑战时的反应。比如面试过程中,我突然对你的观点提出反驳,观察你的应对策略。策划天天要应对各种各样的挑战,有的来源于老板,有的来源于美术,有的来源于程序.....
Q 我看到有些招聘会要求,「完整参与过若干款已上线的产品」,为什么要强调已上线?
Jesse:游戏策划不像程序和美术,他工作的价值往往只能通过产品的价值体现。而只有经过市场验证的产品才能证明,你设计出来的系统真实的效果如何。
Q 很多公司招资深系统策划时,会要求他对某个品类的系统有深入了解,怎样才算深入了解?
Jesse:这没有特定的标准,从我个人角度看,深入了解分为几个方面: 第一,你要了解产品背景,每个系统的诞生都脱离不了它的背景。你去反拆系统设计的时候,不能只关注这个系统的亮点在哪,你要知道它基于什么情况上线,才能理解这个系统为什么会做成现在这样。 第二,你要知道为什么系统会做成这样,它在做的过程中可能考虑了哪些环节,最终产生的作用是怎么样的?这个系统对游戏产生了什么影响? 第三,你要寻找这个系统的相关系统和相关玩法,梳理它们是怎么互相影响的。 第四,你还要判断,这个系统有没有优化空间?假如你是负责人,要进一步优化这个系统,应该怎么做? 综合来说,一定要理解系统的设计背景、设计过程、结果和相关性,这才能叫深入。
Q 系统策划工作的时候一般会用到哪些工具软件?
Jesse:通常Office就够了。然后如果项目用UE4、U3D或者Cocos等工具,策划至少要具备相关引擎的应用能力,然后还会用一些项目管理工具,每个项目组都不太一样。
Q 您觉得一个合格的系统策划的标准是什么?
Jesse:首先得具有策划的通用设计能力。在此基础上,一个合格的系统策划必须要知道,如何验证自己设计的东西是好是坏。 他/她要学会有始有终,而终就落在有没有能力验证自己设计的系统是否符合预期。如果只会做起始,不会做终结,就无法真正成长,在我这就不算合格。
Q 我们上一期《论道》栏目和一位数值出身的主策聊过类似的话题,你觉得系统策划的数值能力有多重要?
Jesse:一个合格的系统策划一定要有数值解读能力,但可能对数值设计或规划能力要求没有那么高。
Q 一般制作人、主策划会对项目做整体把控,那系统策划如何避免成为一个......
Jesse:文档“工具人”是吧?成为工具人确实不好受。 我觉得,想要避免成为工具人,你得重视数据,把数据埋点、分析计划用起来,帮制作人和主策划发现问题,提出解决方案,哪怕一些思路也好,千万千万不能当哑巴。如果可以的话,你甚至要尝试提出游戏后续发展过程中要重点解决的问题,或发展方向。
Q 更主动地观察和分析数据变化的原因?
Jesse:对。游戏的问题一定会体现在系统数据上。以好友系统为例,假设社交生态出了问题,好友添加率和通过率一般会降低。 如果好友通过率下降了,假设我要相应优化系统,我得先知道玩家喜欢通过哪些途径加好友,这是从量的角度分析。 有没有可能再进一步,从质的角度去分析?比如玩家通过哪些途径添加的好友,后续互动率更高?PvP、休闲玩法、游戏大厅还是世界频道?想解决问题,得整理、分析数据背后的信息,提出解决思路和方法。 如果你想快速成长,思考过程中一定要把眼界拔高,着眼在项目层面看问题,只顾着写文档、追进度是不行的。
Q 有什么具体的方法吗?
Jesse:比如你给自己定一个日常目标,每天必看哪些数据,这样你一定能最先关注到数据的异常。然后每隔一阵子,你要留出一点思考的时间,不要让自己太忙。天天埋头苦干,很难抬头看更宏观的东西。
Q 最后一个问题,系统策划是不是必须要玩遍市面上所有的热门游戏?
Jesse:同品类的游戏最好都要深入了解。再就是借用一个比较时髦的词,系统策划要注意「打新」。
Q 怎么理解「打新」?
Jesse:去玩新的游戏。因为新的玩法体验或对已有体验的改善、优化经常会诞生在新产品中。这些新游戏的设计可能不一定正确,但它有可能给你带来启发,这就够了。
暂无关于此日志的评论。