Variables
I know, the first example didn't do much, but if you got it to work, you got to see how easy TGE scripting really can be. As I learn more, these tutorials will go all the way with me, but time is a luxury few can afford, so there are no promises when each one will be done.
Besides just providing output, our program must also be able to receive input. The first level of input are application
arguments. When you run demo, it already has 1 argument, the name of the application. However, what if
you wanted to provide more command line arguments? Right now our script would ignore them and just run. What we need is a
way to read those arguments, and based on their content, perform different tasks.
Arguments are passed to our script as predefined variables: argc is the number of arguments, always at least 1,
and the array of arguments themselves, argv[].
A variable is a placehold for a value. For example, in the equation x + 2 = 5, x is equal to 3. That makes
the letter x a placeholder for the value 3. Variables in programming work the same way, they are used as placeholders for
values, however, those values can change. That's why they are called variables.
If you want to store many varibles, you could give each one a name, such as x, y, z, and so on. However, for a list of
variables, there is an easier way. It is called an array. An array is a collection of variables, kept track of through an
index. The argv[] variable is a list of strings passed to our program and can be 1, 2, or 20 different arguments.
To access each individual argument, you use the index to specify which one of the list you are referring to, for example
argv[0] is the first argument passed to our script, the filename of the program. All arrays are 0 based so the
index for the first item is 0.
When naming your variables, you want them to have descriptive names so when you see them in the middle of a function you can be
sure what their purpose is. You also don't want to get carried away with super long names, because you'll have to type them
over and again, and if you mistype it, it can be hard to find the problem. The variable ammoQty for example
is a lot more descriptive than just the letter a, and a lot easier to type than ammunitionQuantity.
When we use variables, they have what's known as a scope. This means what area of our script they are valid in. Every variable requires a place in memory to store its value, and if all our variables were always in memory, we would use a lot more memory than we need to. Very often a variable is only needed for a short period of time, then it is no longer necessary so it would be wasteful to keep it in memory when it is not needed. To identify a variable's scope you prefix the name with a $ or %. The dollar sign indicates the variable is global, or available in every part of the program. The percent sign indicates a local scope, a variable that exists only within the current function, and then no longer exists when the function is done.
As programs get larger and larger, it becomes harder and harder to come up with new, meaningful names for our variables, so
that's where namespaces come in. A namespace helps uniquely identify our variable and where it comes from. In addition to the
variable name, it also has a namespace name. Namespaces are separated from variable names with a double colon. They allow us
to use the same name for two different things, such as $Player::ammoQty and $MountedMG::ammoQty. In
this example we can identify the quantity of ammo the player is carrying, and the quantity in the mounted machine gun.
Arguments passed to the game from the console are in the Game namespace and have global scope. Therefore, they are addressed
as $Game::argc and $Game::argv[].
// main.cs 7 APR 05
function onExit() {
}
enableWinConsole(true);
echo($Game::argv[0]);
quit();
This script is very similar to our first one, however, instead of displaying a literal string that we typed in when we created the script, it is using the variable placeholder to identify what program we are running.
When programming, even scripting, it is a good idea to isolate processes. This not only helps you focus your attention on the task at hand, but helps isolate any issues that may arise. For example, if we create a new function and by calling that function our program stops, we can easily comment out the call to the function and test to see if the problem is only in the function.
The first thing to do is to declare your function. Then you can enter your statements and call the function. Compare the following example to the previous one.
// main.cs 7 APR 05
function onExit() {
}
function parseArgs() {
echo($Game::argv[0]);
}
enableWinConsole(true);
parseArgs();
quit();
Now the function is a little longer, but if there is a problem with the parseArgs function, we can simply add double slashes before the function call to prevent it from running, helping us isloate our problem. Later, when we expand on the function it will become much more apparent why it is far better to call it as a function than inline.
When we run our game, as it gets to the parseArgs(); line, it calls the function, performing the same statement
call as the previous example, and we get the same results.
