全文3800字，阅读约需8分钟

一、前言

此致写在即将“校招毕业”的离别之际，借用制作人的话来说“校招生应该是对这种体验感到比较新鲜的”。 确实，在某族倒贴实习165天之后，我们光荣的“毕业”了。所以，也刚好成趁这个机会，把这段时间的经历重新总结一下，看看我都得到了些什么。

本篇中不包含具体的设计思路及实现方案，后面有机会的话会在脱敏的前提下讲讲

二、杂谈感想

1.  什么是系统策划

现代电子游戏设计中，设计师会把游戏看作是一个个子系统以及这些系统之间的关系构成的一个“结构”。所以我们会根据项目的不同，划分出系统策划不同的工作职责和界限。但通俗来讲，系统策划顾名思义是为游戏中的各个系统构筑规则和体验的设计师。设计师会根据当前阶段的版本目标，分析所需的系统功能，决策这些系统需要达到什么程度，并把它设计出来、落实，并持续维护。

不同研发阶段所做的要求会或多或少的有些不一样，例如组队在原型阶段能有基础功能加入、退出就行，后面需要铺量的时候再增加邀请、踢人功能。所以在正式开始做需求写案子之前，首先要跟制作人或主策划对齐系统的设计定位和目标，以及核心体验大概是怎么样的？

一般对新人来说，还是要确保至少问清楚制作人或主策这几个问题：

1. 这个系统针对哪些用户群体？
2. 对于玩家投入到这个系统的时间、精力成本的预期是怎么样的？
3. 以及这个系统的辐射面，即该系统与其他系统、玩法的关联性？

在问完这些问题的基础上，为了让玩家获得好的体验，要考虑两方面：体验循环，系统在游戏中的目标定位。例如装备强化中，有以下几种常见的思路：第一种是强化失败后直接报废；第二种设置保底机制；第三种只升不减，通过概率控制；第四种让玩家提升装备格子等级，而不是装备。而实际开发中要选择哪种就是要根据项目及系统的自身体验预期和定位来决定了。

另外，也要时刻提醒自己，这个系统应该具备什么，现在的设计是否足够有效？不能想当然的说“我觉得做个点赞功能挺好”，而是要思考，点赞对于解决问题是否真的有帮助？要不要做进一步的闭环设计？

沟通完之后，接下来就是根据目标拆解功能点、梳理框架、把设计难点都解决掉，必要时借助数据和调研来验证设计。如果实在想不清楚，一是抄同类型的优秀产品怎么做玩家体验；二是结合用户调研，确定设计方案。然后再去整理细节，包括UI交互样式、美术效果、客户端、服务器要实现的功能等等。最后，还要整理系统的风险点，提前规划好数据埋点和分析方案。

这里面的风险点是指系统上线之后，万一出现错误，你有没有准备规避措施？例如装备强化系统上线之后，突然发现程序有个漏洞，你能不能立刻把系统关掉？或者能不能在保证主体逻辑正常运营的情况下，关掉有问题的模块？这些风险点通常可以通过考虑极端情况，设计通用的应急措施来避免。比如这个功能有四个模块，我们可以为四个模块各做一个开关，出现问题立刻关闭相应的模块，再进行后续的处理来应对。

如果系统顺利上线了，系统策划接下来的工作重点就是转移到数据分析上。比如玩家的参与率不达标，或者没有达到预期目的，都要通过数据回头找问题。同时也可能根据游戏的功能、玩法变化，对系统做出一些调整。

但不过归根结底，在做系统需求的时候还是会有以下5个方面作为工作的参考范围。

• 创意——负责游戏系统玩法设计，以及针对不同类型用户的需求进行衍生玩法设计
• 交互——设计各种系统和玩法的交互界面，让玩家能通过游戏内的图形交互使用系统和玩法
• 执行——推动设计方案的落地，验收并优化功能点，对玩法的最终品质负责
• 数据——针对游戏产品上线后的数据进行分析，持续改善游戏产品
• 文档——以上种种，都需要使用策划文档的形式来进行交流

系统策划能力维度图

2.  写策划案

策划案不是只要简单的将设计师脑子里的想法输出成文字文字就好，更是作为与开发交流、存档的重要手段。所以在写案子的时候就应该保证好每一份案子的质量，不仅是写出这个案子要做什么，更要写出对团队有价值的内容，让程序和美术认为这事是值得他们付出努力的。

那么，要怎么写好文档并推动落地呢？一份合格的文档必须要把玩家预期体验、系统规则、交互规则都说清楚，尤其是异常状况处理方案。不过，只关注功能本身，不考虑边界条件的文档肯定是不合格的。

边界条件指的就是系统中一些需要考虑的细枝末节的异常情况，你提前考虑到的细节越多，对异常状况处理的越全面，说明你对策划案的思考越充分，这是合格与优秀文档之间的最大差别。例如好友系统中，如果用户用连点器每秒点100下添加好友按钮怎么办？我们就要为这个按钮添加1~2秒的CD。再例如玩家利用留言功能辱骂他人怎么办？这些都属于边界条件和异常情况处理需要考虑到的点。

