Building a Quest System

[Ali_RS]

Hi

I started to design a Quest System for my rpg and after a thorough search the web for good tutorials and examples I fond these resources to be really good.
Thought to share them here for any body who is/will work(ing) on a RPG game.

Building a Quest System | Hacker Noon [This one is really good ]

BetonQuest/BetonQuest

Parts 23-29

I am going to use this thread for my future discussion on Quest System + ES

[mitm]

Thanks.

[Ali_RS]

Now that we are talking about Quest specific stuff I have moved to this thread.

Feature Request for SiO2 EventBus : Support for filtered listeners

Yes, sorry I did not provide it in the first place. It was a bit hard to explain The case is, in a multiplayer game which you have multiple parties where each Party(Team) has it’s own separate Scene (World). A Party is a group of players who created a team and are playing the game in a Scene (World) that belongs to them. Scene (World) is an entity with a Scene component and any object belongs to that scene is going buff to that Scene. Each Scene has it’s own PhysicsSpace, NavSpac…

[Ali_RS]

Feature Request for SiO2 EventBus : Support for filtered listeners

Design question: what was the thinking behind the choice that the quest state is not a component in the ES? It seems like this would be a persistent part of the world state to me.

[Ali_RS]

My current approach is :
(I have not implemented it yet, I am just prototyping them on the board. @pspeed please comment if you feel the approach is taken wrongly and I need to change it)

Reading my Scenario prefab (blueprint) and it’s containing Quests from a JSON string persisted in a JsonString component and parse it with Gson. So I do not represent a Quest itself with an entity.

When a quest unlocked I assign a QuestGiver component to the NPC entity who is going to give this Quest to the players Party.

QuestGiver component has name of the Quest it’s going to give.

Now based on what you said, I think If I add also the current state of the quest into QuestGiver component then I do not need EventBus stuff at least for this case

[Ali_RS]

In case, I am following approach described by Maxim Zaks in my first link

How do I implement a quest system with ECS

In my article Games Data and Entitas I argue that data can be divided into three categories:

Configuration
Game State
Runtime Data

In case of quests, we need to use all three of those categories. The definition of the quest is stored as a configuration. In progress, Done and canceled quests are stored as game state.

At game initialisation, we would go through the configuration and create a set of “pending” and “in progress” quests, according to quests already persisted in the game state. We also check if we can store new quests as canceled.

At runtime we need a set of reactive systems, which will monitor the relevant parts of the game state and transform pending quests to unlocked and if possible to in progress. Quests based on ad-hoc actions, will have components storing the progress.

We need another set of reactive systems, which monitor the game state and user interactions in order complete a quest, or at least change quest progress in case of ad-hoc actions.

When a quest moves to done, it will be persisted in the game state.

This is basically the magic sauce. The details can become a bit more involved, but in my opinion, ECS is a very quest friendly architecture. Specifically if you are following it strictly and turn every player event to a component.

Note, I am using JSON String for saving configurations (prefabs) with GSON lib.

And @pspeed yes as you said I should save quest state as a component which I was wrongly tried to use events.

Edit:

Note, I am going to use Game state based instead of Ad-hoc actions approach.

Completion Requirements

There are mainly two requirement categories for completion:

Game state based
Ad-hoc actions

For example we are building a farming game and we have a quest based on apples. In Game state based category we define that the quest is completed, when the player have 2000 apples. If apples is a consumable resource the player would have to stop consuming it and keep harvesting apples till s/he has 2000 of it.

In the Ad-hoc actions category, we would define that player should harvest 2000 apples after the task moved to “in progress” state. This way we do not impose any consumption restriction on the player and don’t care about previous achievements. Btw. quests with Game state based completion requirements can be auto-completed. Player might already reached the state needed for completion. However the Ad-hoc actions based, always needs to be worked on.

So I wont need extra components to keep current progress of Quest. I will just use information from player inventory and stats.

[raistm]

Great! I’m currently working on a RPG title as well but I have yet to think about a quest system.