Building Games with Scratch 2.0

Scratch comes with dozens of useful graphics that you can use as a starting point. We'll import the image of a ball from the library, and add a behavior to it.

In a paddle-based arcade game, we expect certain things. The ball should bounce off the paddle, and missing the ball should make something bad happen. Here's where our project starts to look like a game.

Bouncing a ball on an empty screen isn't fun for long. In this section, we'll give the player targets.

It's tedious to create individual items and arrange them on the playing field. We can automate the process using the "Clone" and “Repeat” blocks.

We'll keep score, and end the game with an appropriate message when the playing field is clear.

To build a catch and avoid game, we need to start with controlling the player. If you have completed section 1, you'll end up with the start of a catch and avoid game, so some part of the next few minutes will be a review.

Now that we can control the horizontal position of our character, we need to provide the player with a reason to move around. We'll add a treasure to collect and a threat to avoid.

Now that we have the most important parts of the game working, we need to keep a track of their interaction in order to create rewards and penalties. For instance, you win the game after collecting ten fruits, but you die if you touch ten donuts.

Visually, our game is a little monotonous - the same apple and donut, over and over again. There's a very simple way to add variety -- reskin our sprites with different costumes.

The game works, but how can we make it more engaging for the user? Switching to a mouse makes the game easier to win but less fun to play; controlling the avatar by gesturing in front of a webcam makes the game harder to play, but engages the player's whole body.

So far, we've created games that use a single backdrop. However, Scratch offers some fairly robust tools to work with different backdrops. In this video, we'll use our laptop's webcam to import photos, which we'll use as the basis for a simple locked door puzzle.

We have photos of three different game states. Now, we need to start working on making clickable objects that we can overlay on these photos so that we can trigger events within the game.

Now, we have clickable hotspots that can pop up a message and change the game world. However, right now, we can escape the room in one click - hardly a challenge. Let's make a locked door puzzle. We'll use more if-then statements with true-false questions in order to trap our player until he or she wins the game. This is easier than it sounds.

We've added a locked door puzzle that works. But so far, we've only used the word “key” in the text messages that the player reads. Let's make a key object, so the player gets some visual feedback.

We've achieved the motive of escaping the room, but we can't just end the game yet. Let's create another state where we give the player the satisfaction of accomplishment.

The basic idea - fire something at the incoming targets - is fairly simple. You could protect your picnic basket from ants or be a politician throwing money at incoming political problems. We will defend the earth against hostile rocket ships. Let's create sprites for the player to interact with.

We'll start with fairly large, fairly slow invaders.

The mechanics of the game work, but we need to keep track of the game state so that the player feels more involved.

Our game works, but it's very easy. We'll use cloning and decrease the interval between enemy spawning in order to increase the difficulty level.

Now that our base defense game works, we can re-use the mechanics with just about any graphics.

So far, the games we've built work, but they’re rough. A first-time player would have no idea how to play. We’ll start this video by creating the artwork for a simple maze game, which we'll implement and polish over the next few videos.

We have the main pieces of the game; now let's add the code to make them work together.

A good game will get a little more complex as it progresses. In this video, we'll implement walls that will kill the player if touched.

We'll ramp up the stakes a bit - this time, with a moving deathsquiggle level. This means that we will have assets to show and hide based on what level is active.

We’re in the home stretch. Let’s create two different endings for the game – lose and win – and let’s code them. Then, let’s publish our game to the Scratch community and beyond.