Quest System

Hello everyone !
Following yesterday's Live stream - the 6th episode of the journey - I'm opening this thread to discuss the Quest System.

It's been implemented in the Quest System Branch, following the requirements below.

I'd love to discuss with the community ways to improve this system :)

Here are the diagrams that we used during the live stream
And here's the Quest System card

Quest System
Create a script that tracks progress in the game and in individuals Quests.

Quests are ScriptableObjects that contain a list of sub-units called steps. When all steps in a Quest are completed, the Quest itself is complete.

Quests are linear. It means that only one quest is active at one point in the game. And once it's completed, it starts the following Quest.

This creates a logical connection, but the connection is not explicitly stated in the data (i.e. the ScriptableObjects are not linked to each other).

We don't explicitly visualise Quests in an in-game UI.

Steps are also ScriptableObjects, that describe an atomic interaction like:

  • Giving an item or dish to a character
  • Check if the player has the item requested by a Character
  • Talk to a character
  • Obtain an item

The step ScriptableObject contains the dialogues needed for the step :
-Start Dialogue : A dialogue that will be played before doing an action like "checking for an item", "giving an item", "obtaining an item".
This dialogue will keep replaying, each time the player interacts with a character, until the step is completed.
The same dialogue will be played if the step type is just talking with a character. In that case once the dialogue ends, it ends the step
-Win Dialogue : (the naming will be changed) is a dialogue that will be played when the action is done : "Checking for an item", giving an item", "obtaining an item"
Once this dialogue ends, it completes the step.
-Lose Dialogue: (the naming will be changed) is a dialogue that will be played when the action is not done: "Checking for an item", giving an item", "obtaining an item"

The StepController is present on every NPC that will be involved in a step.
When a step starts, It will raise an event that will inform all the characters about it. Each character will check if it's involved in the task. And will register to the task if it's.

When a step is completed, the character will unregister from it.

1 Like

So if the player wants to free roam/explore, then they can't trigger a new quest if they're currently working on one?

Haven't had a chance to look at the code yet, what are the challenges to making a list of active quests instead of a single one? Could we not just have a concept of Quest ID and have an array/list of active ones? Apologies if this is already documented in the code.

How about CompletionDialogue instead of WinDialogue and IncompleteDialogue instead of LoseDialogue?

1 Like

I agree, it might be valuable to be able to run several quests in parallel.

Actually I am trying to figure out if it would be possible to have a quest where the aim is to complete the quest from another NPC first with only one quest active + some dialogue system.

1. Talk to NPC1: I need a piece of ginger to finish the dish for my son, NPC2 have some spare ones could you ask him to give me 1 piece, please?
2. Talk to NPC2: Sure, but a Slime Critter is blocking the access to my storeroom where I am storing ginger. He is just behind me, could you help me to get rid of him, please?
3. Kill the slime critter (a new step type?)
4. Get Ginger from NPC2
5. Give Ginger to NPC1
6. Get Frying Pan from NPC1! Yeah quest done!

I would argue that the above example is simply one quest with many steps and would certainly be possible.

1 Like

We thought about this at first. Having several active quests meant that the player needed to complete various steps at the same time. And because we didn't want to have the Quests displayed on the UI, we thought it was best to have one required action at a time. So that the player doesnt feel lost.
When discussing this issue with the team, we said that we would test this gameplay first and maybe change it later if it feels too stiff.

I like this renaming

As @danten66 said : We thought that this looks more like it's only one Quest but with different steps.

1 Like

Going for the single active quest system would mean designing a system to prevent additional quests from starting if the Player is already busy with one. Let's say that there are 2 characters giving out quests: A and B.

  • Player gets their quest from A.
  • Quest A activates.
  • Player talks to B before completing A.

What should happen?

What actually happens currently is :
-Quest 1 gets activated.
-Tells A that they have step 1.
-And only when step 1 finishes, do we have a Step 2.
-Step 2 can activate character B .

1 Like

Ah, indeed. Now I understand also treivize's post, thanks. And sorry, I should have read the whole thing more carefully.

Back to the topic, I feel like this might end up being more complex than a multi-quest tracking system because it requires steps to be aware of each-other state.
Perhaps there is a way to keep it simple, I'll give it a thought

1 Like

If they are not connected, how can you tell when you need to start the new quest when talking to NPC B ?

I was thinking that we could add a "Requirement" in the Scriptable Object(SO) definition for the Quest. This requirement would reference another SO with a method returning a bool -> very much like the "ConditionSO" inside the stateMachine system.

That way, we could add a "IsQuestFinished" requirementSO (or ConditionSO) referencing another Quest SO, but we also could easily swap the requirement to something else, like "HasFryingPan".

Or is this too complicated/generic for the current objective ?

Actually here's how it works
-The quest manager has a list of quests.
-Each quest has some steps.
-Each step can be linked to a different Character (Actor)
-Once a step is over, we activate the next step
-Once all steps are over, the quest is considered over.
-Once a quest is over, we activate the next quest.

I think I understand what you're asking.
Currently the "condition" is just checking for an item if it exists in the inventory of the player.
Steps can be either :
-Just dialogue : No condition.
-Checking item : The condition is to have the item in the inventory
-Checking item and giving it up : The condition is to have the item. The item will be removed once the check is done.
-Getting a reward : No condition, the item will be added to the inventory once the dialogue is over.

In the current system these are considered to be conditions, but of course we could propose more !
If you're interested in adding conditions, please do. It can be : fighting 10 critters, going to a place and back ...or anything that you can think about.

Please correct me if It wasn't what you meant :)

That means if Quest A is currently running, then QuestManager will have a currentQuest variable QuestA.

If player talks, interacts or any other way of starting QuestB, it would not start until QuestA has been completed.

This also results in if player wants to do another Quest, he would/will have to finish the current Quest or may have to end current Quest

The player actually doesn't have access to the following quest, nor can they skip or activate a quest by themselves.
The quest manager takes care of that, and it's the quest manager that activates Quest B when quest A is over.

Does this mean it is the same sequence of quests every time? I fear nobody would want to play the game a third time then, if he learned the second time it is all the same...

Also, if the player is currently e.g. down on the beach, how does he know the next quest is e.g. on the mountain path? Do we expect the player walks around all over the map until he finally finds the NPC that has his next quest? If there were 3 potential quests to start, the player would find his next quest easier.

I understand that some quests can only be fulfilled successfully after having obtained necessary recipies, utensils or ingredients in former quests. But if for the next quest e.g. 3 different things are needed, it doesn't matter in which order they were obtained. Also if we want to give the player a hint (like "bard hare has been asking about you""Have you ever been on the mountain? You have a great view from there.") at the end of a quest where his next quest is, it doesn't need to be the same all the time - we could have the hint stored with the next quest.

We could for example have quest groups (containing 1 or more quests, the tutorial and final winning quest could be the only one in their group). The quest groups will be activated strictly in sequence but within the group the quests could be activated either in random order or triggered by the player's behaviour (walking into a trigger?).

1 Like

I thinks quests shouldn't be linear, they should be un-ordered, the player would choose whether he wants to start QuestC or QuestB after QuestA.
But one solution to this would be to make Quests interdependent. This means that QuestB would require an item, and that item is the reward of completing QuestA.

But still there some be a degree of freedom to start QuestE after QuestC (in some cases, where the is no dependency of item between E and C).

But this would require the player knows which reward he will get. If we would make quest groups and put quest B in your example is in a later group than quest A, then it would be taken care of without the player knowing. Nonetheless the player has the freedom to execute the quests in one group in any order he desires.

1 Like

I think, being a vertical slice, we should focus less on side quests. If the system is made right, adding those should be fairly simple. For now, we just have one questline, the main one of course, and it makes sense that when you finish a quest in a questline, you'll immediately receive or get directed towards the next one. That's common in most games.

So based on that and on what @ChemaDmk has said, what she's calling the Quest Manager, I'd rename it to Questline.
-A Questline has a list of quests.
-Each quest has some steps.
-Each step can be linked to a different Character (Actor)

Then we can make a QuestlineManager that can listen to when a questline becomes active, when a quest in that questline is completed or failed, and when the questline is over. Initially, the manager would simply be there to hook up the UI. Then it can be further extended to perform orchestrations; enable and disable quests based on the state of the game, what items the character has, what quests have been completed, etc. But that's probably outside of the scope of the project. But besides that, it's just making the quests and questlines, but the system doesn't really have to care whether there's only one or 5000.

This should really be reconsidered. Perhaps not some UI in the middle of the screen, but at least a Journal you can open up if you feel lost is always necessary.

1 Like

I like your idea, having a group of Quests that can be activated in an unordered manner gives the player a sense of "newness" each time they play the game.
The quests in one group need to be independent, but groups need to be ordered and can be dependent to other groups
That meets the idea proposed by @deivsky (questlines)

The only thing is that we wanted to avoid the UI for quests. Leaving the game to be more of a discovery/adventure, then just quests.
The quests will tell the story of the game, and the player needs to be invested to understand it.
This, of course, needs to be tested before fully dismissing the idea.

I'll try to add the grouping to the quest system and will open a new thread to decide about the quests (story wise)

1 Like

I don't mean some dull quest log that's like,
Bring a spoon to townsfolk A.
Progress: Spoon 0/1
But rather something more like a Journal or a Diary, saying things along the lines of,
Townsfolk A can't stop talking about his collection of spoons.
I don't think that would break immersion, while at the same time it helps players that are feeling lost. Not everyone likes reading dialogs, not everyone plays every day so they might need a reminder of what they were doing, and having to talk to every townsfolk to see which one has a dialog that could be a quest seems to me like a tedious task. Having to remember who needs what and where they are, especially if we are going to allow for multiple questlines running in parallel, is also something not everyone likes or even can easily do.

Edit: This might be a separate discussion though so I'll drop it. It's also a lower priority, once the system and some quests are ready we can test if we need it or not, and if we do then it's just setting up the UI for it ;).

1 Like

Yes, I think it's a fun idea but can also be implemented as an add-on. After all, you only need an additional line in each Quest (or Quest Step) and then send it to this journal once the quest/step is done.

In my recent project I implemented parallel and serial objectives simply using a flat dependency list. It sort of avoids the need for complex nested structures

I also allowed for conditions for whether the objective should be activated (although I guess this could also have been merged in as a “Objective Completed” condition)

To represent the following scenario:

  • A starts and finishes

  • B, C(1&2) and optional D can now begin

  • C2 requires C1 to be finished first

  • B and C must be finished before E can start (D is optional)

  • E must be finished before F can start

This can be represented as a flat list with dependencies as per the sticky note image below

when an objective is completed, you have the other objectives check their dependencies to see if they’ve been satisfied by the completion event

Hope that’s useful anyway