Introduction

One thing that is missing in the Pawn programming language is classes and encapsulation. If you want a variable’s value to persist (i.e. stay the same) throughout function calls there’s one immediately obvious way to do so. The most common and obvious way is to make the variable global which is fine for smaller scripts. However this method becomes problematic and difficult to maintain in larger scripts due to:

• Naming clashes if trying to use more simple variable names
• Overcomplicated variable names in attempts to prevent variable clashes
• Out of context variable declarations and unauthorized editing of variables

These problems stem from the number of variables increasing substantially and variables are declared out of visual range from where they are used. Frequent use of global variables can lead an individual and even a team being very quickly overwhelmed.

During this write up I will most likely brush over a few non-important definitions. It is expected that you can learn about these terms by searching the internet or prior knowledge. If however, you still cannot understand the definitions you’ve found then feel free to leave a comment saying so.

Static

An alternative way to make variable value persistent is to use the static keyword. Use of the static keyword puts your variable in the heap as opposed to the stack. The heap is a space of memory that used by the compiler to put your global variables.

During the compilation process static variable declarations are put on the heap. Any reference to that variable in the same scope is translated to a memory address. This can mean that memory usage can increase if you overuse it. Memory increases as you technically have more global variables instead of the compiler determining a stack based on the largest predicted stack frame and dynamically adding/removing data from that.

Making use of variable scope is a very important technique to prevent your script from being too overwhelming. Scope is simply whether or not you can view a variable from another place, or another context.  It allows us to hide information that is unnecessary to another context in the script. For example, you might have a checkpoint system that doesn’t need to know if the player is on the pirate ship.

Rules of the Pawn language tell us that we cannot declare a variable with the same name more than once in the same scope. This is to prevent ambiguity about what the variable actually means and what data it refers to.

It is also worth noting that files are of a different scope when using the static keyword. This is useful if you split your game mode into several modules each contained in their own file.

Example

Now we will have a look into a piece of code that uses global variables. I have made the variable names simple to highlight the point. However, this exaggeration does not dismiss the point and shorter names allow for a shorter amount of keystrokes when referring to the variable:

// These values will only be set ONCE since they're global
new
	// The last time an update occured in this
	// scope
	g_iLastUpdate = 0,

	// The X, Y, Z positions of the
	// camera and the initial values.
	Float: fCameraX = 2010.0	,
	Float: fCameraY = 1500.0	,
	Float: fCameraZ = 50.0		,

	// The X, Y difference to add on between
	// updates
	Float: fDeltaY	= 0.25		,
	Float: fDeltaX	= 0.5		;

/*
	The several thousand lines in between until you actually reach this method within
	your source code.
*/

public OnPlayerUpdate(iPlayerID) {
	// If the player is not logged in or they haven't read the rules
	// then we'll try update the camera.
	if (!Player_IsLoggedIn(iPlayerID) || !Player_IsReadingRules(iPlayerID)) {
		// This variable will be set EVERYTIME the
		// script reaches this point.
		new
			iCurrentTickCount  = GetTickCount();

		// Check if the difference between the last update and the
		// new update is 50 msec.
		if ((iCurrentTickCount - g_iLastUpdate) > 50) {
			// Some logic to take care of the differences in
			// camera positions
			if (fCameraX > 2150.0 || fCameraX < 1850.0) {
				// fDeltaX is static, so it will keep it's value the next
				// time this function is called.
				fDeltaX = -fDeltaX;
			}

			// Some logic to take care of the differences in
			// camera positions
			if (fCameraY > 1600.0 || fCameraY < 1400.0) {
				// fDeltaY is static, so it will keep it's value the next
				// time this function is called.
				fDeltaY = -fDeltaY;
			}

			// Update the X, Y co-ordinates of the camera
			fCameraX += (fDeltaX * 1.1);
			fCameraY += (fDeltaY * 1.1);

			// Set the updating players information so that the camera
			// updates.
			SetPlayerPos(iPlayerID, 2109.0, 1456.75, 30.0);
			SetPlayerCameraPos(iPlayerID, fCameraX, fCameraY, fCameraZ);
			SetPlayerCameraLookAt(iPlayerID, 1980.0, 1535.0, 13.5);

			// Set the last update to the current tick count
			g_iLastUpdate = iCurrentTickCount;
		}
	}

	return 1;
}

