The intention is to allow an NPC to offer a series of quests, each of which is only offered to the player once they've completed a previous one. This is done in a generic way which should be able to avoid (or at least minimise) the need for custom scripts for most standard quests. It also aims to handle complicated cases where parties contain some players who've completed previous quests for the NPC and some players who haven't.
To implement a quest with this system you need to do three thing:
When reading the information below you'll notice that all the script and variable names have a digit after them - this corresponds to the number of the quest of that NPC. So, all variables and scripts which refer to the first quest should end in the number 1. All variables and scripts for the second quest end in the number 2, and so on. This is how different quests are kept completely separate from each other.
In the examples below, it's assumed you're dealing with the first quest - if you're dealing with another, just replace the digit 1 with whatever quest you like.
Let's take these steps one at a time below.
This should be set up as normal. The category must have at least two entries - one where the quest is described, and one which should be shown after the quest is completed. This will be sufficient for a simple “retrieve the item” quest. More complex quests will probably require more than two entries.
The journal category should be given a unique tag name and assigned the XP you want to reward for completing the quest.
You can place as many entries as you like, but if you're not doing an “item quest” then you should ensure the entry just before the final one indicates that the player shave completed all the steps that are required for a quest except actually going and telling the quest-giving NPC about it.
If this sounds completed there's an example of a more complex quest later!
There are two things you can require players to have done to indicate they've completed a quest:
The first case is fairly obvious. The second case is designed so that you can set up versatile multistage quests. For example, if you require the players to choose a particular conversation option with another NPC to complete the quest, you'd set that option to advance the journal one place. There's an example of how to do this later.
Note that you can advance the journal in any script, so treading on a trigger, or talking to an NPC, or any other event can be used to do this. You may need to write custom scripts for more complicated events (but these are likely to be the exception and not the rule).
Note that the two options (requiring an item, requiring a journal entry) can be combined - in this case the quest is not considered complete until both are true.
To require the players have a particular item you set the variable QuestItemTag1 to be a string which holds the tag of the item you require the players to hold.
To require a particular journal entry, you set the variable QuestJournalComplete1 to be the number of the entry which means the players have completed the quest (aside from the final stage of telling the quest giver). So, a simple quest might have three entries:
In that case, QuestJournalComplete would be set to “2”, because that's the stage the journal should be at to indicate that the players are ready to tell Alustriel they've done what she asked.
This is perhaps the hardest step, but it's still not too hard - in the vast majority of cases you shouldn't need to edit any scripts at all.
The most important thing to note is do not, repeat do not, set up any journal stuff in the “Other Actions” tab. Leave the “Other Actions” tag well alone. We do not do use it for journals in any way at all, no matter what journal tutorials on the web might say :)
There are four main scripts which should be used in quest-giver conversations:
sc_quest_need1 - This is used as the “Appears When” script for the conversation branch which offers the quest to the player. This ensures the quest is not offered until they've completed the previous quest and also make sure it's not offered if they've already accepted it.sc_quest_got1 - This is used as the “Appears When” script for the conversation branch where the PC claims they've completed the quest. Note that this does _not_ check whether the players have finished the quest! It only checks whether the players have accepted the quest. See example conversation below for its use.sc_quest_done1 - This is used as the “Appears When” script for the conversation branch where the NPC accepts that the player has actually performed the task and gives them their reward.sq_reward1 - This is used as the “Actions Taken” script for the conversation branch where the NPC accepts that the player has actually performed the task and gives them their reward - it actually does the business of handing out XP, gold and items.Take the example of an NPC that offers two quests:
First we set up our journal entries - obviously the XP values and tags are just examples:
j_fetch_sword, 200XP)j_tell_time, 300XP)That was easy. We mark the final entry in each category as “Finalises category”.
Now we go to the next step, setting variables. First we set the variables for quest number 1 - this is easy:
JournalTag1 = “j_fetch_sword” (string)QuestItemTag1 = “w_ba_wallys_sword” (string)QuestGP1 = 200 (int)Now we set the variables for quest number 2 - we need to remember that the journal ID 3 is the one where we've completed the quest and are ready to speak to Wally again:
JournalTag2 = “j_tell_time” (string)QuestJournalComplete2 = 3 (int)QuestRewardTag2 = “m_sc_fireball” (string)How easy is that? Now finally, we have to set up Wally's conversation. Below the comments in italics indicate which scripts, if any, go in the “Appears When” and “Actions Taken” tabs. Remember that conversation options are checked in order until one which should appear is found.
NPC comments are in bold.
sc_quest_need1)sc_quest_need2)sc_quest_got1)sc_quest_done1, Actions taken: sq_reward1)sc_quest_got2)sc_quest_done2, Actions taken: sq_reward2)The very last stage is to set up a script on the broken sundial to cause the old man to tell the player where the other one is, and a script on the working sundial which advances the journal one place. These are left as an exercise to the reader… (You could implement both cases by adding a conversation to the sundial placable - conversations are a very versatile way of doing these sorts of interactions).