GameMaker Cookbook: Over 50 hands-on recipes to help you build exhilarating games using the robust GameMaker system

Let's make a player character sprite with a simple walk cycle. If you haven't already, now would be a good time to open GameMaker, start a new project, and create a sprite. Name the sprite spr_player_walk.

As mentioned before, you can use 3rd party art programs to create your own sprites and import them to GameMaker. If you're more interested in just making something that moves, I've included the files necessary to create an animated sprite; simply load them from sprite properties and you're almost good to go.

With that out of the way, let's look at using GameMaker's built-in Sprite Editor.

The Image Editor comes with another feature that is great for animating your sprites: Onion Skin. Onion Skin allows you to, while working on one frame of an animation, view the following and preceding frames. You can set how many frames you want visible, both backwards and forwards, and use the Onion Skin value to change the opacity of those frames to alter their visibility while working. This can help you paint each form and make the animation more fluid because you can see where you've been and where you're going. A useful addition to this is the Scratch Page. Simply hit the J key to be taken to and from a frame that doesn't actually exist in your animation, but allows you to cut and paste image elements. It's a big help when you want to move separate pieces of an image from one frame to another.

There you have it; you've animated a sprite for use in a game. That's a great first step, but we're not finished. If you use this sprite on your character it will appear as though he's walking at all times. I don't know about you, but that's not what I want to see in a game. You could animate an idle sprite, which is ideal for a polished look, but we're going to speed this up by using a single-frame idle pose.

Done. You now have a second sprite for a single character.

As we've just seen, it's possible to create fully animated characters without the use of a 3rd party program. While other programs give you many more options not found in GameMaker, such as layers, you still have access to the fundamentals you need to get the job done. The editor is great for pixel art and Onion Skin makes animating a lot smoother by showing you adjacent frames.

Now, we've only made sprites for two states of our character's being: idle and walking right. There are many other sprites you may want to consider if you're looking to build a full game. Think about other games you've played; how many different movements and poses do they incorporate? Walking, running, jumping, rolling, punching, shooting, and so on, you get the idea. When designing a game, any actions you intend for your player character should be listed and planned out because you need to consider just how many sprites you'll need. Will they be animated? Will they look different depending on what direction the player is facing, or can they be mirrored? How long will it take for the animation to play out? These are all important questions, but they get easier to answer with each game you make.

Sprites used for GUI will be discussed in Chapter 6, It's All GUI! – Creating Graphical User Interface and Menus, while sprite-based VFX are used in Chapter 9, Particle Man, Particle Man – Adding Polish to Your Game with Visual Effects and Particles.

You've animated some sprites, but animated sprites won't do you any good without a character to which they can be applied. Create a new object and call it obj_player. Under Sprite, click the menu icon and select spr_player_idle.

The movement discussed in this section is quite simple. In this case, you've instructed GameMaker to make your character move left or right and play the walk animation (facing the proper direction) as he goes. Using jump to position allows you to move a character to any point in the screen or, as you did here, move the character relative to its current position, adding the entered values to existing coordinates. Using a negative value would subtract from the current coordinates, causing the character to move in the opposite direction. If you want your character to move up or down you would change the value of y and leave x as 0. I encourage you to play around with the values entered, as this will change the player's speed.

It might seem like this section had a lot of text to set up very simple movement, but I can assure you it is all necessary. This section and the rest of the chapter set up some core ideas that will recur throughout your GameMaker experience and will be explored much further later on.

Several methods of advanced player movement and controls will be demonstrated in Chapter 2, It's Under Control – Exploring Various Control Schemes, and Chapter 3, Let's Move It – Advanced Movement and Layout.

We want to create a projectile at our character's location whenever the player hits the Spacebar. On creation of the projectile, we want GameMaker to verify the direction the player is facing and send it flying in that direction. Before GameMaker can check the direction, though, we need to create a variable that tells GameMaker which direction the object is actually facing. It sounds convoluted but in execution it's really fairly simple, so let's begin.

There's one last thing we should look at, here, and that's how often our player character can shoot. As it is right now he can shoot every time the Spacebar is pressed. Imagine our character is holding a handgun. Now think about how quickly the player could potentially press the Spacebar, over and over. I don't know about you but I imagine a handgun that can shoot that fast must be magical; maybe a wizard made it. There is a way around this magical handgun made by wizards, and that way involves alarms and variables.