Now imagine there’s actually several thousand lines of code between those variable declarations and that callback. You have to admit that it would be very tough to ensure the integrity of those simple variables and also annoying to ensure they do not clash with other variable names. Instead of using this method we can use an alternative method which makes use of the static keyword:

public OnPlayerUpdate(iPlayerID) {
	// If the player is not logged in or they haven't read the rules
	// then we'll try update the camera.
	if (!Player_IsLoggedIn(iPlayerID) || !Player_IsReadingRules(iPlayerID)) {
		// This variable will be set EVERYTIME the
		// script reaches this point.
		new
			iCurrentTickCount  = GetTickCount();

		// These values will only be set ONCE by
		// the compiler and dumped somewhere in
		// memory.
		static
			// The last time an update occured in this
			// scope
			s_iLastUpdate = 0,

			// The X, Y, Z positions of the
			// camera and the initial values.
			Float: fCameraX = 2010.0	,
			Float: fCameraY = 1500.0	,
			Float: fCameraZ = 50.0		,

			// The X, Y difference to add on between
			// updates
			Float: fDeltaY	= 0.25		,
			Float: fDeltaX	= 0.5		;

		// Check if the difference between the last update and the
		// new update is 50 msec.
		if ((iCurrentTickCount - s_iLastUpdate) > 50) {
			// Some logic to take care of the differences in
			// camera positions
			if (fCameraX > 2150.0 || fCameraX < 1850.0) {
				// fDeltaX is static, so it will keep it's value the next
				// time this function is called.
				fDeltaX = -fDeltaX;
			}

			// Some logic to take care of the differences in
			// camera positions
			if (fCameraY > 1600.0 || fCameraY < 1400.0) {
				// fDeltaY is static, so it will keep it's value the next
				// time this function is called.
				fDeltaY = -fDeltaY;
			}

			// Update the X, Y co-ordinates of the camera
			fCameraX += (fDeltaX * 1.1);
			fCameraY += (fDeltaY * 1.1);

			// Set the updating players information so that the camera
			// updates.
			SetPlayerPos(iPlayerID, 2109.0, 1456.75, 30.0);
			SetPlayerCameraPos(iPlayerID, fCameraX, fCameraY, fCameraZ);
			SetPlayerCameraLookAt(iPlayerID, 1980.0, 1535.0, 13.5);

			// Set the last update to the current tick count
			s_iLastUpdate = iCurrentTickCount;
		}
	}

	return 1;
}

If you read the comments you can see what is happening in this piece of code. This code is using the static keywords and due to their scope the variable names are not required to be extra specific. The meaning of the variables such as fCameraX, fCameraY and fCameraZ can be picked up quite easily as they’re only used within that short piece of code. If the variables had been declared at a higher level than shown then the meaning would become less obvious. The code would have had to have been investigated to make sure there were no side-effects from reading or writing to the variables.

Conclusion

Hopefully after reading this you can appreciate the static keyword and its uses. Here is a quick summary of the topic discussed in this write-up:

• You can use the static keyword to hide variable information from unrelated modules in your code
• Data will persist throughout function calls which means that global variables are not always necessary
• Keep your code simple a programmer can only remember so much at once. You should limit the amount of information so that carelessness will not cause script breaking bugs
• Hide the information from areas it is not necessary

I hope that I have opened your eyes up to a few ways to take advantage of the static keyword. Remember not to overuse it if it’s not necessary, you may increase memory usage or cause unintended side effects.