GML: From Ninja to Pirate - The Game Maker's Companion: Game Development - page 256

The Power of Language

A direct translation of D&D to GML is a bit like watching a mimed performance and then
wr i ti n g down wha t ha ppe n e d. T he r e sul t mi g ht be a r ti cul a te d i n a di ffe r e n t for m, but i t ca n ' t
express anything more than the original. The power of GML is in its ability to “say” things that
you simply can't in D&D. Our next task then is to take advantage of some of GML's additional
power by making some improvements to our Zool code. This code will form the basis of our
Pirate game too, so we're improving them both at the same time.

A Global Evil
Global variables are accessible to all objects in your games, and as such provide one way of
sharing or passing information between them. However, generally speaking, global variables
are considered particularly bad practice in most programming languages.
One of the great advantages of programming using objects (as in Game Maker) is that it
keeps different parts of your code nicely separated from each other. It is easy to consider objects
in relative isolation, and changing a piece of code in one object doesn't necessarily have any
knock-on effects on other objects. The problem with using global variables is that they often
have the opposite effect. They can create unnecessary links between objects that make it
impossible to change one without affecting another (because they all make use of the same
global variable). Changes in one area of code can easily have unintended effects on other parts
of the game, leading to more errors and less reliable code. Global variables are therefore
something you should try and use sparingly in your games, and we will attempt to address this
in our GML version of the game next.
There was one use of a global variable in our original version of Zool, which is probably
acceptable, and this was when we used it to create a global.step_count variable that kept track
of the number of steps since the start of the game. Even so, this relies on an understanding that
only the controller object should ever change this variable, and other objects should only ever
get the value of it—otherwise, it could cause problems too.
On the other hand, there was another use of a global variable that was both ugly and no
longer necessary in GML. This was where we used one to pass through the sprite of the dying
enemy object, and this can now be removed.
For the following sections, you'll need to open two Game Maker files: zooldrag.gmk (which
should already be open) and zoolgml.gmk , which is also in the Chapter11/Games directory on the
CD. Launch Game Maker again (so that it is running twice) and open the new file as well. Refer
to the headings before each set of instructions to tell you which file we're currently looking at.

Within zooldrag.gmk
1. Open up obj_beastie and select its Destroy event. Double-click on its Execute Code
action and notice the following lines within the code:
global.die_sprite_index = spr_beastie_die;
event_inherited();

This is the event called when the Beastie is killed and you can see that it sets up the
global variable so that it contains the Beastie dying sprite and then calls the Destroy
event of its parent ( obj_enemy ). So let's look at its parent's Destroy event next.

2.

Open up obj_enemy and select its Destroy event. Double-click on its Execute Code
action and find the following lines within the code: