Unity任务系统笔记

数据结构设计

任务基类包括的字段：

string 任务内容；

Transform 任务目的地；

MyCharacter 任务开启后要更新对话的NPC；

MyTalkData 任务开启后相关NPC要说的对话数据；

共同方法：开启任务、完成任务。

每类任务有一些特有的字段和方法。

任务的两个关键行为是触发和完成，这两个行为的条件都很多样：对话、战斗、取得物品、到达地点、刺杀等。要触发任务，需要那些可能触发任务的行为能指向任务，这些行为都要加上可能触发的任务字段。触发任务可能是特定行为也可能是一个任务完成。也就是说任务系统不是只加一个系统，还需要对其他系统的行为加回调。

对话完成任务

任务开启后相关NPC需要记录所属的任务，玩家找ta触发对话时完成任务，且把这个任务变量置空，防止再次对话再次完成任务。为此NPC对话脚本要加一个任务变量。

对话触发任务

则需要在对话结束后开启任务，然后NPC不能再触发这段对话，可能是触发任务进行中的对话，或者没有对话。

和上面触发对话完成任务加起来，对话的开始和结束都要加一个UnityEvent。

战斗完成任务

字段：要消灭的敌人列表；

敌人列表的每个敌人也记录自己所属的任务，每个敌人死时，把敌人移出敌人列表，然后判断列表是否为空，若是，则任务完成。

由于任务是依次触发的，一个关卡的任务的数据结构可以是1.链表，每个任务记录自己完成后下一个任务。但是这样一个关卡的任务先后顺序不直观；但是这样支持多任务分支；2.列表，一个中心任务管理器有一个任务列表，这样不支持多任务分支。然而我做了任务列表界面，也就是我一直想做多分支，这就和使用关卡流程任务列表冲突了。现在问题就是，没有一个图形化的表示多分支关卡的工具，用一连多的“链表”做多分支很混乱。所以在有合适工具前，只能先放弃做多分支。

有一个列表记录此关依次要执行的任务对象，关卡流程会清楚很多：

但是多任务分支用列表就不行了。

两种NPC

NPC分为两类：永远只能触发相同对话，对关卡没有推进的npc（简称氛围NPC）；对关卡有推进，不同阶段触发不同对话的npc（简称推进NPC）。

对于推进NPC，在关卡不同阶段有不同对话，在一个任务进行中触发同一个对话（如“拜托你了”），实际上出现了完成任务和进行中的多分支。这么多对话的存储位置有几种方案。

1.用List全部记录在NPC对象上。由任务对象指定完成后NPC该说哪一段对话。这样NPC对象脚本的检查器上会存一大堆对话数据。也难以看出一段对话对应哪个任务，是触发任务的对话还是任务进行中的对话。

2.NPC上只记录一段对话数据，就是当前去找ta会触发的对话。任务对象上记录两段对话，任务触发、进行中要说的对话。当关卡进度管理器显示该触发一个任务时，任务对象把触发任务对话写入npc脚本的对话变量，任务触发后把任务进行中对话写入npc对话变量。

这样氛围npc因为没有任务系统修改ta们的对话数据，自然就一直触发同一段对话，不用修改。

3.对话数据记录在任务对象上，npc只记录关联的任务对象。这样不推进进度的npc没有关联的任务，ta们的对话就要另外处理了。

很明显2是最优方案，既防止推进进度的npc的脚本里的对话数据过多，又兼容两种npc，而且不推进进度的npc只有一段对话，给ta们声明一个一段对话的List完全是浪费。总之对于氛围NPC，只有一个一段对话变量，对于推进NPC，不同任务阶段对话不同，对话应该记录在任务对象。

问题：回复时开启任务 ，直接把下一个任务NPC要说的话写入了NPC的对话数据，导致当前对话变成下一个任务阶段的。需要在回复时记下要触发任务，这段对话结束后再开启任务。所以在一段对话数据结构里放一个List<UnityEvent>，回复的结构体里有一个UnityEvent用于在检查器配置回调函数，选择该回复时把这个UnityEvent加入列表，对话结束后执行。

数据结构定义

一个任务对象应有的字段有：

1.任务内容文本（可能分成任务标题和任务描述）；

2.任务目的地位置；

如果想直观地标记任务目的地位置，应该用一个场景内游戏对象，那么任务类就不能继承ScriptableObject做成Asset，而应该继承Monobehavior做成Component。

一个任务对象应有的方法有：

1.开启任务（可能包括NPC、敌人、物品的生成和摆放、设置NPC可触发的对话，总之几种脚本里不确定，需要在场景里确定的函数）；

2.完成任务（也可能有上述函数）；

坑

协程冲突

在修改NPC位置等突变操作时我写了一个画面渐变为黑色，执行操作，再变透明的函数：

public UnityAction blackoutCallback;
[ContextMenu("画面变黑")]
    public void Blackout(){
        StartCoroutine(BlackoutCoroutine(blackoutCallback));
    }
    float fadeSpeed=.04f;

IEnumerator BlackoutCoroutine(UnityAction callback=null){
        while(blackBack.color.a<1){
            blackBack.color+=new Color(0,0,0,fadeSpeed);
            yield return 0;
        }
        if(callback!=null){
            callback.Invoke();
        }
        while(blackBack.color.a>0){
            blackBack.color-=new Color(0,0,0,fadeSpeed);
            yield return 0;
        }
    }

然后这个函数在ContextMenu调用时正常，但是完成任务调用时画面就不变透明了。NPC被正确移动了。然后在第二个while循环里加了个Debug.Log()，发现第二个while循环一直在执行，但是alpha值没有变。

 然后又在第一个while循环加了个打印，发现两个while循环都在一直执行。

在协程开头加打印，发现协程被执行了两次。因为一个很笨的错误。

 这说明写淡入淡出时如果以imag.color.a作为循环条件，如果在一个淡入淡出完成前开始另一个，两个协程就会打架，淡入淡出永远完不成。实际开发中如果无法避免一个淡入淡出进行中开始另一个，就根据计算好的循环次数，或者直接规定循环次数，并且循环结束后直接把alpha值写成目标值，因为如果不这么做就算循环能结束，最终的alpha会是一个半透明值。

改进后的淡入淡出：

int fadeStep=10;
    IEnumerator BlackoutCoroutine(UnityAction callback=null){
        for(int i=0;i<fadeStep;i++){
            blackBack.color+=new Color(0,0,0,1/(float)fadeStep);
            yield return 0;
        }
        blackBack.color=Color.black;
        if(callback!=null){
            callback.Invoke();
        }
         for(int i=0;i<fadeStep;i++){
            blackBack.color-=new Color(0,0,0,1/(float)fadeStep);
            yield return 0;
        }
        blackBack.color=new Color(0,0,0,0);
    }