When determining the challenge portion of an ACR quest, the thing to keep foremost in one's mind is how you're going to advance the state of the quest. This page assumes that you've already set up a quest Hook that initializes the quest. The challenge portion of a quest is also the easiest to combine or repeat-- by simply adding more states that the quest must pass through before it's considered completed.
Conversation Challenges
When writing a challenge that operates through a conversation, we will again be creating a conversation tree-- we'll need a conversation option somewhere for the player to bring up the quest they're on, and some responses to indicate what the player needs to do next.
Like with the hook, we'll need to have a conditional statement to check if the conversation option should exist, but this time it will go on the player's broaching of the topic ("Hello! I have gotten going" in the example above). Just as before, click on the node, then the condition. Again, you'll want to use acr_quest_progress, and the same sQuest, but this time we don't want nState to be 0 (because 0 means that the quest isn't started) -- now we want it to be 1. That tells us that the character is on the quest-- moreover, it tells us that the player is on this step of the quest.
Once that is done, we move on to the NPC's response (in this case, "So I see! You should go back to...") -- we want to update the quest state so that we know the PC has spoken to the target of the quest, so we'll be on the actions tab. But because we're not starting a quest this time, we'll be using acr_quest_update. In this case, we're just advancing the quest-- so we want the same sQuest we've been using, but we want to set nState to a whole new number: in this case, 2. bAllPartyMembers is, as always, the question of whether or not doing this should advance the quest for everyone.
Now, we accomplish a few things when we do this.
1. Remember the quest giver? He wants nState to be 0 to give the quest, so he won't restart the quest, or offer to, when the player goes back.
2. Remember the conditional we set up on this conversation? It wants nState to be 1, so we can't repeat this step of the quest.
3. nState being 2 is a unique number, so we can use it to configure our turnin later.
After you've done that, open the journal and add an entry to this quest's category, number it 2, and give it a description that explains what they would believe they need to do next.
So with that done, it's time to test. Start up a server and try it out. Make sure that you don't get quest conversation points when you don't have the quest, but that you do if you've taken the quest and can't repeat the step.
Of course, this doesn't sound very challenging-- the first thing to point out is that this person probably isn't going to be standing next to the quest giver; he might be far away, hard to find, in a dangerous locale, or all three. But if that's not enough, we can also set up another level of difficulty here. First, we'll need to expand our conversation tree to allow us to have other checks happening-- and maybe let the character pick how they solve whatever problem it is.
In this example, moving nState 1 to 2 requires some avenue to convince the quest giver that progress is acceptable. We'll leave the scripts on "Hello! I have gotten going" from the previous example, so that we know that we're only dealing with people who are on the quest, and then we need to concern ourselves with the skill checks. So, let's take the first option-- a Perform (Dance) check. We leave the player option there without any scripts. Anyone can try to dance. You only need training to be good at it.
So we have two NPC responses to the attempted dance, the same way that we did when we were asking the hook NPC for work. On the first response ("All right, you win" in the example), we're going to set our skill check:
We're using acr_cs_skcheck, which will roll nSkill against nDC. nSkill is a constant, and simply needs to be looked up, while nDC is the minimum roll that 1d20 + skill modifier must be to pass the check.
Once this is done, we can place the action on the player response ("Yay" in the example above) that we had on the simpler quest setup, to set nState to 2.
Now we're stuck with the question of what to do if the check fails. It's very easy for a player to just mash buttons through conversations until they pass a skill check, so it's usually wise to provide some sort of failure state in these sorts of quests. Add an action to the player's response to the failure conversation ("You suck!") that sets nState to something else-- it can be any number, as long as it's unique-- and write a journal entry that describes the failure (and, if you like, you can provide some challenge-type interaction that looks for the quest's failure state and resets it-- such as bringing this NPC flowers and an apology; such would follow the same pattern as here).
Now, the other three checks would follow very similar patterns-- but let's have a look at that second one. Tumble requires training. Most characters would know that they can't impress anyone with tumble. Of course, the players probably know that too, but if we're nice builders, we'll just never show non-tumbling characters the option to tumble their way to victory. It's a little mean, after all; they're promised to fail if they try.
So what we'll do is put a conditional on the tumble option-- just like before, but we'll be using gc_skill_rank as our conditional. Now, the prefix ("gc_") tells you that this script is only meant for Obsidian resources, so we wouldn't be able to use this on Perform(Dance) like we did with the acr script, abut it's perfectly functional for checking if a player has ranks in tumble. So, we'll pick the script and refresh, as before, but because this is an Obsidian script, we're going to want to read the comment lines on the script (that is the green text that appears in the box when you have the row highlighted). It tells us that:
int nSkill = skill int to check
int nRank = minimum rank to return TRUE
But notice that right below that, it tells us what integers refer to which skills for this script. So tumble is 26 here, even though tumble's constant is 21. Quirks like this are why it's important to read those comment lines on any new script-- most people who write them are trying to help you by writing them.
So we'll set nSkill to 26, and nRank to 1. This way, the tumble check will never be an option for a character who can't tumble.
There are a number of scripts that you can use in this way, and the comment lines will generally tell you how (and the names will give you hints). You can click the down arrow beside the entry field for a script to pull up a searchable list-- for conditional scripts, scripts starting with "acr_cs_" and "gc_" are valid for use. The acr_cs_ scripts are those that ALFA has assembled for itself, and are usually the best place to look for anything that is specific to us (such as checking a player's progress on a quest), while the gc_ scripts cover a number of universal concepts that wouldn't need any special handling (such as gc_is_female, which is exactly what it sounds like)
Trigger Challenges
Perhaps this quest isn't meant to be completed through a conversation or an interaction with an NPC. It is possible that the challenge is in arriving at some destination, retrieving some item, or slaying some sort of threat. Generally speaking, these sorts of quests are completed with triggers. The first step is going to be setting a new trigger. In the triggers tab of your blueprints panel, find the Quest OnEnter trigger template, and draw it on the ground where you wish the quest to be completed. As with the placement of any trigger, each click will add a new corner to the trigger, and as the basic rules of geometry declare, you need at least three corners to make a shape with straight sides (and circular triggers can't be drawn; there are only polygons with many sides).
Now select the trigger you just placed (the "Select Objects" button on your toolbar will allow you to select objects, instead of painting more corners on your trigger). View the properties of the trigger and find the "Scripts" subsection of the trigger's properties.
You'll first want to verify that the acf_trg_ series of scripts are in use on the trigger, and that the name of each script matches up with the event that it is placed on. acf_trg_onenter in the On Enter Script field, for example. Once that is set, click into the "Variables" field and then click on the "..." button on the right side of the field. This will open the variable editing window. At this point, we branch slightly based on what we want this trigger to do:
For All Quest Triggers
Identify the Quest: First, every quest needs to be identified by its tag, which you defined originally when you created the hook for this quest. This is set on ACR_QST_NAME as a string, like this:
Identify the Prerequisite State: Every quest needs to know what you expect nState to be when a player on this quest enters the trigger. By default, this is set to 1, assuming that nState was set to 1 in the initial conversation. However, if you have a more complex quest (Bob says to talk to Harry, who tells you to check on the tree at the top of the hill and come back to him), you might need to change this. The value is stored in ACR_QST_LOWER_STATE, and is an integer (and so may be set in the ValueInt field, like this:)
Identify if This Finishes the Quest: Every quest also needs to know if visiting this trigger provides the reward for the quest. This is set in ACR_QST_UPPER_STATE. If you don't want the trigger to reward experience (if, for example, the rewards will be present when the PC returns to the quest giver), this should be set to 0. If you do wish to reward XP, this should be set to one higher than ACR_QST_LOWER_STATE. It is also an integer, and editing it looks exactly as ACR_QST_LOWER_STATE.
For Scouting Quest Triggers
That's it. You've written this challenge. When a PC visits your trigger and nState is ACR_QST_LOWER_STATE, they will get a journal entry and an nState of one higher. So if ACR_QST_LOWER_STATE was 1, they leave with 2, and you may check for that at the turnin.
For Combat Quest Triggers
You'll need to tool a creature for the PC to fight. Once this is done, you'll set two variables: ACR_QST_SPAWN_CRESREF is set to the resource name of the creature you wish to spawn. Important: Resource Names and Blueprint ResRefs are not necessarily the same. To prevent confusion, you should tool your creatures to always have the same ResRef as Resource Name.
Next, you will set the value of ACR_QST_SPAWN_WAYPOINT to be the unique tag of a waypoint at which your creature will spawn. Usually, this is near or inside of the trigger that is being tooled. Because this needs to be unique, you should pick a tag that is unlikely to be used by anyone else in the future-- usually appending "_spn##" to the quest's tag is a reliable way to ensure as much. In this case, it would be "sample_quest_0_spn01"
With that done, your quest is ready. As with a scouting quest, nState will be 1 higher than ACR_QST_LOWER_STATE, once the creature is killed. For example, if ACR_QST_LOWER_STATE is 1, you should check for nState to be 2 at the next step of the quest.
For Retrieval Quest Triggers
If your quest is a retrieval, you have two more variables to set and one more thing to place. First, you will need to pick a unique tag for a container for your retrieved thing. You don't need to style it like a box or a bag-- it can, for instance, be a hollow tree trunk or a shallow hole, but you'll be tooling it like one. Because this needs to be unique, you should pick a tag that is unlikely to be used by anyone else in the future-- usually, appending "_cntr##" to the quest's tag is a reliable way to ensure as much. In this case, it would be "sample_quest_0_cntr01"
First, create a new string named "ACR_QST_CONTAINER_TAG" and set its value to your unique container tag.
Next, we will want to pick what sort of item will appear in this box. Tool a new item with a new resource name and flavor text to represent the object being retrieved-- and be sure to consider if the item itself is to be part of the challenge (it might apply penalties to the PC, or might be especially heavy, for example). Then create a new variable named "ACR_QST_SPAWN_IRESREF" which has the same value as the item's Resource Name. Important: Resource Names and Blueprint ResRefs are not necessarily the same. To prevent confusion, you should tool your items to always have the same ResRef as Resource Name.
Finally, we need to place a container which has the tag we set in ACR_QST_CONTAINER. Place a placeable in the area (usually near or in the trigger) and ensure five features:
1. The container has no scripts on it
2. The container is set to plot
3. The container has an inventory
4. The container's tag is the one you specified before.
5. The container is empty
As with scouting quests, the item will appear in the chest only if a character whose nState is at ACR_QST_LOWER_STATE enters the trigger, and nState will advance to the next number once they pick up the item (so a 1 becomes a 2, for example), which can be checked later to drive further challenges or a turning.
Placeable Challenges
TODO: Describe how to set up a placeable-based quest challenge
#39;ll need to expand our conversation tree to allow us to have other checks happening-- and maybe let the character pick how they solve whatever problem it is.
Main Page -- Hook -- Challenge -- Turnin
