So I am currently making a system with different actors, which some are of quests. I noticed that alot have variables like bhasSpokenToXY or hasCompletedQuest1. Is it recommended to put quest variables in the quest class ? For instance if player enters the area i dont create a boolean in the character class but quest class and true the boolean in the quest class. So begin overlap → instead of true the boolean in the character class i set the quest class boolean to true and dont bother creating a boolean in the character class at all.
The reason I ask this is because I noticed alot of variables stacking on the character class which some are just simple checks etc.
Is this a valid method or should I do that in the game instance? I know the game instance is persistent and retains the values
Separation of concerns, what really needs to know what.
The heath-thingie doesn’t adjust health directly since it would need to know how to adjust the health on everything it might need to, and they might all be different. Rather the player/monster heals (adjusts) it’s health and just reads the ‘how much’ from the health-item.
So, I would say yes, put it in the quest item. At some level, code aside you DO need to know if the quest in particular is complete. If the player tracked this, they’d need to have a list of all the possible quests in an array/list, etc.
I would make quest-template that has isComplete as a bool, among others.
More generally, I made an ‘item’ that can go into the backpack (or attach to any other critter) of the character that has a ref to quest-stats, weapon-stats, armor-stats, etc, otherwise all the shared-aspects of any item. Ref’s start empty and I can just attach the sub-stats as I require per item-type, or mix/match.
The sub-stats are themselves structs which in the case of a quest, can have the bools, text-description, ref to another quest-leg, etc. When you want to display all this, you can just iterate through ‘items’ and the quest-screen becomes another backpack screen, same logic, diff item.