Global variables. Local variables.
If you have read the second workshop (the one that talks about variables) you might wonder why we haven't covered global and local variables there and then. Are these concepts so difficult to understand for a beginner?
Fear not, for you have used global variables all this time without even knowing it. I needed to explain actions and functions first, because we need them in order to understand how local variables work. Let's fire up an example; start WED, load work23.wmp and run it using script23.wdl:
It looks like a post-apocalyptic version of our planet indeed! I have used a cube textured with black for the level and I have placed the sphere model inside it; that's why you can't see the level boundaries.
Now that's what I would call a nice script file! The sphere model changes its pan angle by adding "2 * time_step" to it every frame, because "rotation_speed" is set to 2. This is, as you might have guessed, a "global" variable, a variable that is defined outside any action or function. Like I said, we have defined only global variables in all the previous workshops without even knowing it! Now run the level again, press "Tab" to show the console and type in the following line of code:
rotation_speed = 5;
The sphere rotates faster now, right? We can control the rotation speed using the console because the variable named "rotation_speed" is known to each and every function or action, including the built-in engine function that displays the console. That's how a "global" variable works!
A "local" variable is known only inside the action or function that includes its definition. Let's turn our global variable into a "local" variable; move the line that defines "rotation_speed" inside the action named "mother_earth":
Now let's run the script file again:
The planet rotates just like before; let's type the same line that changes the speed at the console:
rotation_speed = 5;
This time the rotation speed hasn't changed at all! The console function doesn't know the variable, because "rotation_speed" is now a local variable, so it is known only inside the action named "mother_earth". If I would put a line that sets a new "rotation_speed" value inside function "main":
the engine would display an error message, because function "main" doesn't know the local variable that was defined inside the action named "mother_earth":
Let's build another example that uses local variables; copy and paste the following lines of code at the end of the script file:
action mother_earth2
{
var rotation_speed = 5;
while (1)
{
my.pan += rotation_speed * time_step;
wait (1);
}
}
And here's how the resulting script file should look like:
Now add another sphere model to the level and attach it the "mother_earth2" action. Take a look at the shot below to see the approximate position of the second model in WED:
Save the level, build it and run it:
We have got 2 rotating spheres now, and each one of them uses a different rotation speed. That's how it should be, because we have defined a local variable named rotation_speed (set to 2) inside the action "mother_earth" and a local variable named... ahem... rotation_speed (set to 5) inside the action named "mother_earth2"! We have defined two variables with the same name, and yet they do provide different rotation speeds for the two planet models, because they are local variables. What other proof could you want? These local variables don't interfere with each other at all, even when they have the same name!
Now don't get me wrong, I like global variables too! They are necessary whenever some data must be available for every action or function! Want to have all the monsters in your game do a little dance when the player dies? Then you'd better make player's health a global variable, because the monsters will want to check its value from within their own actions or functions! On the other hand, you will want to use local variables for all the instructions that only take place inside a function or action: animation, movement, and so on.