But you, as a scenario designer for AoM, 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.000000 (or so), etc. So the main thing 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 scenario designing, only worry about the decimal point numbers. You must always be careful in naming your quest var randomize effect. Think of a short, simple name. Remember that you have to re-type this same name in the other triggers containing the quest var check condition or other. Depending on the minimum value and maximum value, a certain amount of objects will randomize. So, for example, if I want to randomize 3 settlements, I would have to put Min Value=1, and Max Value=3. Example: Trigger_1: Trigger_2: Trigger_3: In the Example illustrated above, the Main trigger(quest var randomize) has three choices, and will only choose one of the 3 other trigger. Each trigger that has "condition Quest Var Check" which represents a value in the Quest Var randomize effect because of the number written in the Quest Var check Value Box. The reason why I typed "Main" in the name box, is because "Main" is the name of the "Quest Var Randomize" effect that will decide which value to randomize. The reason why you are using Quest Var Check as a condition is because this condition will fire the desired Value you typed. Its similar to a Fire Event effect; however, instead of activating a trigger, it gets activated by the quest var randomize and causes the value to take effect. Remember that you must type the desired amount of values in the Quest Var Randomize effect. If you type a value in a quest var check condition that is not defined in the quest var randomize, nothing will happen because the value is not registered. Keep in mind that this condition can be used and set with the Quest Var Set, Quest Var Modify, and trigger effects as well. Be careful when typing a value number for each quest var check. As you can see, each trigger above has different numbers in the quest var check box. If you put the same number in two different quest var check box, then the quest var randomize effect will choose one of the two triggers to randomize, and the other one will be deactivated. You can also add an extra value so that the main trigger has the possibility of not randomizing any of the other values written in the quest var check. Variables: Greater Than or Equal to(=> ): You would use this variable to check the same value and other greater values Less Than or Equal to( Greater Than(> ): You would use this to check ONLY greater values than the typed value Less Than( Equal to(==): You would want to use this value if you want to check one value. but you can just use the equal variable if you only want one trigger to randomize If you couldn’t manage to work this trigger out, do not worry. It takes some time to understand and it is for sure you wont get it right away(depending on your experience with the editor). Make sure the values are set correctly, as well as the variables. Always make sure the trigger itself is not accidentally looped, activated or run immediately by mistake. [This message has been edited by Papaya (edited 02-25-2006 @ 11:42 AM).]
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 (never ask why!). The list has four different items: a rug, a house, a fish and a donkey. These items can be bought in any order. This is entirely possible (I've done it). How would you keep track of which items the player has and which still need to be bought? This is where variables come into play.
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 name.
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: Has_Rug, Has_House, Has_Donkey and Has_Fish are the ones I will use.
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.
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.
This is pretty self explanatory. This is where you can directly set the value of your variable (or create it with a default value).
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.
This allows you to change the value of your variable by using an operator. This may seem confusing at first, but its not that difficult.
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 amount you want to change by. The formula would be: Var Name = Var Name Operator Value.
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), /(divide), and probably % (modulus, though I've never tried it) as operators.
This trigger is exactly the same as Quest Var Modify, except instead of using a value for the third parameter, you use another Quest Variable. That way you don't need to know how much to change the first Quest Variable when you create the scenario. The formula this creates is: Var Name = Var Name Operator Var Name2. So for the example from Quest Var Modify: Experience = Experience + Jarl_Experience. That way, Jarls don't have to always give 500 experience, they could give a variable amount that you determine.
Quest var randomize does not randomize objects as a random map script. A random map script can randomize all objects in whatever place possible(depending on the .xs document of course), Unlike a quest var randomize effect which needs a quest var check to define the location where the object(s) has to be randomize. The first thing you have to know is that In order to randomize an object successfully, you must create the main trigger called "Quest Var Randomize". Quest Var Randomize is an effect which randomizes values. All variables(Ex: Min=1 Max=5) defined are valid values and can be randomize. This can pretty much be use with any quest var. Example: Trigger_Main: Active
Effect: Quest Var randomized(name: Main)<
Condition: AlwaysTrigger_Main: Active
Effect: Quest var randomized<
Condition: Always
Effect: Change unit type<
Condition: Quest Var check<
Effect: Change unit type<
Condition: Quest Var check<
Effect: Change unit type<
Condition: Quest Var check<
There are only two conditions that I will go over for Quest Variables. These are really where Variables show their usefulness. 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
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.
Okay, so you want to know IF the person bought the rug. Quest Var Check is the condition for you. Remember that IF the variable Has_Rug = 1, THEN they have the rug. IF the variable Has_Rug = 0, THEN they don't. This can be almost directly translated to the Quest Var Check condition like this: Condition: Quest Var Check. Var Name = Has_Rug, Operator = ==, Value = 1. Unless you want to know more about other kinds of programming, just accept that == means "is equal to" as in: IF Has_Rug is equal to 1. There are also several other operators that you can experiment with. So the opposite would be IF Has_Rug == 0, or Or you can even just check the "Not" box as in IF Has_Rug NOT == 1 THEN. It may not be good English, but I'm sure you get the idea.
This is the same as Quest Var Check except instead of comparing one quest var and one value, you're comparing two quest variables. The formula looks like this: IF Var Name1Operator Var Name2 THEN... So in our Paper, Rock, Scissors example, We want to know if its a tie (Both the player and the computer picked the same answer). So it would look like this: IF Player_Answer is equal to Computer_Answer THEN its a tie. So lets put the pieces into their correct Parameters: Var Name1 = Player_Answer, Operator = ==, Var Name2 = Computer_Answer. THEN (its a tie so do the necessary effects for a tie).
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.
If you understand Quest Variables, then the possibilities are vast. You can have anything from inventory systems, to mini-games (like the paper-rock-scissors), to completely random environments.
oh you can wait for what I can give
you know what I am so you know how I live
try to look proud but you’re not in the slightest
its happening now and it’s always been like this.