Once you read the guide, get the example scenario 1. What is a variable? The technical definition of a variable is a place in memory used to store a value that is unknown at the time of creation. At this point, that probably doesn't make much sense to you (and if it does, you really don't need to read the rest of this guide). That's okay; I just needed to get that out of the way so I can start explaining it to you. So what does it mean? Well, when you create a scenario, there are things you may not know, or that can change, depending on the player. Still confused? An example is probably in order: Say in your scenario you want to create a shopping list ( You can actually create a variable that stores this information so that you don't need to know it when you make the scenario. Instead, you simply refer to it by its Okay, now I will break away from the example to explain another aspect of variables. This is actually very logical if you think about it: If you don't know what this mystery value is when you create this scenario, how in Hades' name can you use it? The answer is very simple: Names. Every Quest Var that you create will have a name. Remember it, because without it, you're screwed. A name can be anything, really. I like to use descriptive names because they allow me to remember what variable is for what. So in our example, there will be four Quest Vars: one for the rug, one for the house, one for the donkey and one for the fish. Lets make some names: Okay now what? you may ask yourself at this point. Well remember, a variable is just a value. We can use it to keep track of things. Let’s say, if the player has the item, its variable value will be 1 and if they don't, the value will be 0. These are really arbitrary, but I use 0=FALSE 1=TRUE because its sort of a programming thing (I could have used 121.5=TRUE and anything else=FALSE or some other nonsense but lets face it, that's just asking for typos). So: So far we have a good definition of a Quest Variable in plain English: Any value that you don't know when you create the scenario or that can change when the scenario is played. It has two parts (in AOM:TT) A name and a value. 2. Types Okay, this is a short one, but it's here for posterity. There are many types of data that your computer can store. It can store "strings" which are strings of characters (anything you can type is a character), there are integers (i.e. 1, 2, 3, 4, 5, etc), there are boolean values (Big word...just means true or false only), and many, many more. But you, as a scenario designer for AOM:TT, don't have to even think about it. Its all handled because the only type of information your Quest Variables are allowed to hold are called Float. That's short for Floating Point decimals. For those of you who are mathematically challenged, a floating point decimal is any number with a decimal point in it. You know, this guy: . As in 32.33, 1234.70, etc. In fact, any value you give it will automatically be given many decimal places: 1 becomes 1.00000000 (or so), etc. So the main thing I want you to get from this chapter is: If you want to go on to do other types of programming, there are many different types of variables. If you're going to stick with scen designing, only worry about the decimal point numbers. 3. Trigger Effects using Quest Variables Okay, I started with effects because they are what you will use to set up your Quest Variables and give them values. Conditions will be covered in the next section. Also note that some of these conditions/effects may come from the New Editer as I downloaded that before I ever opened the editor and I don't really know which ones came with what. Quest Variable effects are easy to recognize, they all begin with Quest Var. Here are the important ones: 4. Conditions using Quest Variables There are only two conditions that I will go over for Quest Variables. These are really where Variables show their usefullness. First a small explanation of some minor programming type stuff: IF...THEN. Okay, short logic lesson. As you may (or may not) know, all conditions are similar to the english IF...THEN. In other words, the Unit In Area condition is One more note about conditions: Remember, you can use multiple conditions with "AND" or with "OR" to get the desired results. Experiment around with it. 5.oddy's Quest Var Conditions/Effects For this section, we have a special guest, the very creator of these Quest Var Conditions and Effects, oddy. These triggers can be downloaded from the download section of AOMH. Being the creator, he is the best person to describe what these effects do. So, without further adieu, Here's oddy: --Already downloadable effects/conditions-- Effects: --Conditions-- --There are more to come.-- So there you have it. 6. Conclusion So this is the end of my first guide. I hope it helped in your understanding of Quest Variables (and maybe computers in general). If you understand Quest Variables, then the possiblities are vast. You can have anything from inventory systems, to mini-games (like the paper-rock-scissors), to completely random environments. I would like to thank oddy again for keeping me accurate as well as adding section 5. I really recommend you download his triggers and they are very powerful and alow a wide range of creativity. If you have any other questions, feel free to post them. [This message has been edited by DrNick (edited 05-23-2004 @ 11:59 AM).]
With a special thanks to oddy for Section 5.
Parameters: Var Name; This is where you enter the unique name of your variable. Value; This is where you enter the value you want to give your variable.
Example: For the example in Chapter 1. When the player buys the rug, you can create a trigger with the effect: Quest Var Set. Var Name = Has_Rug. Value = 1. This will set the variable named Has_Rug to the value 1.
Parameters: Var Name; The name of the variable whose value you want to modify. Operator; This is the way you want to change your variable. Its a mathematical operator. Value: This is the ammount you want to change by. The formula would be:
Example: I haven't given an example of this yet, but here's a simple one. Say you want to create an RPG where killing a Jarl gives you 500 experience points. You can keep track of how much experience a player has by using a Quest Variable (let's name it Experience). you can set up a condition so that the trigger fires whenever the player kills a Jarl. Then the effect would be: Quest Var Modify. Var Name = Experience. Operator = +. Value = 500. So the formula would be Experience = Experience + 500. No matter what Experience is already, this effect will add 500 to it. You can also use - (subtract), * (multiply), /(devide), and probably % (modulus, though I've never tried it) as operators.
Example: Okay, say the player must win at a game of "Paper, Rock, Scissors" againsed the computer in order to win a donkey (instead of buying it for his list...duh!). The player choses one of the three options and then the computer can randomly chose one of the three options using the following effect: Quest Var Randomize. Var Name = Comp_Answer. Min Value = 1. Max Value = 3. Rounding = On (TRUE). The value will be either 1 (paper), 2 (rock) or 3(scissors). This is just one example, the possibilities are endless.
really saying IF there is a unit in the area, THEN do the effects. Quest Var conditions are no different. In fact, you can really see the correlation better.
value of a Quest Var. For example, if you use the Quest Var MyArmySize and the value of MyArmySize is 8, then 8 units will be deployed. Imagine the possibilities with difficulty settings! If you are using triggers to make the game easier or harder depending on the difficulty, be sure to add some
Quest Var Set to them. With QV Count Army Deploy, you can deploy smaller or larger armies depending on the difficulty! It also comes handy in the case that a player gets an amount of units based on earlier events. And DrNick thinks it would be cool to make a random number of enemies or allies appear like Random encounters!
As you know, the Quest Var Echo effect displays the value of a Quest Var in the left of the screen, like a gaia's chat. These effects let you include the Quest Var value in the text of a Message, a Chat, an Overlay Text, a Fake Counter or a Counter. It works like this: you have a sentence in which you want to include the value of your Quest Var. You split up the sentence in two parts: one before the place where you want the value to be,
and one after that place. The first part comes in the first textbox of the effect, the Quest Var name in the second and the second part in the third.
Example: if MyVar is 6 and your two parts are
Example: if the Quest Var MyResourceAmount has a value of 239, a QV Tribute
with MyResourceAmount will tribute 239 of the selected resource.
Example: We have three Quest Vars: MyMaxRandomVar, MyMinRandomVar and MySupahRandomVar. We use a plain old Quest Var Randomize effect on MyMaxRandomVar and MyMinRandomVar. These two Quest Vars are used in a QV
Randomize with QV effect on MySupahRandomVar. Let's say that MyMaxRandomVar was randomized to 43 and MyMinRandomVar was randomized to 23, the random value of MySupahRandomVar will be between 23 and 43. DrNick says: This could be used in conjunction with say QV Tribute to allow for a random number of tributed resourses, within the limits of how well or poor a player is doing.
these values to start from scratch, i.e. as an objective in midgame, because you don't know how much it was before. For example, if you have an objective "kill 300 guys", the 300 will be the amount of kills since the start of the game and not since the activation of the objective. Until now. With the QV Set Stat Value effect you can store the current value of a Stat Value in a Quest Var. This value is what I like to call it a Point Zero. In following triggers, you don't use the Stat Value condition but the QV Stat Value condition. The QV Stat Value condition needs the name of a Quest Var and uses its value to calculate the amount of the Stat Value requested. Sounds hard? Let's give an example:
Imagine, We still have the objective "kill 300 guys", now not since the game started but since the objective was activated. At the time the objective is activated, we use the QV Set Stat Value effect with a Quest Var called ObjectivePointZero to store the Stat Value "Kills" at the time of activation. Let's assume that when the objective is activated, the player has killed 120 units. ObjectivePointZero will now be 120. We also have a trigger that checks if the objective is completed. This trigger has a QV Stat Value condition. It requests the Stat value "Kills" and an amount of 300. Also, the name of the Point Zero Quest Var, in our case ObjectivePointZero, must be typed in the textbox. The condition now works like this: IF the current Stat Value MINUS the value in the Point Zero Quest Var EQUALS current stat value, the effects will be fired. So, if the players has 120 + 300 = 430 kills, the effects will be fired. Because the 120 is the amount of kills that the player already had when the objective was
activated, 300 is the number of kills since the objective. Tadatada!
purposes. For example: on Easy the Quest Var MyVar is set to 300, on Titan it is set to 1000. So, in the trigger where this is used in, the player must have 300 of the resource on Easy and 1000 on Titan.
a kind of password function. The condition will be true if the player chats the exact Quest Var value (including the floating-point numbers!). For example: if a Quest Var MyPasswordVar is randomized (with rounding OFF) to
1.236784, the condition with MyPasswordVar filled in in the textbox will be true as the selected player chats exactly "1.236784". This can serve as a password: a code for getting units, upgrades or something. It stimulates the
memory of the player (or his blocnote). (Of course, be sure to display the Quest Var value with a nice effect!)
Your flashes of merriment, that were wont to set the table on a roar?
Not one now, to mock your own grinning?