[Crossfire-wiki] [Crossfire DokuWiki] page added: user:cavesomething:guide_to_quest_dialogs
no-reply_wiki at metalforge.org
no-reply_wiki at metalforge.org
Mon Mar 22 19:27:21 CDT 2010
A page in your DokuWiki was added or changed. Here are the details:
Date : 2010/03/22 19:27
User : cavehippo
Edit Summary: created
====== Dialog-Driven Quests ======
The following is a guide to creating your own dialog-driven quest.
By dialog-driven, I mean that most of the events in the quest occur from talking to NPCs.
You can construct a quest without speaking to any NPCs, but it is harder to write a narrative when you do that.
===== Dialogs =====
Dialogs are specified using a JSON syntax, we'll have a simple example first, followed by a general explanation of all the options:
==== Example ====
<code>
{
"location" : "friendlypeep",
"rules": [
{
"match" : ["*"],
"pre" : [["token", "seenbefore", "yes"], ["item", "money", "100"]],
"post": [],
"msg" : ["Hello again $you, you are rich."]
},{
"match" : ["*"],
"pre" : [["token", "seenbefore", "yes"]],
"post": [],
"msg" : ["Hello again $you."]
},{
"match" : ["*"],
"pre" : [],
"post": [["settoken", "seenbefore", "yes"]],
"msg" : ["Hello I'm $me."]
}
]}
</code>
==== Taking it apart ====
Each potential line of dialog forms a 'rule' these rules are checked in sequence, from the top of the file down.
* The first part of each rule is the 'match' - This is what the player has said to the NPC - These ones are all * so will match on anything the player might say.
* Next are the 'pre' conditions, in order to match a rule, **all** of the pre-conditions must be true.
* After that we have 'post' actions, these are things that happen after
Because we check from the top down, the most restrictive rule goes first.
=== Rule 1 ===
We'll look at the topmost rule first.
<code>
{
"match" : ["*"],
"pre" : [["token", "seenbefore", "yes"], ["item", "money", "100"]],
"post": [],
"msg" : ["Hello again $you, you are rich."]
}
</code>
There are two conditions we must meet.
The first condition is:
<code>
["token", "seenbefore", "yes"]
</code>
This checks that the token "seenbefore" has been set to yes.
Tokens are set in dialogs by the 'post' actions, if this is your first time speaking to this character, it won't have been set yet.
The second condition is:
<code>
["item", "money", "100"]
</code>
This checks if the player has enough of a certain item, first there is the item to check for, then the number required.
"Money" is a special case, it checks for silver, gold or platinum, up to the required value in silver. (so in this instance 2 platinum would meet the target, as would 1 platinum, 4 gold and 10 silver)
There are no post actions for this rule, so now we look at the message:
<code>
"msg" : ["Hello again $you, you are rich."]
</code>
This is the text that the NPC will say to the player. //$you// is replaced by the name of the player
===Rule 2===
Rule 2 is similar to rule 1, except that the item condition is missing, as such it will trigger when the token is present, but the amount of money held by the player is less than 100
===Rule 3===
<code>
{
"match" : ["*"],
"pre" : [],
"post": [["settoken", "seenbefore", "yes"]],
"msg" : ["Hello I'm $me."]
}
</code>
Rule 3 has no pre block, and matches *, so it will always work if one of the other rules hasn't triggered first (that is why it is the last rule to be checked).
Here we have a 'post' block which sets the token 'seenbefore' to yes, this means that the next time that we speak to this character, the check ["token", "seenbefore", "yes"] will pass and one of the first two rules will be used.
Tokens are stored in the player file, under the "location" which was specified at the top of the file. Any dialog files which point to the same location have access to the same tokens (and can affect the values they hold). Two tokens with the same name but in different locations are treated separately.
Finally there is the message block where //$me// is replaced by the name of the NPC.
==== Full List of options ====
The options that can be used vary in the different blocks:
=== The Match Block ===
This holds the text that the player should say before we check if the rule applies.
There can be one or multiple words specified, or "*" which matches anything.
eg
<code>
"match" : ["gork","hoard","yes","want"]
</code>
This will match any out of "gork", "hoard", "yes" or "want"
=== The Pre Block ===
In the Pre Block, the following checks are supported:
* Quest
* Item
* Token
== Quest ==
Quest is followed by two fields, the name of the quest, and the stage that the player must be at or past.
eg
<code>
["quest", "testquest", "5"]
</code>
Checks that the player has reached at least step 5 of the quest 'testquest'
== Item ==
Item is followed by the name of the item to check for, and optionally the number that are required.
eg
<code>
["item", "testquesttarget"]
or
["item", "money", "100"]
</code>
The first example looks to see if the player is holding at least one item called "testquesttarget", the second looks to see if he is holding at least 100 "money".
"Money" is a special case, it checks for silver, gold or platinum, up to the required value in silver. (so if you look for 100 money then 2 platinum would meet the target, as would 1 platinum, 4 gold and 10 silver, or 1 gold and 90 silver, etc)
The number of items required may be omitted, if so it will look for '1' of the item.
The number may also be set to '0', this checks that the player does **not** have the item.
== Token ==
Checks for Token to have a value from the list of values provided.
eg
<code>
["token", "pester", "1"]
</code>
Checks whether the token "pester" holds the value "1"
There can be more than 1 value provided.
Tokens are stored in the player file, under the "location" which was specified at the top of the file. Any dialog files which point to the same location have access to the same tokens (and can affect the values they hold). Two tokens with the same name but in different locations are treated separately.
=== The Post Block ===
After the Pre block is used to decide whether a message should trigger, the post block holds the consequences.
There are 5 different options here:
* quest
* giveitem
* takeitem
* settoken
* connection
== quest ==
This sets the named quest to the stage which is specified.
eg:
<code>
["quest", "testquest" "5"]
</code>
Moves the player to stage 5 in "testquest"
If the quest hasn't been started yet, this also starts the quest.
Note that you can not set a quest to a stage which is earlier than the one it is currently at.
In order to prevent that happening, you should have an earlier rule which checks for the stage you want to advance to, typically this not going to do much other than remind the player what already happened.
eg
<code>
"match" : ["*"],
"pre" : [["quest", "testquest" "5"]],
"post": [],
"msg" : ["I've already opened the door."]
},{
"match" : ["*"],
"pre" : [["quest", "testquest" "4"]],
"post": [["connection", "4"], ["quest", "testquest" "5"]],
"msg" : ["I'll just open the door for you."]
</code>
The first rule triggers when we are already at stage 5, the second rule when we are at stage 4, and then moves us to stage 5
== giveitem ==
Gives the player an item or items from the NPCs inventory.
eg
<code>
["giveitem", "biccie", "2"]
or
["giveitem", "money", "74"]
</code>
The first of these gives the player an 2 'biccie's - There **must** be at least one such an item in the NPC's inventory already for this to work. This item may be customised in any manner you want in the map editor. It does not matter how many biccies the NPC actually has, one is enough; when they give items, they create copies of the ones they already have.
The second of these gives the player 74 money, made up of the smallest possible number of platinum, gold and silver coins. The NPC does **not** need to have money in his inventory in order to give it.
The name should be the name of the item to be given, or money. The number may be omitted, if so it is treated as 1.
Note that items which are given away are in the NPCs inventory, so if the NPC is killed, they will drop. If you don't want to be able to acquire these items through killing the NPC, then you should set the god-given flag on the item. - This is removed when the item is given to the player.
== takeitem ==
Removes the given number of an item from the inventory of the player.
eg
<code>
["takeitem","testquesttarget"]
</code>
Removes one instance of an item called testquesttarget from the players inventory.
You may specify "money" and coins will be removed to the correct value.
You may omit the number, and 1 will be assumed.
You may specify '0', which will take all of the items of the specified type.
Note that you will need to check that the player has the item(s) to take first, as such you should always use this in the following way:
<code>
"match" : ["*"],
"pre" : [["item", "testquesttarget"]]
"post": [["takeitem","testquesttarget"]]
</code>
That is to say, having a matching item check before removing the item.
== settoken ==
Sets the specified token to the specified value, other rules can query this value using 'token' in the pre block.
Tokens are stored in the player file, under the "location" which was specified at the top of the file. Any dialog files which point to the same location have access to the same tokens (and can affect the values they hold). Two tokens with the same name but in different locations are treated separately.
== connection ==
Triggers the specified connection on the map
eg
<code>
["connection", "4"]
</code>
This allows NPCs to appear to do things for the player.
eg
<code>
{
"match" : ["*"],
"pre" : [["quest", "testquest" "4"]],
"post": [["connection", "4"], ["quest", "testquest" "5"]],
"msg" : ["I'll just open the door for you."]
}
</code>
will give the impression the NPC has opened a door as long as there is a door with connection 4 set in the map editor.
=== The msg Block ===
This is send directly to the player, if the pre conditions are matched, with the following exceptions:
//$you// is replaced by the name of the player
//$me// is replaced by the name of the NPC
Obviously, it probably doesn't make sense to use $you on the first line of dialogue that will be spoken, unless there is a story-based reason for the NPC to know who the player is.
IP-Address : 81.141.60.247
Old Revision: none
New Revision: http://wiki.metalforge.net/doku.php/user:cavesomething:guide_to_quest_dialogs
--
This mail was generated by DokuWiki at
http://wiki.metalforge.net/
More information about the crossfire-wiki
mailing list