|
|
写在前面的话：
文档（策划案）是帮助策划沉淀想法，管理者评估和对接人执行的依据，是策划行使权责的证据，具有不可替代的价值。因此除非“敏捷开发”思想下先做后补文档的工作流，其余情形均需写文档。
而策划可以借助通用模板统一格式，降低阅读成本，更能形成一种工业化的思考流程，将系统的全貌思考清楚，以此保证系统品质的高下限。同时随着经验增长，策划可将需注意的点补充完善进模板，从而提高自己思考的深度和广度。
而在文档之前，策划最好将备选方案写在XMind思维导图上（设计案），与上司确定最终方案后再写正式文档（执行案）。根据系统规模，设计加执行案花费的参考时长如下：
- 小型系统（红点，公告，选角，设置等）2-3天；
- 中型系统（抽卡，商城，技能等）5-7天；
- 大型系统（交易行，自由捏脸，装备框架，战斗框架等）1-3周，甚至更长。
时长包含与上司确定最终方案并返回修改所消耗时间。根据项目进度，系统方向可能转变，策划需及时同步到文档中，并标注修改日期。
- 注意1：文档重要的是思考得出的具体方案而不是字数/措辞或格式，勿喧宾夺主。
- 注意2：文档更注重功能的最终效果，实现方式推荐弄清楚但不强求。
文档的开头：
记录文档的修改情况，方便自己对比修改内容。
模板的正式内容：
一、总览
1.1 设计目的
此系统存在的目的，需要策划站在游戏大方向上客观评价该系统对游戏体验/目标玩家/自家项目产生了什么作用或意义。
举例：1）XX系统在特定条件下能给玩家带来某体验，符合项目大方向的需要，比如新增每日资源玩法，利用随机buff选择功能降低其他日常单一刷图的枯燥感。或者当前游戏环境存在问题需要需通过XX系统改进，如大世界跑路太麻烦需要新增便捷传送功能，对战卡牌竞技场套路单一需引进ban/pick机制等。
2）付费玩家关卡体验容错太低，为降低其挫败感增加付费复活机制。或者MMO里老服务的新玩家需要限时的成长补偿机制来跟上大部队进度等。
3）满足项目组的KPI需要，如为了增加收入/拉新/回流/维持市场热度而新增轮换的运营活动等。
（注意：设计目的不涉及游戏内的具体概念，以防文档阅读者不理解或撰写者没思考清楚大方向）
另外，目的能生效需要遵循设计前提，即做方案时绝对不能违背的标准。分为两类：
- 项目要求：项目已成立的结论和上司对系统设计的总体要求。比如项目定位轻度大众化，所有功能规则都需要简单明了避免抽象并高度符合直觉。或上司认为方案一定要在市面上找到原型，则设计目的就需要考虑已有成熟案例。
- 项目类型的设计原则：不同游戏类型鼓励和避免的点不一样。比如给MMO制定玩法就需鼓励玩家社交组队获得的收益高于单人体验。或动作竞技游戏类型需考虑怎样让玩家主动相遇并发起冲突，或是对局失败后有途径转移挫败感。
1.2 系统概述
- 简略描述帮助阅读者快速了解方案是什么，分为几个阶段（最好有粗略的流程图），但不包含细节描述。
- 该方案是因为什么才可以达到设计目的。
- 如果系统有改动，分段阐述舍弃，保留，新增了哪些设计，改动原因和日期。（为方便对比，过往所有的记录都不能删除）
*粗略的流程图：只列举功能拆分为哪几个基础模块（橙色方块）和旗下的子功能（紫色方块），并展示基础模块和子功能的流程关系。举例如下：
1.3 系统定位
此系统在游戏整体框架上扮演怎样的地位，它的出现会对其他系统产生哪些影响（比如出一个资源流转图）。系统定位更多从系统资源循环和玩法体验上着手，并使用游戏内的具体概念进行阐述。举例：为达到刷装体验有起伏有惊喜不枯燥的目的（设计目的），新增装备属性随机功能（具体方案），其属性强度上限高下限低，玩家击败精英怪获得，平均概率为中低强度，低概率获得上限（系统循环中的定位），体验上为假随机有保底机制，给予玩家一段时间内的强度加速体验。（玩法体验上的定位）
系统定位由设计目的分解和推导而来，是实现目的的具体落地方案，单独开一栏是为了让撰写者和阅读者审视方案是否可以达成目的。比如：ACT游戏中设计伙伴助战系统的其中一个目的是新增养成线延长游戏寿命，那么系统定位上就要思考伙伴是第几重要的养成点，属性给多少，资源如何流转，其养成节奏，玩法体验是怎样，对玩家游戏目标是否会造成冲击，不同付费的玩家获取的方式是怎样等诸多在游戏环境中的具体问题。如果逻辑冲突，阅读者能很快发现从目标到定位的推导有问题，需要修改。
1.4 名词解释
对程序/美术/其他策划可能看不懂的术语或词汇进行解释，以帮助其阅读文档。需注意名词尽量控制在个位数。
举例：【随机装备】含有最多4条随机词条的装备，拥有独特的物品贵重等级。强度定位上下限与通用绿装持平，上限较高相当于金装，但出现率低。
【系统】：由不同独立部分组成的，并且能够相互联系和协作的一个有明确输入和输出的整体。
【功能】：组成系统的，对系统完整运作产生影响的独立部分。
1.5 拓展规划
一般指以下几点，如没有可以不写：
- 系统往往不是一次性做完，如果有迭代计划可以写在这，标注大致启动的节点日期。
- 该系统需要配合哪些配套功能可以更好地实现设计目的，但暂时无排期计划的，可列出功能名称，概述和原因，以供阅读者参考。
- 该系统是否有备用方案，如有则可以简单提及名称，概述和原因，仅供阅读者参考 。
二、功能实现
2.1 详细流程图
将概述中拆分好的所有模块分解为最小单位的子功能，并以前后流程的形式展示。此张大的流程图包含前后端要处理的所有逻辑，便于程序把握功能整体。（注意：外部功能与本系统的联动也需要用虚线标出来，例如跳转至某个界面）
2.2 基础模块一
2.2.1 子功能一
简洁叙述此功能的大致流程和规则，并贴出该功能的UI界面或UE交互图，需标注数字序号。
如果有多张界面图，需标注相互之间的跳转关系。
2.2.1.1 开启规则
- 此模块的开放/结束的时间点：玩家角色XX级/具体年月日/某个前置系统的变化如任务完成等。
- 功能开放持续时间：部分系统或玩法会有时间限制，从X时到Y时结束。
- 开放/刷新/重置频率：部分系统或玩法每天/周/月/永久开启/限制使用X次。
- 位置和表现：UI或NPC入口在哪，是否有开放预告功能，开放时是否会有特效动效过场等展示。
2.2.1.2 界面元素规则
- 数字标识处的前端功能的定义和详细规则：界面元素的排序优先级/刷新时机/运作流程/计算公式等。
- 该数据的获取途径：表格/写死/玩家输入；初始数据填什么，完整数据的预期效果如何。
- 极端状态下的处理情况和对应的界面显示：空态/有数据时的普通状态/封顶状态。
- 不同尺寸终端的适配规则：一般为四周贴边，非四周居中。
- 前端性能需求：在妥协后的美术表现下的FPS最低帧数；多人同屏是否自动隐藏其他人以平衡性能等。
2.2.1.3 特殊规则
系统在特殊或极端情形下的固定规则，以避免BUG或塑造更好的体验，只能靠策划积累的经验来定夺。
- 组队状态：单人剧情关卡，有玩家未解锁时的处理方法，奖励如何分配；进入关卡前有不满足条件的成员处理方法；组队状态被邀请参加其他事情等。
- 离线状态：断线处理或重连机制，数据如何恢复；叠加组队状态下各成员状态怎么显示。
- 特殊激励：首次通关时的额外奖励，玩家执行某个行为会有彩蛋内容等。
- 容错率：玩家在误操作比如误点击离开关卡按钮后需要二次提示；脱离卡死；背包容量不够后获得的奖励放入邮件等功能；策划填表有错误ID如何提示；加入公会设置冷却时间防止重复领取奖励等。
- 与其他系统的联系：系统之间相互关联，某个系统状态的改变可能会引起其他系统的BUG，写文档时需提前对可能发生的问题给出解决方案。比如：公会有排行榜，如果公会解散则排行榜需要立即撤下其排行并对排名进行刷新，如果没考虑到则解散时可能公会仍停留在榜单上，但是显示名称为undefined。
2.2.1.4 后端需求
涉及数据的来源，保存和流转，有余力可以考虑清楚（出现BUG时可以更快定位），没空时也可全权交给后端安排。部分项目需要策划案前后端需求分开，可按需求将流程图分别做一份前端的和后端的。
- 数据的流转：该系统中，数据在前端的哪个阶段发送给服务器。显示时，前端在何时收到后端数据，如果没收到数据，界面该如何显示。
- 数据的存储：该信息储存在客户端还是服务器；数据来源是什么，是否需要做验证；数据存储的最大条数，数据溢出时的处理方法。
2.3全局功能需求
系统存在一些共同的功能需求，推荐在做每个系统时都逐个思考检视一遍，完善系统体验。
2.3.1 红点需求
某种情况下，需要在以下界面如图处增加红点，以提醒玩家执行某种行为。
注意红点属于负反馈，与游戏核心收益相关的部分可设置，其余可不加或使用视觉上弱化的橙点。
2.3.2 便捷功能
- 引导玩家认知的功能。查看道具时的【获取来源】信息；帮助玩家决策的信息【99个1级宝石可合成X个5级宝石】；查看相关系统信息时的【跳转界面】按钮；重要决策时的【二次确认】按钮等。
- 预测玩家行为的功能。选择数量时的【MAX】；副本中的【再次挑战】或【下一层】；缺少材料时的【快捷购买】；领取多个奖励时的【一键领取】等。
2.3.3 新手引导
需要引导玩家操作的部分写在这。推荐核心系统使用强引导（必须点击正确位置才能触发下一步），次要设定使用弱引导，玩家主动点击时才触发引导，一般为图文界面。
2.3.4 行为监测
- 为防止BUG的条件检测。如进入关卡前的背包容量检测，队友网络信号强度等。
- 新旧账号数据冲突时的兼容性处理。
- 特殊数据的异常值检测。比如移速，视距，CD等容易开挂修改的属性，可触发反外挂手段；亦或者每日资源获取上限，如果超过临界值时需锁定收益并提醒项目组。
2.3.5 控制开关
- 进程开关：运营活动或玩法类常见，能在紧急状态时（运营事故/不可抗力/重大BUG）关闭功能的显示或可交互性，甚至可以强制中断使用该功能的玩家行为。
- 功能开关：系统给到玩家不同体验的可选项，一般统一放在设置界面中。比如MOBA类型的智能/手动施法切换，MMO的是否自动播放世界频道的语音消息等。
2.3.6 后端数据打点
本功能的哪些数据在什么情况下需要在后端记录。一般是有：
- 验证功能中使用率，玩家留存情况，方便项目组验证设计的情形。
- 监控服务器特殊资源产出的多少，并在超过上限时提供预警，方便排查BUG。
2.3.7 智能排序
所有表格中有字符串输入的地方推荐增加自动排序，常见的有高品质物品在前，低品质在后。表格ID从小到大等。此类自动排序可避免手动填错，根据实际情况可选择是否引用此功能。
2.3.8 Tips提示&公告
此功能有某种技巧或者功能需要玩家知道，一般显示在loading界面中。
玩家的某种行为可触发公告，并显示在世界聊天频道/跑马灯播报/手机推送信息中。
2.3.9 GM命令
输入指令可方便测试系统全貌的功能。
三、数据库
功能需要哪些表格，表格之间如何关联，表格中每个字段的含义是什么，都可以在这里看到。
功能总表：XXXX；模块和子功能表格：XXXXX
四、其他策划需求
4.1 系统：设定需求
一般是新增道具的需求，及旧道具如何修改。
4.2 数值：产耗需求
- 产出：产出道具的种类/爆率/获得限制等，及不同付费的玩家的标准获取量。
- 消耗：回收道具的途径种类/消耗量和时间分布情况，及不同付费的玩家的养成曲线等。
- 属性：功能产出的角色属性强度收益；敌人的属性强度等。
最后贴出数值配套详细文档地址：XXX
4.3 关卡&战斗：玩法需求
- 敌人角色：怎样的形象，什么数量，需要怎样的技能，爆出的东西是关卡给还是怪物独立掉落。
- 场景和交互物：需要多少关卡，其尺寸和承载的战斗大致体验是什么等。
最后关卡配套需求文档地址：XXX
4.4 文案：描述需求
系统如何与游戏剧情大纲/世界观设定结合起来，包括：系统名称和文本；背景故事；道具概念包装；相应角色和场景等。
五、美术需求
美术需求字段写多少取决于美术团队的地位，以及合作者是否希望加入自己的设计想法，可灵活增减美术需求点。如果策划没有太多美术基础建议全权交给美术团队，只写名称/需求和参考图。
六、验收进度表
七、游戏或资料引用
展示撰写人方案的原型，方便阅读者审查或溯源，也可以拓展其他策划的思路。有时间的话推荐写写，可积累阅历。
示例：功能原型来自——《暗黑破坏神3》萃取系统：
萃取”功能是通过消耗日常任务材料，将特定装备的特殊效果词条转变为玩家被动技能的过程。玩家最多可在3个不同部位上携带其中一种效果。（最新版本取消了部位限制）。该功能帮助当时的游戏环境扩大build的组成思路，并缩短了新角色前中期打宝过渡的时间。
写在后面的话：
模板的最终意义是帮助策划思考得更加全面，希望大家多多积累，不断完善自己的思维，做出质量上乘的作品。
文/魏泽征
来源：游戏设计研究所
|
|
发表于 2024-1-15 09:26:45
