Best Approach to design the architecture of Items or Quests Types

Updated on August 22, 2019 in [A] Unity Scripting
Share on Facebook0Tweet about this on TwitterShare on Google+0Share on Reddit0
8 on August 21, 2019

Hello, 

i am currently working on a quest system for my game. and i want to make Quest Types Like Gather items type , Kill monsters Type , Go talk to someone mission etc. so my appraoch was like this :

a Class of Quests 

public class Quest
{
 public int ID;
 public string Title;
 public string Description;
 public string CongratulationText;
 public string Summary;
 public Status Status;
 public Goal Goal;
 public Reward Rewards;
 public int QuestGiverNPCID;
public Quest(int iD, string title, string description, string congratulationText, string summary, Status status, Goal goal, Reward rewards)
 {
 this.ID = iD;
 this.Title = title;
 this.Description = description;
 this.CongratulationText = congratulationText;
 this.Summary = summary;
 this.Status = status;
 this.Goal = goal;
 this.Rewards = rewards;
 }
 public Quest()
 {
 this.ID = -1;
 }
}

and the Goal class is : 

public class Goal 
{
 public GoalType type;
 public Gather gather;
 public Kill kill;
 public GoTo goTo;
public Goal(GoalType type, int ID, int AmountRequired)
 {
 this.type = type;
 if (type == QuestEnums.GoalType.Gather)
 {
 gather.itemId = ID;
 gather.AmountRequired = AmountRequired;
 gather.CurrentAmount = 0;
 kill.EnemyID = -1;
 }
 else if (type == QuestEnums.GoalType.Kill)
 {
 kill.EnemyID = ID;
 kill.AmountRequired = AmountRequired;
 kill.CurrentAmount = 0;
 gather.itemId = -1;
 }
 }
 public Goal(GoalType type, int ID)
 {
 if (type == QuestEnums.GoalType.GoTo)
 {
 goTo.NpcGiverID = ID;
 }
 else
 {
 throw new ArgumentException("Wrong type. or number of params does not match the required amount");
 }
 }
}
public struct Kill
{
 public int EnemyID;
 public int AmountRequired;
 public int CurrentAmount;
}
public struct Gather
{
 public int itemId;
 public int AmountRequired;
 public int CurrentAmount;
}
public struct GoTo
{
 public int NpcGiverID;
}

The Goal class defines what kind of quests its going to be . for example it s a gather mission : i cant construct a new goal with type gather , item that is going to be picked and required amount. so this approach works. but i m not satisfied and im not convinced that this is a good approach it feels noobish and hacked not a solid design. so if it s possible to hear some good approaches and technics to achieve Goal quests :c and thank you for your time

  • Liked by
Reply
0 on August 22, 2019

If this is for Unity, then I would recommend making them ScriptableObjects instead of just classes, that way you you easily make them in the editor.

Either way, you may want to check out this video here in rearguards to your “quest type”. Instead of making the quest/ goal type an enum, you make more quest classes that inherit from the base quest type class, and having some kind of “QuestHandler”… handle the quests..

This would make it easier to make more quest types in the future, without needing to edit your existing code. You just make a new class, and let the handler handle it.

  • Liked by
Reply
Cancel
6 on August 22, 2019

Hi mouledoux, thansk for the idea. it seems to be a better approach but i have some questions regarding inheritance. If i make a base class Quest (does it have to be abstract ?) then i make 3 other classes that inherit from Quest class like GatherQuest , killQuest , GoTalkToQuest and to regroup all the quests in a list can i use the List<Quests> to regroup GatherQuests, killQuest and GoTalkToQuest ?. and then if i have a function AddQuest that takes Quest as a param can i pass every type of quest and still access its specifique fields (for exemple gather has item ID to pick and gotalk to quest has a npc id to talk to)? and thanks for your time i m really grateful for the effort you are making 🙂 

Wise
on August 22, 2019

Base quest doesn’t have to be abstract per se, but it should at least be generic enough that you could use it in place of any of the inherited classes, and still get almost the same result.

You would have a List of ‘Quest’ or whatever the base class is called, and if you were to pull from that list, you would need to use reflection to get exactly what type it is, and what special information that quest type has.

on August 22, 2019

ok i got it. it doesn’t have to be abstract but what do you mean by “at least generic ” ? 

because i though about leaving quest class as it is and make a killGoal , gatherGoal and gotalkToGaol that all inherit from a QuestGoal class which is gonna be empty because i have nothing to add to it ? does that mean it s not generic ? 

Wise
on August 22, 2019

Kind the opposite of that, you want like 80% of the code to all be in the base class, and all of your sub classes are just gonna slightly expand on it is their different ways. But in the end, all of them are still 80% the same thing.

on August 22, 2019

okay i got it. so I think i have to rebuild the quest class to implement this technique :c . i just want to know something out of curiosity why most of the code would be best in the base class and slight expand in sub classes. 

is it a preference or it just goes against the idea of inheritance? 

So mouledoux, i really admire what you are doing this helped me alot. and  thank you profoundly 🙂

Wise
on August 22, 2019

It’s because that’s what SOLID programming is.

The L in S.O.L.I.D. to be exact.

L stands for Liskov substitution principle, wiki link if your interested, but basically what it means, is that you should be able to do inheritance both ways… kinda. You should be able to use any inherited class as a substitute for the base class.

 

One way I heard it that helps me remember is: “If it walks like a duck, and sounds like a duck, but needs batteries, it’s not a duck”

In this example, a toy duck may inherit from a base duck class, but if the toy duck needs ‘batteries’ or any other kind of variable/ resource to be a duck, then it can’t replace the base class that does’t have those variables. So it’s not SOLID code.

on August 22, 2019

Got it. 😀 i didnt know about S.O.L.I.D design That s very intresting. okay everything is clear now. ty

Show more replies
  • Liked by
Reply
Cancel