An event in game design is a something that is triggered when a series of conditions is met. An event will only occur when all of those conditions are true. A series of commands are usually bound to an event, to be carried out when it triggers. These things together make up an event script. It consists of one or more conditional statements, called the trigger, and a series of commands to carry out if the trigger is fired.
Event scripts are what makes great games great. Without them, you cannot make truly interesting and engaging games. The construction of an event script requires a profound understanding of what you want the object to do.
Every event must have a trigger. There are two common types of triggers: the key press trigger and the collision trigger. A key press trigger, as you may have guessed, requires a key press. A collision trigger fires when a collision detection to return positive. Some triggers require both a key press and a collision in order to execute. Some triggers require multiple events. While some people may be more comfortable with nesting conditionals (placing one conditional inside another), there is a much more efficient method of testing the truth of multiple conditionals, in a single if-then statement or even without one entirely. Suppose you wanted to have the value of A increment by three if A is negative or decrement by 3 if A is positive. You could write this:
:If A<0 :A-3→A :If A>0 :A+3→A
Or you could use this, which does exactly the same thing:
:A+3(A<0)-3(A>0)→A
This comes from the fact that an equality (or inequality) returns 1 if true and 0 otherwise.
Apart from sprites and events, collision is one of the most crucial elements of game design. In most challenging games, especially those with hits and attacking and defending, the game would not be the same without collision. As such, collision is one of the more difficult concepts (as if the rest of this tutorial isn’t). Here are the two easiest methods of achieving a collision detect.
The first method involves the variables assigned to represent the positions of the two sprites between which we are testing for a collision. In this method, you compare the X value of the first sprite to that of the second, then the Y values of the two sprites in much the same manner, through the use of conditional statements. If both the X and Y values coincide, there had to have been a collision. Provided that sprite 1 is located at (A, B) and sprite 2 at (C, D), the conditional statement A=C and B=D would work. You could place parentheses around the A=C and B=D, but they are not required and waste both time and memory.
The second method involves the use of the pxl-Test( command. In this command, you are required to specify what pixel you want to test. The pxl-Test( command returns 1 if the pixel is on and 0 if it is off. Assuming that one sprite is in motion and the other is stationary, you can use pxl-Test( to check the pixels ahead of the moving sprite.
In most games, these two topics are combined to help form the graphical interface. Usually, the flow of events within a game is as follows. Usually, a user-controlled sprite is moving about the screen, or launching some sort of attack. When this attack is completed, or two sprites collide, the program triggers an event, and delivers control of the game to an event script, which executes its instructions, before terminating and restoring control to the user-controlled sprite. Event scripts may be in-game or external subroutines. There are pros and cons to both. Having your event scripts in-game increases the size of your game, thus making it more demanding on your calculator’s memory. However, having them externalized makes your game unstable in the event of a crash, as some of these routines may be lost. In the end, it all comes down to a matter of preference.
