多杰游戏学

本页面只读。您可以查看源文件，但不能更改它。如果您觉得这是系统错误，请联系管理员。
====== 版本活动系统设计 ======

单有**机制期**的耐重复系统，虽然理论上可以撑着让玩家玩一段时间了，但在玩家眼中，显得没有诚意，毕竟你“没有更新啊”！  

在玩家眼中，一个健康运营的游戏，每个月都出活动的，哪怕这个活动一模一样。这也是现代手游的一个节奏。  

我们当然不能每个月都提供纯粹一模一样的内容，也不可能每个月都生产全新的系统给玩家享受，所以额外的**版本活动系统**，就出现了。  

这种系统简单来说，就是：

<note>“客观的框架固定，主观的内容改变，伴随着付费点，让肝氪玩家都可以得到稳定的收益”。</note>  

同时，还要符合我们的流程：  

  - 用理论设计  
  - 用经验防御  
  - 用工具校验  
  - 用数据确认  


===== 活动设计结构 =====
{{:知识库:设计相关:pasted:20240913-153551.png?400|版本活动的结构}}

==== 商业层 ====

从数据方面，考虑活动的目的是为了赚钱，活跃，还是品牌，或者是三者之间的组合，明确通过哪些指标在多次活动间做出对比，验收合格程度。一般来说，商业目的都是一些相对目标，如**“本次付费额目标比上次多8%”**或**“游戏付费额要与竞品一致”**等。商业目的指导设计目的的挑选逻辑。

==== 设计层 ====

明确商业目的后，对玩家群体进行**用户分群**，分析并挑选最大化商业目的的用户需求，并产生对应的n个设计目的，设计一个完整的活动系统框架并用**OPF表**证明体验的完整性。设计层的目的主要是统筹全局，思考框定需求的上下限，避免犯错。

==== 体验层 ====

体验层负责在设计层的框架中填入具体的内容，进行体验验收，检查是否有设计层缺乏考虑导致的错误，对照需求验收表进行活动验收并产出**数据埋点方案**。

==== 收入需求 ====

即活动的盈利需求。  

**付费率**：每日付费用户占活跃用户的比例。 

  付费率 = 付费人数 / 活跃人数  

**ARPPU**：每付费用户收入，反映每个付费用户的平均付费额度。 

  ARPPU = 付费金额 / 付费人数  

**ARPU**：每用户平均收入，注重一个时间段内运营商从每个用户处所得到的收入。

  ARPU = 付费金额 / 活跃人数  

==== 活跃需求 ====

活动需要有一定的活跃需求，不能片面追求盈利而导致大量用户流失，影响以后的收入。简单地说就是**“把韭菜留住下次割”**。

  * **活动流失率**：检查活动造成了多少用户流失。  
    活动流失率 = （活动上线前一天的在线人数 - 活动结束后的第一天在线人数）/ 活动上线前一天的在线人数  
  * **活动唤醒率**：检查活动吸引了多少潜水老玩家上线。  
    活动唤醒率 = （活动第一天相比前一天新增在线人数 - 活动前一天相比活动前两天新增在线人数）/ 活动上线前一天的在线人数  
  * **活动留存率**：检查活动期间深度参与了活动的玩家占比。  
    活动留存率 = （活动上线第二天肝满当日积分限额的用户占比 - 活动上线第一天肝满当日积分限额的用户占比）/ 活动上线第一天肝满当日积分限额的用户占比  
  * **收益流失比**：检查新增收入产生的代价是否巨大。  
    收益流失比 = 活动期间付费总额 / （活动结束后的第一天在线人数 - 活动上线前一天的在线人数）

==== 品牌需求 ====

有些公司并不靠游戏营收生存，而是靠口碑积攒拉投资等，这时候活跃和收入就不是最重要的因素了。各大平台的好评占比与评分、玩家社区的口碑才是最应关注的维度。

==== 分群维度 ====

我们需要定义玩家群体，进行**用户分群**以分析不同群体的需求。为了避免遗漏某些用户群体，我们通过三个用户属性参数排列组合进行分群：  

  - **肝度**：肝度属于用户个人属性，分为两种参数：愿意肝（1）和不愿意肝（0）  
  - **氪度**：氪度即区分大中小R的参数，故在此分三档：大R（2）、中R（1）、小R（0）  
  - **练度**：练度带有时间因素，属于客观事实属性，这里分为三个参数（可对应活动难度设计的难度梯度）：大佬（2），普通（1），萌新（0）  

