|
|
在网络游戏中做任务已经成为游戏很重要的一个核心功能和玩法，如何做好一个灵活可扩展的任务系统的架构与设计，今天来给大家分享一些我们的设计经验。接下来我把整个的任务系统分成以下6个模块:
对啦！这里有个游戏开发交流小组里面聚集了一帮热爱学习游戏的零基础小白，也有一些正在从事游戏开发的技术大佬，欢迎你来交流学习。
对于单机游戏而言，这6个模块都放在客户端直接处理，对于网路游戏而言，模块1~5实现在服务端，模块6实现在客户端。
任务配置表设计与管理
任务ID：唯一代表该任务类型的ID号;
任务解锁的条件: 解锁该任务的条件(这里有N种完全不同的规则)
任务的文字描述: 描述改任务的内容，主要用于客户端UI界面的显示;
任务完成达成的条件: 完成该任务要达成的条件(这里有N种不同的规则);
任务完成获得的奖励: 完成该任务可获的奖励(这里有N种不同的奖励规则);
任务奖励描述: 完成任务后可获得哪些奖励的文字描述，主要用户客户端UI展示;
解锁方式ID 解锁条件描述, 解锁参数解析模板,如
10000 策划填写ulevel=10, 达到等级10后解锁, type=10000, ulevel=%d
20000 策划填写cards=10, 收集10张卡后解锁, type=20000, ucards = %d
…
在策划的任务配置表里面就可以按照这个规则来填写，程序根据type类型来对应解析规则，解析解锁条件。如下:
任务ID 任务解锁条件 任务文字描述 任务完成条件, 达成奖励
任务完成条件与达成奖励条件也可以按照解锁条件类似的方式来编写和制定规则。所以这里在设计的时候一定要充分的调研任务系统的需求,程序根据type类型来解析规则的参数获得对应的条件规则。
游戏任务的解锁与生成
任务配置表的设计完成后，策划就会给游戏编辑好任务配置表，在游戏运行中要给每个玩家来解锁对应的任务并生成任务，这个时候还需要有一个玩家任务表，这个表描述了所有玩家的所有任务，这个表的设计如下:
ID: 任务的唯一ID号
uid: 这个任务对应的玩家ID号
tid: 标识玩家正在进行的任务，根据tid可在任务配置表里面找到对应的任务和描述;
status: 当前任务的状态:
未解锁【0】
已解锁,待执行【1】
进行中【2】
已结束【3】
奖励未领取【4】
奖励已领取【5】
例如:
ID uid tid status
1 玩家A 10001 1
2 玩家B 10001 1
3 玩家C 20001 2
…
任务进行中与任务完成判定
玩家解锁了任务以后，在任务表里面就有这个玩家所对应的任务记录了,状态也改成了正在进行中，当玩家触发一个游戏事件后抛出一个事件，任务系统监听对任务判定有影响的事件。当有这样的事件抛出后，就去看下是哪个玩家触发的，然后根据任务配置表中任务的完成判断条件规则进行判断，如果条件成立,修改任务的状态。
任务完成后的奖励生成
达到任务的判定条件后, 如果这个任务的类型是有奖励的，这个时候根据任务类型的描述配置表的奖励规则来生成对应的奖励。任务配置表里面有奖励的类型，以及奖励的数据，程序根据奖励规则表中奖励的类型来解析对应的奖励数据生成奖励。如果是直接给奖励，根据任务的奖励内容给玩家的数据加上对应的奖励即可，并通知前端来播放奖励动画。并标记任务已完成。如果奖励需要玩家自己去领取，可以将任务的状态改成”奖励未领取”,这样玩家拉去任务列表的时候，就可以根据这个”奖励未领取”状态来显示还有奖励可以领取,客户端显示领取按钮。
奖励的领取
奖励分为直接奖励与玩家主动领取的奖励，这个根据游戏的需求来就可以了，对于任务系统而言，如果是直接奖励，那么直接给玩家加上对应的数据属性就可以了，比如奖励金币，奖励宝石等，奖励的时候可以通知客户端，这样客户端可以播放一个奖励动画出来让玩家知道自己获得了奖励，如果奖励需要玩家主动领取，当玩家拉取任务列表的时候，可以根据任务的状态”奖励未领取”，把没有领取奖励的任务拉去下来，并展示一个”领取”按钮。当玩家点击领取的时候，服务器根据任务ID来获取任务数据，检查任务的状态是否为”奖励未领取”，如果是，再获取任务的ID号，根据任务的ID号获取具体的奖励数值，给对应的数值加上对应的奖励,并修改任务的状态未奖励已领取，并通知客户端展示动画。
客户端的界面展示
以上就从6个维度详细的描述了一个大型网络游戏的任务系统应该如何设计，关注我可以学习到更多的大型网路游戏的架构与设计相关知识分享。 |
|
发表于 2022-12-21 18:23:10