文档内除了写清楚设计背景、设计目的和预期结果外，就是系统设计详情以及对应的UI、美术、数值等需求。这里特别容易忽略的是引导需求。引导需求就是怎样告诉玩家我们新出了这个功能，是加个红点？还是弹窗式教学？都需要在文档内写清楚。

简而言之，一份合格的策划案至少需要包括以下5个方面

• 系统简介(what)——即它是什么，让人看一眼就知道这个系统是个啥
• 设计目的(why-1)——即它有什么用，解决了什么问题，提高付费、增加可玩性、满足玩家某项需求？
• 需求分析(why-2)——即进一步挖掘设计思路，列举我们游戏的一些特点，找到这个系统的设计边界在哪里，把握设计要素不超纲
• 初步方案选型(how-1)——即它具体玩什么，列举市面上主流的系统并分析其设计优劣，分析我们可用哪些方案及理由
• 落地执行(how-2)——即执行人员实际的工作内容包括哪些，包括系统的核心机制和逻辑、策划配表、UI需求、特效等美术需求等，并在最后附上功能点和验收标准方便QA提测

当然，上述这5点也仅仅只是最基本的框架，实际在写案子的时候其实还需要关注一些更细节的点，如下文所述

1. 在方案选型的时候，我们的系统需要设计出比竞品更精巧的地方，例如在创意角度上的突破，而且很可能只有我们产品有
   • 同时，也需要做好到各个方案的风险预估。并在未来做系统设计时预留好可拓展性和冗余，预估好开发的难度和成本
2. 在落地执行时，需要换位思考到程序和美术，想想他们要怎样才能生产出我们想要的资源
   • 提炼出系统的核心机制，并列出其业务流程图；
   • 拆分整个系统的单环依赖关系图，列出基本元素、梳理系统耦合、并说明元素之间的关系；
   • 列出系统流程中所需的数据结构。建表、确定数据类型、配置方式（增删改查操作）、以及缺省值
   • 然后就是进行分工安排，确认好谁干什么，以及具体怎么做，美术什么时候能完成，程序什么时候能接入。不要出现有人前置没做完，后面就一直等着的情况。
3. 系统上线之后，获得了玩家数据，就要反过头来分析回顾设计案，当时我们这么做的方式是否是对的。即产出的内容及动机是否达成了目的，人力资源是否有浪费，哪些东西是有技术屏障或难以落实的。
4. 最后，也是最重点的，在庞杂的、耦合性高的系统中提炼出共通的系统逻辑、数据结构与各个关联项，方便其他系统调用这共通的底层逻辑，以及助力项目的工业化搭建。

3.  科学的方法

3.1 研究方法

这一部分其实没有太多值得说道的地方，大部分还是基于过往学术研究习惯做出的基本操作。不过其中的文献回顾会对应的变成“竞品拆解分析”就是了。

3.2 制作方法

按照目前业内工业化的趋势，其实更多的时候是在建立规整的生产管线并复用，以此来降低生产成本并提高效率。不过各个项目中的管线都会或多或少的有些不同，但大体上的思路仍然是总结成功的经验，设立标准化模型，并通过一系列标准化的生产，将责任具体落实到每个PO头上，以此按照计划来生产内容。在此仅是作为个人的一种工作习惯来进行分享。不过有一点可以注意的是在实际开发中，由于工期或成本的考量，往往并不需要一步做到最好，只需要满足当期版本的基本需求，往后再慢慢优化迭代即可。

4.  职业发展

在我看来系统策划的发展更多是一个偏经验向的积累，简单来说还是逻辑思维能力、表达能力、游戏经历，以及项目中的沉淀和总结。而且这些总结一定是要由自己思考并亲自设计的内容，而不只是复述参与过的项目。所以这段时间我也会抽空将这段实习中做过的系统进行一个系统性的复盘梳理，尝试提炼出一些系统设计的通用方法论。或者换句话说，更加深入的去了解这些系统的逻辑。关于深入了解，这里便借用Leader的话来描述了

• 你要了解产品背景，每个系统的诞生都脱离不了它的背景。你去反拆系统的时候，不能只关注这个系统的亮点在哪，要知道它基于什么情况上线，才能理解这个系统为什么会变成现在这样
• 你要知道为什么系统会做成这样，它在做的过程中可能考虑了哪些环节，最终产生的作用是怎么样的？这个系统对游戏产生了什么影响？
• 你要寻找这个系统的相关系统和相关玩法，梳理它们是怎么相互影响的。
• 你还要判断，这个系统有没有优化空间？假如你是负责人，要进一步优化这个系统，应该怎么做？

综合来说，一定要理解系统的设计背景、设计过程、结果和相关性，才能被称之为深入了解了一个系统。

三、小结

其实这大半年来也是说长不长说短不短的一段经历，

从一片混沌的DEMO状态开始，到终于像模像样的大规模铺量的预上线阶段；

从一个个新系统验证落地，到接收玩家数据反馈并进行针对性的体验优化；

从一开始仔细的梳理挑清每一个系统之间的相互关联、画出关联谱系图，到熟练的在系统间建立新关联，做各类全局系统级的规划；

这段经历让我想了很多，做了很多，学了很多，通过实践验证了很多之前学到的理念，也跟更多专业的人交流了设计思路，

只可惜… 可惜没有如果吧 

从开赛前的“赢一把就算胜利队”一路笑到了最后