Program Design of Task System

Task is a common system in program applications. It helps users to assume roles, and also helps R&D, operation and user interaction. Usually, users will be given certain rewards after completing tasks.

1. Basic data structure

The early task systems were designed very simply, most of them were linear structures, and occasionally there were ring tasks. We only need a few data formats to store the current task progress, such as the following:

  public class TaskDate
    {
        public int max;//最大进度
        public int current;//完成进度
    }

Then we need a dictionary to store the task object, which is the following data structure:

  public Dictionary<int, TaskDate> currentTaskDic = new Dictionary<int, TaskDate>();//当前显示任务
    public Dictionary<int, TaskDate> CurrentTaskDic { get => currentTaskDic; }

So far, we have completed the most basic data structures and can handle basic task units. For example: kill 50 designated monsters.

Of course, these are the most basic data structures. For the processing of tasks, we also need to determine the type and structure with planning. In some scenarios, it is also necessary to store completed tasks to determine whether the user has repeatedly received them. We can deal with these tasks later.

2. Basic functions

General task processing is similar to the RBI mechanism. Let's take the task of taking screenshots from "Eternal Tribulation" as an example:

The above tasks can actually be divided into two types: 1. Use XX weapons to cause kills when XX is equipped; 2. Use XX weapons to cause XX points of damage.

For the first type, it is necessary to judge whether the two conditions of "equipping XX" and "using XX weapon" are met when the kill is caused. If so, pass completion information to the manager.

For the second type, it is necessary to judge "whether to use weapon XX" when causing damage, and send information to the manager if it matches.

This paragraph means that we first abstract tasks with the same trigger conditions into a type, and then process tasks of this type uniformly. That is, the data is first abstracted into behavior, and then some algorithm is used to process the behavior.

Therefore, we need a general processing function like this in our TaskProp (task manager), which is responsible for processing various complex task progress and judging the processing structure:

 /// <summary>
    /// 任务类型
    /// </summary>
    enum TaskType
    {
        type2,//2,X1个X2设施达到Y级(其中X2任意X1数量即可满足)
        type3,//3,X建筑下的设施总等级达到Y级
    }

    /// <summary>
    /// 任务进度判断
    /// </summary>
    public void TaskJudgment(int _id,int _num)
    {
        //获取任务类型,通过方法计算
    }

For example, the task with ID 15 is "kill 100 spiders": then we call TaskJudgment(15,1) every time a spider is killed. In the function body class, currentTaskDic[15].current will be found and value-added processing will be performed. When the conditions are met, it is judged that the task is completed.

Finally, we need a judgment to receive upon completion, then we can get rewards for the above tasks:

  /// <summary>
    /// 任务完成回调
    /// </summary>
    public void TaskComplateCallBack()
    { 
        //任务完成之后刷新界面
    }

至此,我们完成了一个任务完整的生命周期,即生成任务=>推进任务=>领取奖励。

3,任务红点等附属结构

当我们完成任务,或者运营推出新任务的时候,通常会使用红点来提醒玩家。虽然现在红点系统已经被滥用到一个有些令人生厌的地步,但某些场合它又是必要的。

红点一般使用树状图结构的数据来处理,即子节点有红点的时候,父节点的红点也会被点亮。

回归到基本的任务单元,我们只要判断是否符合红点条件即可。比如完成某项任务需要领取的时候出现红点,则基本代码如下:

bool _isHint = _taskD.current >= _taskD.max;

然后基于这个判断,我们可以处理UI上相应的红点系统。

4,扩展延伸

以上都是针对最基本的任务单元处理,现在游戏中的任务已经设计的比较复杂,我们需要针对具体的任务结构具体分析。比如环任务、日常任务、周任务、赛季任务、主线任务、支线任务等等,它们有这诸如时间、前置等等限制。

但万变不离其宗,我们只要搞懂基本的数据类型和数据结构,便可以处理这些看似复杂的任务系统。

另外任务系统不单单应用于游戏,硬件单元处理、操作软件这些都包含任务系统的范畴。大到国际运行,小到日常活动,任务系统与我们每个人都息息相关。

5,总结

写任务系统代码的时候,先认真分析任务的结构,然后根据表格抽象出我们需要的数据结构。最后层层处理,以保证系统的正常运行。

Guess you like

Origin blog.csdn.net/Tel17610887670/article/details/128834041