SQS – Segal’s Quest System



Technical System Notes
SQS allows a developer to quickly create complex quests in an integrated environment.
 * The system manages the player’s quest, the quest database, and the player’s quest database.  It is designed to use a custom quest journal that displays values that are important to the system.
 * For all quests, the system requires a Quest Id, which is typically a 4 digit code assigned by the developer.
 * The quest is stored in the database by completing a “Quest Add Template” (see Appendix A at the bottom of the page) and saved in the appropriate Quest Master Script.
 * All the global information is stored in a single database; this includes information like quest name, quest givers name, quest givers location, quest steps, rewards, etc..
 * In addition, every player that logs into the world is assigned a Player ID and a unique database is created for the player to store information specific to that player. This includes current quests, completed quests, and other quest tracking information.
 * SQS does not use generally use quest items; they cause toolset, inventory clutter and allow quests to be easily exploited.  Instead, the status of the quest is maintained internally.  Dependent upon the quest type, the player may see flavor text messages letting them know they collected an object but no actual item is added to the inventory.

The Basics

 * All quests have common elements and SQS has standardized those elements to eliminate writing dozens of custom scripts every time you want to add a quest.
 * Quests are essentially tasks that the player must accomplish; we track the progress of the quest in steps. For purposes of SQS, we call these steps the Quest State.
 * The Quest State is a number that defines where the player is in the progression of the quest and we use that number to define how NPCs (and other objects) will react.

There are three KEY rules that are important to know about the Quest State. The rules are outlined below:

The Value 0 Rule
If a player has a Quest State of 0 (zero) for a quest then player does not currently have that quest as one of his or her open quests. This is an important distinction because we only want to have our Quest giver offer the quest if the player does not have the quest. There is a template that can be used called the “qtb_conv_quest_conditional” template that can be used to make this check. Copy the template to the appropriate dialogue line and enter the parameters.

The Value 98 Rule
If a player has a Quest State of 98 for a quest, this means that he has finished the actual task but has not been back to the quest giver to receive his reward and to close out the quest. The value of 98 is a internal number used by the SQS to designate the players status and it is commonly seen in Kill X Creature Quests or Collect X Object Quests. For example: The SQS system tracks how many creatures a player has killed when he is on a Kill Quest. When the process determines he has killed the number of creatures that were assigned, it automatically changes the Quest State to 98.

The Value 99 Rule
A player will have a Quest State set to 99 when he has completed a quest and received his reward from the quest giver. The value of 99 essentially says that this quest has been completed and is considered a closed quest. For the most part, quests should not be repeatable and the quests that are repeatable will require some special attention so that multiple completions of the quest do not inflation the player’s quest total scores.

Quests (and Quest States) should be designed to progress in a logical and sequential order to best take advantage of the functions of SQS. The player begins with a Quest State of 0 (zero) since he doesn’t have the quest yet. He speaks to a quest giver and receives the quest; at that point a script changes his Quest State to 1. From this point forward, you could have any number of quest updates that would increase the Quest State. Eventually the quest will end and the Quest State would be set to 99.

Typical Quest Types
Below I have summarized the basic quest functions that can be used to create quests. Once you understand the general concepts, you can use the SQS system to manage completely new types of quests that build on the current framework.

Kill Quest

 * Notes: Kill Quests are used in a number of different ways. It can be a simple “Kill X number of Goblins” type quest or “Kill Big Boss #123” quest, or even “Destroy X number of objects”.  The quest tracks how many of the associate creatures are killed and automatically updates the quest when the correct number has been killed.
 * Usage: A Kill Quest is typically initiated via a conversation; in which case there is a script template available to facilitate creating the quest (qtb_start_kill_quest).
 * Place this script on the appropriate dialogue line and it will process the start of the quest.
 * The quest state will be set to 1 and the number of kills required will be determined by the Kill_Cnt variable set in the “Add Quest Template”.


 * Variables: The target creatures of the kill quest need to have the following variable assigned which lets SQS that they are part of the quest.
 * QuestName_1 	- 	Quest ID
 * Any single creature can be used in up to three kill quests.
 * Subsequent quests will use the variables QuestName_2 and QuestName_3.
 * SQS automatically searches every creature for those 3 variable names when the creature is killed.


 * Variants: There is a standard script available (std_destroy_obj_qst_update1) that will update a Kill Quest if a placeable object is destroyed.
 * This lets you create quests such as “Destroy the 4 weapon caches in the goblin camp”.