{{:知识库:设计相关:pasted:20240913-154623.png?400|用户分群表}}

====需求模板库====

常见的需求数据库，通常来源于当次活动商业需求推导出的群体需求、基于知识推导的需求（例如其他游戏的经验）和基于自身运营经验的安全需求，在需求模板数据库中基于最大化商业目的的逻辑挑选出设计层所需要的设计目的。

{{:知识库:设计相关:pasted:20240913-160231.png}}

因为当初设计时候没考虑印刷问题，所以排版有些丑陋，请将就看。

==== 设计目的验收表 ====
对系统框架结构进行验收，检查设计目的有没有得到实现。注意，这时活动还未上线实装，验收标准不涉及具体指标，只验收维度。活动验收表是从需求模板库中抽取挑选出来的。

==== 系统验收表 ====
对详细设计进行验收，用OPF表检查系统是否有完整的体验。

==== 数据埋点方案 ====
体验层设计完成后，要明确本次活动需要得到哪些数据，然后对一些活动环节进行数据埋点，在活动运行期收集相关的微观数据进行体验分析，在活动结束后收集相关的宏观数据进行商业验收与总结。

==== 微观数据 ====
与玩家体验有关，一般精确每天每个关卡，例如关卡留存漏斗、活跃玩家平均游戏时长等。

==== 宏观数据 ====
与商业目的有关，只关心活动期间的总体宏观数据。

===== 活动设计流程 =====

{{:知识库:设计相关:pasted:20240913-161410.png|活动设计模型}}

^ 编号 ^ 目标 ^ 方法 ^ 备注 ^
| 1 | 得出商业目的及验收指标 | 数据分析、开会讨论 | 本次活动付费额较上次提升10% |
| 2 | 用户分群，分析需求 | 对照用户分群表进行主观分析 | 又肝又氪的大佬需要有养成反馈和氪金的优越感，偶尔也会需要氪金护肝 |
| 3 | 挑选出本次需要实现的需求列表 | 以最大化商业目的逻辑挑选需求清单 | 例如本次活动商业目的为提升付费同时控制收益流失比，那么我们的主要考虑人群就是氪度高的人群，同时也要兼顾肝度高的人群，然后挑选这些人群的群体需求进行实现。 |
| 4 | 更新需求模板库 | 若发现需求模板库中存在没考虑到的点，及时反馈更新 |  |
| 5 | 在需求模板库中挑选设计目的 | 在库中查阅是否有自己没考虑到的用户需求，结合本次需要实现的需求产生设计目的 | 有不少基于运营经验的安全需求是很难通过用户需求分析得出的，通过查阅获取这些经验才能在设计活动框架时避免犯错 |
| 6 | 生成一个活动系统框架雏形 | 产出一个有完整体验的活动系统OPF表 |  |
| 7 | 明确活动验收表 | 整理清单后在需求模板库中复制粘贴过来 |  |
| 8 | 系统的具体设计 | 在框架下的具体化细节化设计 | 要实现养成反馈的通常手段是有关卡难度梯度，但是具体梯度怎么定，不同的难度梯度怎么划分用户练度等，都需要具体设计 |
| 9 | 对照活动验收表进行验收 | 检查活动设计成果有没有满足设计目的 |  |
| 10 | 活动上线 |  |  |
| 11 | 收集微观数据进行体验分析 | 数数上按数据埋点方案拉数据 |  |
| 12 | 运营事故经验总结 | 处理运营事故，开会总结，更新需求模板库 |  |
| 13 | 宏观数据商业验收 | 参照商业验收维度在游戏后台或数数上拉数据 |  |
| 14 | 修正下次的商业目的 | 开会总结分析 |  |

这个模型不是告诉你活动应该是什么模型，而是说<color #ff7f27>设计出一个活动，需要遵循什么样的流程</color>。

接下来，我们接着说。

{{:知识库:设计相关:pasted:20240913-161446.png|活动设计流程(简化)}}

首先要从商业目的开始，每次活动可能有不同的商业目的，大多数情况下不会变，但在最初时，也要考虑清楚。

^ 商业目的 ^ 维度 ^ 预期指标 ^
| 付费需求 | 总付费额 |  |
|  | 付费率 |  |
|  | LTV |  |
| 活跃需求 | 版本唤醒率 |  |
|  | 版本留存率 |  |
| 综合需求 | 收益流失比 |  |