Congratulations! You now have a player that can shoot projectiles in the direction he is facing and do so at a realistic rate. This outcome is much more appealing than having a player who fires his gun wherever he pleases at incredible rates. You're a loose cannon, player!

In order to make your character shoot projectiles, we've had to use several important elements of programming with GameMaker, namely variables and alarms. When the Spacebar is hit, GameMaker first has to check whether or not the variable shoot is equal to 1. If not, nothing happens. You could hit the spacebar as many times as you want, but unless shoot equals 1, you'll get nothing out of it. Now, assuming shoot does equal 1, GameMaker moves on to create a projectile in the same place as the player, which is (0, 0) relative to wherever the player object is sitting. If you want the projectile to be created near the player, say to give the appearance that the projectile is coming out of a gun, you could change the coordinate values for (x, y).

At the same time, GameMaker is setting shoot to 0 to prevent the player from shooting again right away, and setting an alarm to 30 steps. At the end of those 30 steps, shoot is set back to 1. Each step is the same as one frame in-game, meaning if the game is running at 60 frames per second, the player can fire every half-second.

Once the projectile is created, GameMaker is testing another variable we set: dir. This is simply to tell GameMaker in which direction the player is facing and GameMaker then sends the projectile off in that direction. Bam. Projectiles. No pun intended.

Projectiles will be expanded on in Chapter 9, Particle Man, Particle Man – Adding Polish to Your Game with Visual Effects and Particles.

In-game hazards can come in many forms and various visual styles. Like the projectiles we discussed previously they can be static images, but they look much better as animated sprites. We're going to build a spike trap; you can use your own art, but I've included an animated sprite in the downloadable files.

Once you save your selections we're ready to get started.

Got all that? It's a lot to do all at once, but we'll go through what it does, step by step. The good news is that you now have a spike trap that springs when touched by the player and stays sprung for a bit before retracting. There's a good reason behind this that we'll explore a little further once we get into player health.

The trap you've just made uses collision detection and alarms to set and reset variables that control the trap's state. On creation, GameMaker sets the image_speed to 0, keeping the animation on the 1st frame, and establishes the variable trap_set, which will only be used by this particular instance of the spike trap. Think of trap_set as a sort of on/off switch, using binary (0 or 1) to dictate its current state. When the player collides with the trap, GameMaker checks whether or not the trap is on. If trap_set is equal to 1 (on), GameMaker proceeds to set image_speed to 1 (so the animation will begin to play), set Alarm 0 to 60 steps, and reset trap_set to 0 so that the spike trap will not be activated over and over again. This is to give the player a chance to move away from the trap to avoid being injured a second time. The Step Event checks every single step to see whether or not the sprite's animation has advanced to frame number 4. If it has, it then checks whether or not Alarm 0 is still counting down. If it is, image_speed is set to 0, so that the animation remains on the 4th frame (in the up position) until Alarm 0 is finished counting down. When it has, the image_speed is set back to 1, allowing the animation to continue, and Alarm 1 is set to 30 steps. The animation can continue (retracting the spikes) but once it reaches the last frame, the Animation End event then sets image_speed to 0 again, preventing the animation from looping. The last thing to happen in this long list of events is the end of Alarm 1, which simply gives trap_set a value of 1, thereby resetting the trap to be used again.

It's a lot to take in at once, but creating this trap is a great demonstration of the programming logic we're going to get into later on. For now, enjoy your new spike trap!

As with everything we've done so far in this chapter, you'll need sprites to represent your enemy. You can make your own or you can use the one included in the downloaded files. It's acceptable to use the same sprite for different types of enemies but, from a game design perspective, it's a good idea to differentiate. This will make it easier for your player to identify the enemy types and react accordingly.

Create a sprite and name it spr_enemy_patrol. Load the associated images from the files provided, or create your own, and be sure to set up the collision mask.

