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:
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.
Note, I am going to use Game state based instead of Ad-hoc actions approach.
There are mainly two requirement categories for completion:
Game state based
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.