To be released or..?
Either way best of luck with it.
|
So i've been thinking about creating a system design that supports ease of creating new quests. I was thinking of something a long the lines:
I also found out that this design is used in many RPG games. If any of you could throw out some ideas about a better design or about this one I would appreciate it.Code:@Override public void handleQuestStages(Player player) { String dragonSlayer = player.getQuest("Dragon Slayer"); switch (dragonSlayer) { case null: player.getEncoder().sendMessage("Go, slay the dragon and I will reward you."); player.setQuestAction("Dragon Slayer", "kill"); break; case "kill": player.getEncoder().sendMessage("What are you doing here? You must slay the dragon!"); break; ............... } }
To be released or..?
Either way best of luck with it.
please don't release stuff like this. this isn't good design at all. i think you should rethink your current design and see how you can improve it. for improved modularity why don't you consider some sort of quest manager class (one player = one quest manager) that manages all of the quests. you should also have some sort of base quest class in which all of your quests will subclass.
I think you misunderstood the main post. That's just an example of how the quest stages will be executed.
There will be an abstract class holding all the functionality needed to check requirements etc. Also I was thinking of implementing Listeners for Object & Npc interactions.
i understood what you are trying to say and it's not really an ideal quest system, especially with all of these string literals; it's prone to error. you could clearly introduce a stage system in your quest system which will outline clear goals. ex: each quest will have a collection of stages. it will also hold the current stage that the user is on. a stage will hold the requirements in order for it to be completed (in which it would go to the next stage if there is one). a quest would be completed when all stages are complete. i think you should scrap this and just write the code how you would want to access it, then you could fill in the functionality.
err.. i wouldn't recommend a singleton approach to quests. remember, each player will likely be at diff points in the quest. ditch the Quests enum and turn the Quest interface into an abstract class, as you can provide a lot of helper methods. not sure how i feel about your QuestActions enum, i probably wouldn't recommend it. if you insist of keeping it, create a Requirement interface and create a class for each type of requirement (action).
Well, i think best way to go for quests are a step of nodes eg:
quest.add(new ObjectClickNode(treeId).istantlyAdvance().setNext( new NpcClick(1).addListener(ATTACK_LISTENER).waitForTr igger())
Edit: this was written pseudo in notepad
« Previous Thread | Next Thread » |
Thread Information |
Users Browsing this ThreadThere are currently 1 users browsing this thread. (0 members and 1 guests) |