Collection Quest

 * Notes: Collection quests are typically design so that the player is assigned to go retrieve certain objects.
 * A collection quest can include up to 10 collectable objects.
 * When the player is given the quest, a string is stored in the player’s database that defines which objects he has collected and which he has not.
 * For example, if the PC is given a task to find five (5) hidden books; the following string will be stored, “NNNNN”.
 * The five “N”’s signify that the player needs to collect 5 items and has currently found none.
 * If he successfully collects one of the quest objects, the string will change the appropriate “N” to a “Y”.
 * This is displayed to the player in the quest GUI; thus the player could tell by seeing a collection string of “NNYYN” that the quests requires collection of 5 objects and that he has collected numbers 3 and 4.


 * Usage: A Collection Quest is typically initiated via a conversation; in which case there is a script template available to facilitate creation of the quest (qtb_start_collection_quest).
 * The number of items required to be collected is set in the Quest Add Template (See Appendix A).
 * When a collection quest is given, the quest state is automatically set to 1. When all objects have been collected, the quest state is automatically changed to 98.


 * Variables: Two variables must be placed on each placeable object that is part of the quest.
 * The placeable object must be useable (and usually plot) and have the std_collection_qst_update script attached in the OnUsed event.
 * Collection_1	- Quest ID
 * Collect_1		- Collection Count
 * Note: Like Kill Quests, you can use the same placeable object for multiple quests (max 3).
 * For a second quest using the same placeable, the variables would be stored as Collection_2 and Collect_2 (and Collection_3, Collect_3 for a 3rd quest).


 * Variants: Collection quests can be update in numerous ways but one that I found to work well was using triggers (std_qst_update_enter_use).
 * You can create a quest where the PC has to survey a mine or explore a region, updating the quest when he enters certain triggers.

Sequenced Collection Quest

 * Notes: The collection quest works identically to a normal collection quest except that the collection items must be collected in numerical order.
 * Thus the quest will only update when the player touches collection object #1, then #2, and so on.


 * Usage: Sequence Collections are created just like normal Collection quests except that the script used on the placeable object is “std_seq_collection_qst_update” instead of std_collection_qst_update.

General Quest

 * A General quest is an all-purpose quest that doesn’t have any systematic processing to update it.
 * For the purposes of storytelling, General quests are often the bread and butter behind them.  Typically, the general quest is a series of related events that each updates the quest.
 * Ex: The Blacksmith tells the PC that he needs more coal for his forge.
 * He directs the player to speak with The Miner to obtain the coal.
 * The player speaks with “The Miner” who tells them that the coal is still in the mine but that the mine has been occupied by a violent spirit.
 * With that outline, we can create our quest.
 * What we have is 3 quest states;
 * QS1 = player qets quest from Blacksmith,
 * QS=2 player talks to “The Miner”, and
 * QS=3 when the PC “uses” the mine cart in the mine.


 * Functionally we would use “qtb_start_standard_quest” during the Blacksmith conversation to start the quest (which automatically sets the Quest state to 1).
 * We then use “qtb_conv_quest_advance” script to advance the quest state from 1 to 2 during The Miners conversation.
 * Finally, we place “std_qst_update_enter_use” script on the mine cart to advance the quest to 3.

Gather Quests

 * Notes: Gather quests are the standard Collect 10 Bat Ear type quests.
 * Use the “qtb_start_item_gather_quest” template to create the quest.
 * Gather quests are party based; each player in the group has an individual chance to get the quest item.


 * Usage: Enter the number of items to be collected in the Coll_Cnt field of the Quest Template.
 * Variables:
 * GatherItemQst_1	- Quest ID
 * IGO_DropRate_1	- (Integer) base chance the item will drop (1 to 100)
 * IGO_ItemType_1	- (String) Descriptive Text of the Item (i.e. Bat Ear).

Drop Items Quests

 * Notes: This is a quest where the player is assigned to collect certain items off of specific creatures. For example, collect a bar ear off the white bats, an Antler off the Ravaged Deer, and a Tusk off the Dire boars.
 * Use the qtb_start_collect_quest script to create the quest. This is a party based quest; each player in the group has an individual chance to collect the item.


 * Usage: Store the following variables on the creatures involved in the quest
 * DropItemQst_1 (String) Quest Name
 * DropItemType_1 (String) Item Type, ie. Bat Ears
 * DropItemNum_1 (Integer) Collection number.


 * Completing this quest will set the Quest State to 98. The chance that the item will drop is a flat 10% per kill.

Appendix A: Quest Template
////////////////////////Quest Add Template///////////////////////////////////////// /* sQuestID    = ""; sQuest_Name = "";    // 16 Character Variable Name sQuest_Name2 = "";   // Short Description (32 Char) sQuest_Maker = "Segal";   // Author of Quest

sNPC_Name = ""; sNPC_Loc  = ""; Qst_Rating = 0; Qst_Type  = ""; Kill_Cnt  = 0; Coll_Cnt  = 0;

Step1 = ""; Step2 = ""; Step3 = ""; Step4 = ""; Step5 = ""; Step6 = ""; Step7 = ""; Step8 = ""; Step9 = ""; Step98 = "";

Qst_Reward1  = "";   Qst_Reward2    = "";                   //resref Gold_Reward  = 0;    Exp_Reward     = 0; Itm_Dest1 = "";      Itm_Dest2      = "";     Itm_Dest3  = ""; // Tag Fame_Type    = "";   Fame_Bonus     = 0; Faction_Type = "";   Faction_Bonus  = 0; SaveQuestGeneralInfo(sQuestID, sQuest_Name, sQuest_Name2, sQuest_Maker, sNPC_Name, sNPC_Loc, Qst_Rating, Qst_Type, Kill_Cnt, Coll_Cnt); SaveQuestStepInfo(sQuestID, Step1, Step2, Step3, Step4, Step5, Step6, Step7, Step8, Step9, Step98); SaveQuestRewardInfo(sQuestID, Qst_Reward1, Qst_Reward2, Itm_Dest1, Itm_Dest2, Itm_Dest3, Fame_Type, Fame_Bonus, Faction_Type, Faction_Bonus, Gold_Reward, Exp_Reward);  