对于我们自己的项目来说，一次活动的设计明确这几个商业目的就行了，没有其他太多需求。我们提升点付费，拉回点老玩家，最后再防止在玩的玩家大规模流失。

具体的数字大家可以根据自己的实际项目情况去填写，如果没有经验，可以估填，不能不填，这样就有O，结果出来了就可以对比，下一次就有了数据。

当有了商业目的，就是明确设计目的，换言之也就是需求，举例如下。

=== 基于模板库的需求 ===
  * 参与底线：低练度甚至零练度玩家也可以获得基本的游戏体验保证。  
  * 劳有所得：为各类玩家的付出设计对应区间的奖励收益。  
  * 奖励公平：保证玩家获得的奖励收益有保底下限，同时所有奖励的获取途径公平合理。  
  * 氪金收益：设置合理的氪金梯度与氪金体验，并对氪金系统进行包装，确保氪金玩家的物质收益与精神满足。  
  * 养成反馈：对玩家的养成宽度与养成深度进行考验，设计合理的难度梯度与奖励幅度，为玩家的养成行为提供反馈。  
  * 剧情：对于游戏内的设计有背景包装，保证即使是零练度玩家也能体验到完整的剧情。  
  * 社交：通过同步或异步社交设计，保证玩家有“被需要”的感觉与互动乐趣。  
  * 耐玩性：活动关卡内容量高，重复度低，保证玩家在游玩时间内有持续新鲜感。  
  * 活动时间设置：活动时长设置、活动上下线节点设置合理。  
  * 避免玩家损失：避免玩家所获取的道具由于非正常的消耗行为（如过期）出现损耗，使得玩家利益受损。  

=== 基于安全性的需求 ===
  * 信息安全：保证基本的个人信息、官方信息安全。  
  * 敏感要素：避免出现政治或社会敏感要素。  
  * 侮辱词汇：避免出现针对特定群体的攻击性词汇等。  

=== 基于用户群体的需求 ===
  * 大R：为玩家提供一个能够进行氪金展示的平台。  
  * 技术玩家：通过活动关卡设计让他们实现自我证明。  
  * 大众：让大众产生足够的参与感，愿意主动参与活动。  

这就像写代码一样，我写之前，先写对结果的测试用例，在设计的时候，就自然的会去思考如何满足这些测试用例。

当明确了这些后，就是具体到活动的结构与流程的设计。

===== 极简活动模型 =====
{{:知识库:设计相关:pasted:20240913-162117.png|极简活动模型}}

客观框架，主观内容是前面部分提供的一个需求，客观框架意味着版本之间程序开发的工作量最小，主观内容意味着策划可以有发挥版本差异的空间。  

在这套模型下，策划能够发挥的点：

  * **活动设定包装**
  * **活动道具包装**
  * **故事情节**
  * **奖励商店**
  * **任务面板**（通常不改）
  * **氪金礼包**

玩家熟悉度高，但因为每次策划都提供了“新的故事”，新的故事配套“新的角色”或者“新的皮肤”，玩家代入感好，自然的，玩家也就买账。  

如果任务指向的核心玩法有差异，那通常2、3个玩法就可以轮流一整年，达到每个月出一个活动的要求。  

玩家首先通过**绿色的部分**完成一次性击杀，在实际案例中，为了避免玩家的数值差异引发问题，我们将这个一次性击杀的过程统一了数值，也就是说，怪物与参与角色都是被固定好的，因为要售卖皮肤或者英雄，就拿售卖的英雄来参与战斗，同时向玩家展现剧情故事。  

等玩家通关了活动副本，其实大部分玩家就不参与了。**通关的概念**给了这部分玩家满足感，也同时带来了大量的流失。  

<color #ed1c24>剩余的玩家，有肝帝也有氪佬，他们会为了追求更高级的O，去刷秘境，也就是爬塔类似的耐重复玩法，这个过程提供了无上限的内容，让真的想要“玩到海枯石烂”的玩家也能一直玩下去。</color>

当然，为了满足设计目的，还有许多细节要补充，但基本来说，这个模型可以作为较为通用的一种模型，应用于各种游戏，并在上面进行变种，适应各种情况。  

<color #ff7f27>因为实践部分涉及了大量项目信息，读者与我的同步率是很低的，讲多了其实大家都自以为理解了，结果信息差很大，所以也就只能给个极简模型，然后读者自行理会，实在需要参考，就查查作者当下正在负责什么游戏，进入游戏中看看即可。</color>
多杰游戏学

用户工具

站点工具

页面工具
