[Disc] Quest/Mission Management

[pradvan]

I've been trying to figure out a way to implement a quest/mission manager in to my RPG, but can't quite figure everything out (or at least the best way to do things).

Data Storage
I'm thinking of holding quest data in XML like so:

<Holder>
<QuestChain>
<quest name="End of the World" id="q1001">The end of the world is here. You're screwed.</quest>
<quest></quest>
<quest></quest>
</QuestChain>
<QuestChain>
<quest></quest>
<quest></quest>
<quest></quest>
<quest></quest>
<quest></quest>
</QuestChain>
<QuestChain>
<quest></quest>
<quest></quest>
<quest></quest>
</QuestChain>
<QuestChain>
<quest></quest>
</QuestChain>
</Holder>

This would easily allow me to give the player quests based on what's next in the quest line.

Saving/Loading quest data
How do you save which quests where completed? Data will sit in a database, so keeping the parameters to a minimum is a must.
Potentially, you could have hundreds of quests. How do you manage all that data?

The only/best way I can think of, is to give each quest a unique id, then if quest if finished, add that id to a string:
finishedQuests += "uniqueId123";

When all is said and done, the end string is going to be a long series of ids. On load i could parse that string and see what quests are done/not done.

Is there a better way to do this? Any potential problems with this method?

Quest Types
1. Kill X amount of Z
2. Kill Z, bring X amount of items from Z

Going to keep quest types simple for now, because of next part;

Quest Objectives
How do you set and track quest objectives?
Need to track location of quest (map id, x, y, enemy type)
How many enemies were killed/objects collected.
Need to save this data as well. How do I do THAT?

These are just the things off the top of my head. Any feedback/suggestions welcome.

[rrh]

So you won't have any branching chains or multiple dependencies?

If you don't have branching, you can just give an id to each chain, plus a number for each, indicating how far that chain is complete. And you'll only need to store the completion of the current quest within each chain.

[pradvan]

So you won't have any branching chains or multiple dependencies?

If you don't have branching, you can just give an id to each chain, plus a number for each, indicating how far that chain is complete. And you'll only need to store the completion of the current quest within each chain.

Ah yes! This is what I want. Critical thinking!

I have thought about needing dependencies, but haven't thought about implementation at all. I guess each chain (not quest, but the whole chain to make it a little simpler), can hold a required chain id, and if that required chain is finished, allow user to take new chain.

You do make a good point about only needing to store the chain id and furthest completed quest.

P.S. what do you mean by branching? Isn't dependency the same thing? For example, in order to enable quest 20001 you need to finish quest 10001. So as soon as you finish 10001, it branches off to 20001, etc. Or are you talking about something else?

[rrh]

By branching I mean if you finish quest 10001, that enables two quests: 10002 and 20001.

By multiple dependency, I mean you would need to finish both quest 30001 and 40001 before it enables 50001.

[pradvan]

By branching I mean if you finish quest 10001, that enables two quests: 10002 and 20001.

By multiple dependency, I mean you would need to finish both quest 30001 and 40001 before it enables 50001.

I guess in my scenario its the same thing. When you finish a quest, it doesn't unlock anything, it just says quest10001 finished.

When parsing the quest tree to determine which quests are available, if quest50001 requires quest10001 and quest10001 is finished, allow quest50001.

[rrh]

Describing it one way or the other is just semantics.

But if it's necessary to describe it this way to make myself clear:
By branching, I mean both 2 and 3 require that you complete 1.
By multiple dependency, I mean 5 requires that you complete both 3 and 4.

Or are the chains completely linear, that 5 requires 4, and 4 requires 3, 3 requires 2 and 2 requires 1.

[pradvan]

Describing it one way or the other is just semantics.

But if it's necessary to describe it this way to make myself clear:
By branching, I mean both 2 and 3 require that you complete 1.
By multiple dependency, I mean 5 requires that you complete both 3 and 4.

Or are the chains completely linear, that 5 requires 4, and 4 requires 3, 3 requires 2 and 2 requires 1.

Gotcha. I wasn't sure if there was another meaning/method/theory.

I guess I want both, branching and multiple dependencies. Looks like both will be possible with a simple required quests value for each quest.

P.S. quest chain will NOT be linear.

P.P.S. an interesting discussion on the subject over at FK:
http://board.flashkit.com/board/showthread.php?p=4182532

[pradvan]

I think I'm going to go for mission objective classes. Something like this;

Mission objective classes: Kill, Collect, Rescue, GoTo, TalkTo

//Kill(map id, enemy id, amount
killMission = new Kill("map33", "enemy111", 10)
//Collect(map id, enemy id, item id, amount
collectMission = new Collect("map33", "enemy111", "item2020", 10);


Quest Data will be saved in XML

<questChain>
<quest type="kill" map="map33" enemy="enemy111" amount="10" />
<quest type"collect" map="map33" enemy="enemy111" item="item2020" amount="10" />
</questChain>
<questChain>
<quest type="kill" map="map33" enemy="enemy111" amount="10" />
<quest type="kill" map="map33" enemy="enemy111" amount="10" />
<quest type"collect" map="map33" enemy="enemy111" item="item2020" amount="10" />
</questChain>


Save/Load quest progress
Active quest log with 10-20 max quest slots. Will save all data as a string:

//this one saves 3 quests and their progress
//final version will have shorter parameter names

var questData:String = "questId=q0001,status=1,kills=10,itemId=i2020, amount=6|questId=q0002,status=1,kills=10,itemId=i2 020, amount=6|questId=q0003,status=1,kills=10,itemId=i2 020, amount=6|"



Linear quest lines will require a way to track completed quests. I'm planning on doing that by adding a complete quest's id to a completedQuest string. Then when parsing the quest xml, quests can be available/not available based on what's completed.

var completedQuests:String = "q0001,q0002,q0003";

I opted to go with quest id's in the completedQuests string because the quest status will already by tracked by the quest log. This way is also more stable/easier than relying on character position in a string to track the status.

[rrh]

Are the individual chains still linear? With my experience with such games, they advance linearly more often than they branch.

Here's an idea of how to handle dependencies:

<questChain id="chain1">
<quest type="kill" map="map33" enemy="enemy111" amount="10" />
<quest type="kill" map="map33" enemy="enemy111" amount="10" />
<quest type="collect" map="map33" enemy="enemy111" item="item2020" amount="10" />
</questChain>
<questChain id="chain2">
<dependency id="chain1" value="2" />
<quest type="kill" map="map33" enemy="enemy111" amount="10" />
<quest type="collect" map="map33" enemy="enemy111" item="item2020" amount="10" />
</questChain>

So within the chains, they would be linear. You would start each chain at position 1, so for chain1, your first quest is the kill quest. For chain2, your first quest is a special kind or quest, it's a dependency quest. This will be invisible to the player, but the dependency quest is considered "complete" if you have completed the first two quests from chain1.

This would be pretty flexible, you could put "dependency" quests at the start or in the middle of a chain. You could put two in a row. You just need to make the game treat them as invisible to the player.

[pradvan]

The more I think about this, the more I want to go with random quests... this is a lot of work :(

[pradvan]

This would be pretty flexible, you could put "dependency" quests at the start or in the middle of a chain. You could put two in a row. You just need to make the game treat them as invisible to the player.

I like this idea a lot. Good call.