You now have exactly half of the actions required for a patrolling enemy. At this point you can do one of two things: You could copy this entire set of actions, paste the copies directly below the existing actions, and go about changing the variables to their exact opposites, or you could drag and drop new blocks in the same order, but set the variables to their opposites. The former is much faster, but the latter will help you learn more about programming logic. In any respect, your Actions box should look like this:

While this Step event contains a lot of actions, it is really doing something quite simple. GameMaker is checking, every game step, for the patrolling enemy's state and position. If headed left and his position on the room's x coordinate is more than 16, he'll continue on in that direction. Once he gets past this point, GameMaker switches his direction, flips the sprite and sends him off to the other side of the room until his x coordinate reaches the room width minus 16 pixels, rinse and repeat.

This method of creating a patrolling enemy is a simple enough way to move your enemy in a set space. I chose to have him walk right across the entire room, but you could also have him walk within a smaller space. Another way to accomplish this is to create left and right boxes, remove their visibility by unchecking the Visible box in Object Properties, and placing them at either end of the area you want patrolled. In the enemy's properties, instead of having everything in the Step event, you can control when they change direction by when they collide with the invisible boxes. The same actions would apply; they would just be executed in a different way. This just goes to show you that there are many possible solutions to all of the problems you may encounter when making games; you just have to find them.

Paths will be discussed in Chapter 4, Let's Get Physical – Using GameMaker's Physics System.

Since this recipe involves making additions to your existing player character, you don't need to do much. You'll need a sprite to indicate your player's lives (call it spr_life) but other than that all you need to do now is open the obj_player Object Properties window.

Health and lives are very straightforward, with GameMaker doing a lot of the work for you when using the drag and drop actions. Essentially, GameMaker has created the variable health and you've set it to a value of 100. You've also created the variable hit, which you use to control when you can be injured. If hit is set to 0 (off) then you can be hit by an enemy or hazard. If you are hit by one of them you lose 20 health points and the variable hit is set to 1. This is to prevent contact with an enemy continuously draining your health, as it is being checked every step. An alarm is set to 60 steps and at the end of that countdown hit is set back to 0, meaning you can be injured once more.

The Step event is also constantly checking for when your health reaches 0. When it does, the lives variable is decreased by 1 and your health is reset to 100.

In this case we set the health bar to a specific coordinate relative to the player's position. This was purely a design choice to show you that you have options. You can set the health bar to a static position on the screen, much like we did for the lives indicator. As for the lives indicator, using the Draw Lives action instead of Draw Life Images allows you to indicate the player's remaining lives with text and numbers.

This recipe does not involve any new sprites or other assets but does require a new object. Call the object obj_score and leave the sprite box blank.

GameMaker is again doing a lot of the heavy lifting, here. You created obj_score to keep track of scoring. Not assigning a sprite to it will allow the object to be in a room, affecting the game, without being seen. The rest of the recipe is simply placing the score counter as a GUI element, checking for collisions between projectile and enemy, and adding points and destroying the two when they collide.

In this recipe, obj_score acted as what's referred to as a controller object. These objects are often invisible and control specific aspects of the game. Since an object needs to be active in order for its actions and variables to be used, any aspect of the game that needs to be present without interruption should be assigned to a controller. I use controllers for music, HUD, global variables, and more.

Most chapters going forward will deal with controllers and their various functions.

This recipe, again, does not necessitate new sprites or even objects. We'll be relying on existing objects but we'll be adding some new variables. Start by opening the Object Properties for obj_player.

As you may have guessed by the names of the actions, you are simply asking GameMaker to check the values of score and lives, and restarting the game when they reach a certain point. In previous recipes you set the score to increase by 10 whenever you shot an enemy. If you shoot 10 enemies, the game will restart. You set the lives variable to 3 but had it decrease by 1 every time your health reached 0. Once you have no lives left, the game restarts.

Using Game Restart in this scenario is arbitrary; it is simply there to demonstrate that you can tell GameMaker to change the game's state based on your score, health, or number of lives. Under the Main1 tab in Object Properties you can find actions that take you to other rooms you may have created. This can be used to go from one level to another.

The Chapter 6, It's All GUI! – Creating Graphical User Interface and Menus, deals with more advanced GUI and Chapter 7, Saving the Day – Saving Game Data, covers save systems and leaderboards.