游戏任务成就体系

前言

任务和成就在游戏中非常常见,基本上是游戏的必备功能,其功能意义个人认为包含以下几点:

1. 增加用户粘性,让用户有事可做,有目标可做.
2. 增加用户在游戏中的成就感和投入感,降低用户流失.
3. 体贴的游戏商可以根据成就任务活动之间的攀比排名来激发用户的消费欲望

正文

一, 游戏任务成就体系的业务分析及技术架构

1. 任务:

1. 业务形式描述:一定时间内,呈现给用户的行为目标,达成后会有有一定的奖励,而后结束或出发下一个目标.
2. 在时间上的特性:判定和发奖都是即时的.而任务的存在往往是有生命周期的.
3. 展示层面上的分类:可根据不同的任务类型划分为,每日任务,成长任务,新手任务,运营活动等等,(但数据模型是一样的.)
4. 任务组:有一部分任务做完了之后会出发下一个环节(可能也是一个任务)此时,我们可以将这个情况定义为连续任务,多个小任务组成的一个有序整体,我称之为任务组.任务组我设计的任务成就体系中一个核心概念.后续章节会仔细讨论.

2. 排名活动:

1. 业务形式描述:一定时间内,全局用户设定一个共同的行为目标,在时间结束时进行最终的统计和排名,最后根据这个结果对用户进行差异性奖励.
2. 时间上的特性:在排名活动进行时间内,是不进行判定和发奖的,最多只是提供了即时或定时的排名刷新显示.当排名活动结束时,会统计数据并进行结算.(在此之前数据源还在持续更新中也无法做出结算).
3. 展示层面上注意事项:游戏都有活动,但是此处的的排名活动仅指具备”业务形式描述”中指定特性的部分活动,其他很多活动在数据模型中其实是”任务”模型.(To新手:做服务器开发过程中一定要从数据模型角度来分析业务,而不是从策划人员给出名字上来定位).

例:

       1>”元旦活动:1月1日 - 1月3日之间充值前5名的玩家可以活动iPhone7一台”– [这个是排行活动模型]

       2>”端午活动:5月5日 - 5月7日之间充值达到3w元的玩家可以活动iPad5一台”–[这个其实是一个任务模型]

       3>”中秋活动:9月20日 - 9月23日之间充值达到3w元玩家可以活动M6一台,充值额前10%的玩家更可获得火星单人单程飞机票一张” – [描述的是一个活动,但是数据模型上实际上是两个业务,M6的是任务模型,火星的是一个排行活动模型]

3. 成就:

1. 业务形式描述:永久性的,对用户设定一个行为目标,每个目标有阶段性划分并逐步达成,用户达成后会有奖励,多数奖励为可炫耀或无其他来源的奖励(比如一个称号).这样的成就,经常十几个并行平铺,用户所有成就进行的总进度,可以作为用户在游戏中的”资深度”的一个重要体现.
2. 时间上的特性:即时判定即时达成,成就有效期为永久.
3. 展示层面上的分类:展示形式多种,与平时大多数人理解的成就相似,不仔细描述啦.

注:细心人可能发现,从描述的信息来看,成就与任务是相似的,或者说成就是有效时间为无限早至无限晚的特殊任务.其实确实如此,之所以将这部分区分出来的原因是因为在真实的游戏(仅指我所设计的游戏)设计中,两者的使用频率是有巨大差异的,为了提升运行效率和系统稳定,我将逻辑简单并轻易没不会有过多策划空间的成就单独列了出来.其他朋友可以根据自己的实际情况定位自己的设计

一般来讲成就主要为：

1. 完成一系列任务
2. 完成一系列关卡
3. 完成一系列挑战
4. 完成一系列成就
5. 杀死一系列敌人

4. 成就模块设计

成就模块需要: 需要一张成就表

1. 玩家不同等级的领取奖励
2. 通关关卡
3. 新的英雄
4. 玩家登陆
5. boss玩法

等等

　　这些条件达成提示领取，在服务器中使用事件就很好解决了。

　　数据存储分为:两块领取数据和玩家的数据记录

1. 领取数据
2. 模块达成的数据记录(挑战职业玩法次数等等)

二, 活动

游戏中排行榜的活动和运营活动等, 都是一类类型活动规划好游戏的活动非常重要

活动分为：

1. 游戏服务器的全局活动
2. 玩家的活动

所有活动的共同的信息

1. 活动名称：
2. 开始时间和结束时间
3. 活动描述
4. 活动显示的图片
5. game服务器列表
6. 渠道(小米, 华为等等)
7. 领奖保留时间

