I suppose in its simplest form a quest follows these steps:
1. Attain quest - usually by talking to a non-player character (NPC)
2. Perform quest - do the action commanded by the NPC
3. Accept reward - get something in return for completing the quest
To give an example of the above steps as they should appear in your game commands, here is what happens: Store a variable in your code called BEARQUEST. Set it's value to 0. You talk to the village elder (an NPC) who's code is partitioned in this manner:
If BEARQUEST =0 then say a$
If BEARQUEST =1 then say b$
If BEARQUEST =2 then say c$
If BEARQUEST =3 then say d$
Since your BEARQUEST variable is 0 at the moment, he says a$ which could be this.
"A bear is eating all the children. If you slay him, I will reward you with 500 gold coins."
Once the text is said, have the code change BEARQUEST to 1.
If you now talk to the elder, he will say b$, which could be "Please hurry in your quest."
At this point the player wanders all around the game until the bear is found. Once killed change
BEARQUEST to 2. Now return to the village elder who now says c$, "You've saved us! Here is 500 gold coins!"
Now to complete the quest, change BEARQUEST to 3 so that from now on, everytime you talk to the elder he will
say d$, "Thank you for saving the children. Good luck in all your future adventures."
Congratulations if you could follow that, it's all there is to making a quest.
Now you're probably thinking, "That's not hard at all! I thought this was advanced quest design!" Don't worry, I'm not finished yet. The above design was more or less what was used in Dark Ages I. Its brilliance is in its simplicity (and that it works), but its drawbacks are impracticality, informal structure, and wasted space. While programming Dark Ages II, I discovered something better structured, external, and more malleable is necessary for what is going to be a much larger and more complex program. Using the basic concepts of the above example and integrating better structured coding such as scripting, I believe I have come up with a great quest system.
In order for this to make sense, you need to be familiar with scripting. I can't give you a good impression of it here, but it's basically a few lines of code that get their data from external files (usually .txt) and perform the actions based on the data read. The advantages are almost essential in programming because they save a lot of code space, structure your program, and organize what would otherwise be an uncontrollable amount of variables. In my strategy, quest coding requires three things: speech scripting, object scripting, and a universal variable dimension. The universal variable dimension (UVD) is a simple integer dimension from 1 to whatever, where each number represents a variable and could have a value from 0 to whatever. Now here comes the surprise, this strategy is advanced, yet amazingly simple. My speech script contains the following necessities, but yours could be modified to your needs. It contains the variables required, the text that is spoken, and the variables that are changed. The text scripting code would be read whenever a player attempts to talk to someone.
Let's look at some pseudo code of my script:
*"1","0"
*"1","1"
*"Help me, I have a horrible disease and need a magic cure potion!"
*"1","1"
*"1","2"
*"Thank you for saving my life. Take this magic item as thanks."
*"1","3"
*"2","1"
*"1","3"
*"I'll never forget how you saved my life."
Here's how it works. Variable 1 from your UVD currently has a value of 0. According to the above script, if
it has a value of 0 or 1, the text would read, "Help me, I have a...etc." and then change variable 1 to have
a value of 1 (obviously if it was 1 already, changing it to 1 would mean keeping it the same). If it had a value
of 2, it would read the corresponding text, change it to 3, then change varialbe 2 (perhaps a magic sword variable)
to have a value of 1. After that, every time the text is read, it would find variable 1, value 3 and read that
corresponding text, never making any more changes.
"Hold up! Where did variable 1, value 2 come from?" Ahh, good question! Here's where object scripting comes in. Object scripting is in many ways similar to text scripting. The basics that I have integrated are type of object, variables required, text to be read, and variables changed when activated.
Let's look at some object pseudo code:
*"1"
*"1","1"
*"You have found a magic cure potion."
*"1","2"
Unlike text scripting, object scripting needs to be read twice in the game. The first time it is read is when
the map loads. You have to write a script that will search your file for the objects that will show up on the
map, then a separate script for what happens when you manipulate those objects while playing the game. In the
case of the above code, the first "1" represents that the object is something that you pick up if the UVD variable
1 has a value of 1 (as shown in the second line of code above). If you had a value of "2" for the first line, it
could be an object that you activate, but do not pick up, like a lever or switch. In this manner, if you load the
map before you have been given the quest to find the magic cure potion, then your UVD variable 1 would have a
value of 0 and the potion would not appear on the map. But if you have been given the quest, then your UVD
variable 1 would have a value of 1 and the potion would appear. The third line of code is what appears signifying
you have picked up the potion and the fourth line gives variable 1 a value of 2. Now if you redraw your map and
check your object script, it will no longer draw the object because your UVD variable 1 has a value other than 1.
If you've been following all this then you will notice that variable 1, value 2 is the key to finishing the quest
you started in the scripting code. You can now return to the NPC who sent you on the quest and get your reward.
Obviously this is a very basic example of advanced quest programming. Your scripts may contain up to 20 lines, and manage up to 10 variables as some of mine do in DA2. It just depends on how complex of an engine you desire. But hopefully you've picked up what a quest is in an RPG computer game. Simply put, a quest is just the manipulation of people and objects in the game. You could even go so far as to create your own program to manage your NPC and object scripts while you write them.
The I-Face Warehouse is a site about graphics, web-design, etc. They provide you with a huge collection of interfaces you can freely use on your site! (like Future Software did) They also have tons of website templates, all top-notch design! Now, see how many points they scored:
| Topic: | Mark: | Description: |
| Design: | 7.3 | Could have been better, if their menu was in a side-frame, while the content was in the main-frame.. Also, i would have used another font, like Verdana, and not the standard one.. |
| Compatibility: | 7.0 | This site works just fine with with a resolution of 800x600, and higher, but not when you're viewing the site with a resolution of 640x480.. |
| Content: | 9.5 | This site is really filled with lots of good, useable information and cool interfaces, banners, website-templates, etc... |
| Updating: | 9.0 | This guy updates his site a lot, that's all I can say here.. |
| Overall: | 8.2 | |
© Copyright 1999-2000 The QB Times.
This tutorial was taken from The QB Times with permission from the webmaster(s) of the site. You may not take this article and place it on any other website.