- Free Dota Template
- Cinematics
- Color Codes
- Dialog Boxes
- Multiboards
- Abilities - Buffs and Spells
- Abilities - Guide
- Abilities - Introduction
- Advanced Skinning in Photoshop
- AI - Basics and Triggers
- AI - The Editor
- Start Here
- General FAQ
- Cameras
- Campaign Basics
- Elevator Switches
- Formula Finder
- Unit Editor
- Trigger Basics
- Variable Basics
- Attachments
- Creating Icons
- Custom Tiles
- Editing Skins
- Fade Filters
- Importing Models
- Loading Screen
- Minimap Image
 |
|
 |
 |
 |
|
Exploring QuestsTutorial By death_knightThe aim of this tutorial is to explain a bit about quests. In this tutorial, we will look at: • Some of the ways you would receive a quest • Quest messages • Creating/Discovering Quests • Quest requirements • Quest descriptions • Quest failure conditions • Completing a Quest 1.0 Receiving Quests This is the first step when considering quests is considering how they will be given to the player. This is very map dependant. Below is a list of possible ways to give a player quests: • Unit-given quests • Quests arising from situations (like a messenger dying in battle) • An overall mission quest (e.g. survive for 30 minutes), usually given after an introductory cinematic There are a number of possibilities that are not on the list above, but the ones listed above are the main ones which people will use and thus they will be explored. 1.1 Unit Given Quests Unit given quests are done by having a notable player unit (e.g. hero or important non-hero unit) near the quest-giver unit. The quest may also have the prerequisite that the player has their notable unit near the quest-giver as well as selecting the quest-giver unit. Below are example of both cases: 1.1.1 Getting close to the quest-giver to receive the quest Getting Near the Unit Events Unit - A unit comes within 'x' of <QGU> <gen> Conditions (Triggering unit) Equal to PlayerUnit Actions -------- Quest Actions -------- Where 'x' is the range which trigger the actions (as long as the conditions are met), PlayerUnit is the player's unit and <QGU> <gen> is the quest-giver unit. 1.1.2 Getting close to and selecting the quest-giver to receive the quest Getting Near and Selecting the Unit Events Player - Player 1 (Red) Selects a unit Conditions (Triggering unit) Equal to <QGU> <gen> Actions Unit Group - Pick every unit in (Units within 'x' of (Position of (Triggering unit))) and do (Actions) Loop - Actions If (All Conditions are True) then do (Then Actions) else do (Else Actions) If - Conditions (Picked unit) Equal to PlayerUnit Then - Actions -------- Quest Actions -------- Else - Actions Where 'x' is the range which trigger the actions (as long as the conditions are met), PlayerUnit is the player's unit and <QGU> <gen> is the quest-giver unit. The first one is good if there is a lot of room to move around the quest-giver unit so that the player can avoid receiving the quest for whatever reason. The second one better because it makes sure that the player doesn't unintentionally receive the quest, and it can be used for quest-giver units where there isn't a lot of room to move around them. 1.2 Quests Arising from a Situation This is a good way of receiving quests as there is a theoretically infinite number if situations you can have. For example, in one area you could have a situation where a messenger dies and you have to deliver their message, a situation where you are robbed by bandits and they steal something important, and a situation where a major enemy is seen moving through the area in great numbers. The number of situations you can have for one area is only limited by your imagination and patience! The way these situations are put together usually involve the player triggering a cinematic (by entering a particular region, for example) which will depict the situation. After the cinematic is done, then the quest is given. I don't have the space, patience or time to give you a worked example, but just remember: • Triggering Event • Cinematic Sequence • Give the Quest 1.3 Overall Mission Quest These quests are quests which are given after an introductory cinematic and also precede each other (if applicable). The first main quest is always given after the intro cinematic. This could be to establish a base or destroy an enemy's base. If there are more main quests for the player to do (e.g. launch an assault after establishing a base), then the next main quest is given shortly after the completion of the preceding main quest. Once the final main quest has been done, then typically the map will end with victory. Many of these quests have a defeat condition, while others won't. For example, if you are escorting a convoy of 4 kodo beasts from one place to another, then a defeat condition may be that 2 must survive the entire journey; while a quest such as establishing a base will not have a defeat condition. 2.0 Quest Messages Quest Messages are very versatile as they can be used for a number of things (as seen in the list below). • Quest Discovered • Quest Update • Quest Completed • Quest Failed • Quest Requirement • Mission Failed • Hint • Simple Hint • Secret • Warning • New Unit Acquired • New Unit Available • New Item Received What you use all of these different types for is pretty self explanatory, but you must make sure you use the right colours for the right types. For all quest related messages, the title (i.e. "Quest Discovered", "Quest Update", "Mission Failed", etc.) are coloured yellow. "Hint" and "Simple Hint" are coloured light green. "Warning" is coloured red. "New Unit Acquired", "New Unit Available", "New Item Received" are light blue. I'm not sure what colour "Secret" would be. 3.0 Creating/Discovering Quests Creating a quest is quite simple process. In this section, we will not look at how these triggers are set in motion (that's up to you), only what they do once they are. 3.1 Creating a Quest There are two things that you need to do before you make this trigger: The first is to figure out how you set this trigger. This could be anything from having an action at the end of a cinematic trigger which runs the quest creation trigger to having it run at the beginning of the map through the use of a trigger with a "Map Initialization" event. The second is to make sure that this trigger, once run, will not be able to be run again. The way used in the maps for the campaign "Founding of Durotar" is setting the trigger it "Initially On" with no events. When the trigger was run, it would check whether or not it was on, and then ran the actions, one of which was turning it off. Apart from the action(s) which will help you make sure this trigger can't be run again, the actions you need can be seen below. To help me iterate what you need, I'm suing a quest creation trigger I'm using in my current project: Quest HonourOfTheFallen Create Events Conditions ((This trigger) is on) Equal to True Actions Trigger - Turn off (This trigger) -------- Create the quest objects -------- Quest - Create a Required, undiscovered quest titled Honour of the Falle... with the description For the sake of hon..., using icon path ReplaceableTextures\CommandButtons\BTNShaman.blp Set QuestHonourOfTheFallen = (Last created quest) Quest - Create a quest requirement for (Last created quest) with the description Deliver Moggar's me... Set QuestHonourOfTheFallenReq1 = (Last created quest requirement) -------- Flag Quest Progress -------- Set QuestHonourOfTheFallenProgress = (Max(1, QuestHonourOfTheFallenProgress)) The condition and the first action are the fail-safe to make sure the quest isn't created again (just as I aforementioned). The next action is creating the quest. Make sure you do 4 things: • Make sure it's an "Undiscovered" quest. • One mistake (which I'll explain in more later) is writting the quest requirements in the quest description. DO NOT do this. • Make sure the icon is appropriate to the quest. • Make sure the description doesn't include the quest objectives. The next action assigning the quest to a variable so that it can be easily referred to later. The third action is cheating the quest requirement. You can have as many of these as you like. The fourth action is assigning the requirement to a variable so that, just like the quest, it can be easily referred to later. The last action refers to setting the progress of the quest. The variable is an integer. For (Max(1, QuesthonourOfTheFallen)), it picks the greater value of the two given values. For more info on it, see[http://world-editor-tutorials.thehelper.net/cat_usersubmit.php?view=39620]. This variable indicates the progress of the quest from creation to completion. 3.2 Discovering the Quest Discovering the quest can be a separate process to creating it. For the purpose of this tutorial, it will be regarded as a separate process. When the appropriate time arrives, the quest will need to be marked as discovered so that the player can refer to the details of the quest using the quest menu should the need arise. To make sure this process is done correctly, there are a couple of steps that need to be made. • The first step is to run the quest creation trigger to make sure that the quest does indeed exist. If it already exists, then the fail-safe that you should have in place will prevent the trigger from creating it again. • The second step is to mark the quest as a discovered quest. • The third step is to send the player a quest message to indicate that the quest has been created as well as provide a quick overview of the quest objectives. • The final step is to set the quest progress variable to 2. Setting this variable to 2 indicates that the quest has been discovered. Once you have done this, your discovery trigger should look something like this: Quest HonourOfTheFallen Discovered Events Conditions Actions -------- Ensure that the quest exists -------- Trigger - Run Quest HonourOfTheFallen Create <gen> (checking conditions) -------- Update the quest -------- Quest - Mark QuestHonourOfTheFallen as Discovered -------- Display a quest message. -------- Quest - Display to (All players) the Quest Discovered message: |cffffcc00MAIN QUES... -------- Flag Quest Progress -------- Set QuestHonourOfTheFallenProgress = (Max(2, QuestHonourOfTheFallenProgress)) 4.0 Quest Requirements This is a very important part of creating your quests as it makes life easier. Let me explain by describing what some people do in the quest description. For example, if the objective of the quest was to bring a message to a person, then people would make the quest description something along the lines of the following:
I know my example is brief, but you get the idea. There are two reasons why you don't do this: • Especially if you have multiple objectives, it can get very messy when it comes to marking the objectives as complete because it involves long, messy triggers to change the quest description as well as the use of colour codes. • Using quest requirements rather than doing it this way is so much easier and requires less triggers and actions. This means that's easy, short, and clean. Instead of doing what's in the example above, create the quest requirement(s) and then just set the quest description to purely the description of the quest. Using the previous example, you should set "Deliver the Message to X" as a quest requirement, and "Your goal is to deliver a message to X" as the quest description. As I aforementioned, this makes it easier as all you have to do to mark the objective as complete is to use the one relevant to mark it as complete. Be sure to, when you create the requirement, to assign it to a variable to that when the player completes it, it can be easily referred to and thus marked as complete. 5.0 Quest Failure Conditions Defeat conditions are conditions which, when fulfilled, cause the player to fail the quest. This could be anything from losing all your buildings to letting your hero die. The only thing is they are generic, so they apply to all quests. This means that if you create a defeat condition such as "X must survive", then it will apply for all quests. I'm not entire sure how you would work a defeat condition. My suggestion is that instead of using a defeat condition, create another quest requirement which, in a sense, will act as a defeat condition for the specific quest. What you would have to do then is then trigger the circumstances where that requirement would be met, thus failing the quest or worse, failing the mission overall. 6.0 Completing a Quest When all of the requirements have been met, then you can mark the quest as complete. I leave it to you to create the triggers that mark each requirement as complete. For the completion trigger, there are a number of things which could make it run. This could be checking whether or not all of the requirements are complete and, if so, running the complete trigger. It could also be that your main unit approaches the quest-giver unit for a reward. There are a number of things that your completion trigger should have. These include: • It should run the quest creation trigger again to be 100% sure it exists. • it should mark the quest as discovered. • t should mark all the requirements as complete. • It should then mark the quest as complete. • It should then send the player a message to indicate that the quest is complete. • You should then include any "Cleanup" actions. • Finally, you should set the quest progress integer to (Max(3,<quest Progress integer>)) A basic example from my quest can be seen below: Quest HonourOfTheFallen Completed Events Conditions Actions -------- Ensure that the quest exists -------- Trigger - Run Quest HonourOfTheFallen Create <gen> (checking conditions) -------- Update the quest -------- Quest - Mark QuestHonourOfTheFallen as Discovered Quest - Mark QuestHonourOfTheFallenReq1 as Completed Quest - Mark QuestHonourOfTheFallen as Completed -------- Display a quest message. -------- Quest - Display to (All players) the Quest Completed message: |cffffcc00MAIN QUES... -------- Flag Quest Progress -------- Set QuestHonourOfTheFallenProgress = (Max(3, QuestHonourOfTheFallenProgress)) I hope this helps. Comments/Criticism/Suggestions of more content are welcome. Cheers, death_knight Click here to comment on this tutorial. |
||
 |
 |
| Designed by Arkheno
2005 Blizzard Entertainment® Blizzard Entertainment is a trademark or registered trademark of Blizzard Entertainment, Inc. in the U.S. and/or other countries. All rights reserved. |
Team Griffonrawl Trains Muay Thai and MMA fighters in Ohio.
Apex Steel Pipe - Buys and sells Steel Pipe.