大致的流程

web到gm到game服务器的处理game

1, gm的工作(运营这一块)

活动是给运营人员增加游戏中玩家的成就感和投入感, 这个会一个web的局面通知gm进程, game服务器后期, 后期玩家越来越多了, 就增加game服务器, 1服务器, 2服务器, 3服务器… , gm进程就是管理活动具体在那个game服务器有这个活动, gm管理活动在那个服务器上有的，和活动什么时候停止, 什么开始这个活动.

一个流程图

gm服务器的活动业务逻辑主要分为两类：

1. 接收web运营人员的活动通知gm增加, 修改或者删除活动操作
2. gm通知game服务器, game服务器请求gm服务器

2, game(word)服务器

word服务器分为

1. 活动的个人数据
2. 全局活动数据(global)

3, 活动可以使用工厂方法模式设计

优点：

1. 实现了对象创建和使用的分离。
2. 不需要记住具体类名，记住参数即可，减少使用者记忆量。
3. 扩展性好

伪代码:

enum ActivityType
{
  EActivity_None = 0,
  EActivity_Shop = 1,
  EActivity_Max  = 2
};


class activity
{
public:
	activity(void);
	virtual ~activity(void);
	
public:
	// 活动开启
	virtual void on_open();
private:
	activity_base m_data;
};

class activity_shop :public activity
{
public:
	 activity_shop();
	virtual  ~activity_shop();
	
private:
	activity_shop  m_data;  // activity_shop{activity_base, shop_data};
};

class activity_mgr
{
public:
	typedef std::map<int32, activity*> activity_map;

public:
	activity_mgr(void);
	~activity_mgr(void);
	
public:
	activity* add_activity(int32 id);
	bool remove_activity(int32 id);
private:
	activity* _create_activity(int32 id, int32 type);
	
private:
	activity_map		m_activitys;
};

三, 完成一系列挑战

1, 竞技场的设置

竞技场的正常情况在取 前5名, 在根据自己的 (竞技场的排名是什么战斗力) 战斗力 等差数列 - 找到自己插入的位置 首先把放到竞技场的排行榜上 上才能战斗

四, 设计任务

当设计任务时有如下几个重点：

1. 任务需要以线的方式组织，一般都是在每个任务配置中指定下一个任务的id，每个任务线的第一个和最后一个比较特殊，第一个任务必须在角色属性满足条件下自动获得，而最后一个任务因为是故事线的结尾所以不能触发下一个任务，需要保持任务已结束的状态，如果故事线增加了后续任务，那么任务可以继续往下顺延。
2. 任务需要满足条件才能接取，所谓的条件一般都是角色属性，比如角色等级。比如等级10级以上的可接取，为了抽象这个需求，任务可接条件设置两个字段角色属性类型和属性值，这个等级的例子就是等级:10。
3. 任务接取后角色在游戏中做相关的操作，如果跟接取的任务相关，那么任务的进度会自动更新，那么二者是组合产生关联的呢？我们使用事件机制，玩家的游戏行为拆分出一系列的事件类型，用三个字段表示，事件类型，事件对象，事件值，比如打怪，事件类型为击杀怪物，事件对象为树妖，事件值为1。对应的任务完成条件也是这三个配置，不过任务配置中的值为目标值，另外有一种特殊情况比较常见就是状态完成条件，比如某任务需要角色达到100级完成，这个时候就用一个特殊的事件类型，属性表示状态类的完成条件，本例中配置就应该为属性:等级:100。
4. 任务完成后需要触发下一个任务，但是如果下一个任务条件不满足，那么也不允许获得该任务，待角色属性成长后满足了条件再自动获得。
5. 任务配置除了支持以上说的参数外，需要流出一些可扩展参数，比如任务奖励，任务绑定的npc，任务接、交过程中的对白、过场动画等。任务系统使用csv做配置，增加配置只需要增加字段就可以了，每个任务有std::map<uint64, std::string>类型的参数字段保留了所有扩展配置。

五， 数据存储

在游戏中有大致有这么几种数据

1. 玩家数据
2. 全局数据(公共数据[排行榜，工会, 全局的活动(gm)，情报数据等等])
3. 玩家消费的日志的数据
4. 玩家买商品的数据

结语

系统中大量使用了事件机制，增加了易用性和可扩展性。角色上线载入数据，使用事件机制，避免了与数据库模块产生耦合，同时也很好的支持了异步和同步模式。

• 上一页
  3,优化程序的性能
• 下一页
  游戏中商店的设计