How it works: the quest system, part 2

Part 1 

Part III, Quest manager

The functions of this component can be divided into the following groups:

1. API for other game.  Start\Finish quest, GetTaskStatus etc.
2. API for quest node objects. GetActorsOfClass, GetGameMode etc.
3. Quest construction, saving and loading.
4. Debug.

I will describe all the basic functions. Additional, like the formatting of the text of tasks, we leave for later as less important. The debug function is not complicated and is a very many “print strings”.

First, some external functions. You need a function library:

Very simple function; they return class of the quest by name.

Easy too. They return the BP_MyQuestManger; as I said in my case it’s been attached to the game mode.

OK, now API for the quest nodes. Why it’s need? Because in UE4 objects can’t call the world functions like a GetPlayerPawn or GetPlayerController. It's easy to get around with C ++, but as I said I use blueprint only. Therefore, the simplest thing you can do is duplicate these functions in the Quest manager, and then call them in the nodes referring to it. 

It looks like this:

Proxy function for the GetAllActorsOfClass

Proxy for the GetGameMode

Amazing. A small digression: sorry for the quality of many of the following screenshots. And yet: variables with the prefix "L" are local.

OK, let’s go. 

They construct the quest object from class, and, if it is not contains in the list, add it.

From the name of the function, everything is clear.

Move quest from the ActiveQuest map to FinishedQuest map and clear all of it’s nodes.

Update the task status. This function is used both as an API, and in the construction of quests.

When quest node are started or finished they call this function

Saves current condition to the dump.

Clears everything. Used before loading the dump.

We can load the quest’s condition at the any moment!

And

Is API.

OK, its all for this moment. Next time I will describe the quest; this is probably the most interesting part.