Project: Basketball Shooting Game

One-sentence summary

In this lesson we build a basketball shooting game in Scratch: we set the shot power and angle, move the ball with gravity, score a point when it touches the hoop and count the number of attempts.

Why it matters

I enjoy playing basketball. On the court, we adjust the power, the angle and the timing to make a shot. When we build a shooting game on a computer, we use the same ideas, except this time we code the path of the ball ourselves.

This project brings together three structures from earlier lessons: sequence (the shot steps happen in a set order), condition (if the ball touches the hoop, add a point) and repetition (keep moving the ball while it is in the air). We also add a new idea: making an object move with something like gravity.

This is a game project, not a real physics simulation. Our goal is a playable, teaching game, not a perfect physics engine.

Planning the game

Before writing any code, it helps to describe what the game should do in plain sentences. This is similar to the pseudocode from earlier lessons.

The rules of the game

• The player chooses a power and an angle.
• Pressing the green flag launches the ball.
• The ball falls with gravity while it is in the air.
• If the ball touches the hoop, the score goes up.
• After each shot, the attempt count goes up by one.

Sprites and variables we will use

A sprite is an object that moves on the stage. A variable is a number the game keeps in memory.

• Sprites: Ball, Hoop
• Variables: score, attempts, power, angle, speed_y

Here speed_y holds the vertical (up–down) speed of the ball. Gravity lowers this value a little on every step, which makes the ball rise first and then fall.

Shot power and angle

In a real shot we set two things: how hard we throw (power) and which direction we send the ball (angle). In the game we represent these with two variables.

Turning variables into sliders

In the Variables panel, right-click power and angle and choose the “slider” option. Now the player can change these values on the stage with the mouse, so every attempt can be a different shot.

Example: starting a shot

The block sequence below places the ball at the starting point when the green flag is clicked and gives it a first speed based on the chosen power.

when green flag clicked
set "attempts" to 0
set "score" to 0
go to x: -180 y: -120
point in direction (angle)
set "speed_y" to (power)

By setting speed_y to the power value, we decide the ball's first upward speed. The direction block sets the angle at which the ball will travel.

Moving the ball with gravity

Now we reach the most important part of the project: the path of the ball. The ball moves forward and is pulled down by gravity at the same time.

The idea of gravity

In the real world, a ball thrown upward slows down, stops and begins to fall. To imitate this in the game, we lower speed_y a little on every step. We can call this a kind of gravity.

Example: the flight loop

The loop below moves the ball forward in the angle direction, shifts it vertically by speed_y, and then applies gravity.

when I receive "Shoot"
forever
  move 5 steps
  change y by (speed_y)
  change "speed_y" by -1
  if <y position < -140> then
    change "attempts" by 1
    stop other scripts in sprite

In this loop:

• change y by (speed_y) moves the ball up or down.
• change "speed_y" by -1 lowers the speed each step, so the ball rises first and then falls.
• The condition y position < -140 notices when the ball hits the ground, ends the shot and adds to the attempt count.

Scoring and touching the hoop

For a shot to “go in,” the ball has to touch the hoop. We check this with the touching block from the Sensing category.

Example: the score condition

The block sequence below adds a point the moment the ball touches the hoop and then stops the ball.

when I receive "Shoot"
forever
  if <touching "Hoop"?> then
    change "score" by 1
    say "Basket!" for 1 seconds
    stop other scripts in sprite

Here <touching "Hoop"?> is a condition: the steps inside run only when the ball touches the hoop. The stop block prevents the point from being counted several times in the same shot.

Launching a shot

We want the player to shoot on a key press. This short sequence starts a shot when the space key is pressed:

when space key pressed
go to x: -180 y: -120
set "speed_y" to (power)
point in direction (angle)
broadcast "Shoot"

So after setting the power and angle, the player presses space to take a new shot.

Mini practice

Try these steps in order:

1. Open a new Scratch project and add two sprites: Ball and Hoop.
2. Create the variables score, attempts, power, angle, speed_y.
3. Turn power and angle into sliders.
4. Add the four block sequences above to the right sprites.
5. Take at least five shots with different power and angle values.

Test scenarios

• Low power: With very low power, can the ball reach the hoop? Probably not. That is an expected result.
• High power: With very high power, does the ball fly over the hoop? If so, lower the power a little.
• Right angle: In which angle range does the ball come closest to the hoop? Write it down.

Ideas to improve it

• Show a message that reads “Shot rate: score / attempts.”
• Make the hoop move sideways every few shots so the game gets harder.
• Add a shot sound (Sound category).

Project strengthening plan

A working demonstration is not enough for Project: Basketball Shooting Game. A strong project also makes its aim, user, limits, test conditions and failed attempts visible. Use the context of an animation in which two sprites take turns through messages to produce a working Scratch scene, an organised block stack and a test list. Although the lesson aims to “Design a simple basketball shooting game with shot power, gravity and score”, do not present an unmeasured result as a confirmed success.

1. Project summary and scope

Write three sentences: What problem are you solving, who is affected by it, and what will the first version deliberately not do? Stating what is outside the scope does not weaken a project; it makes the project finishable. Describe the connection between Planning the game and Sprites and variables we will use as the main assumption, then name the test that can confirm or reject it.

2. Acceptance criteria

• Does the green flag create the correct starting state?
• Do events run only when needed?
• Do variables have clear names?
• Are clone and loop counts under control?
• Is the previous state cleared when the project restarts?

Do not leave an acceptance criterion for “Project: Basketball Shooting Game” as a vague statement such as “it works”. Choose an observable measure such as time, distance, correct trials, screen width or user steps. When direct measurement is difficult, record whether the same behaviour appears in three consecutive trials.

3. Test matrix

4. Version log

For every version of “Project: Basketball Shooting Game”, record the date, the one main decision changed, the reason and the test result. A first version that fails is evidence about which assumption involving Planning the game or Sprites and variables we will use should be reconsidered. Remove personal information and private background details from images.

5. Presentation and self-review

Prepare a two-minute explanation of “Project: Basketball Shooting Game”: the problem, the solution approach, the most important result for an animation in which two sprites take turns through messages, and the next step. Instead of saying the project is complete, state which part has been verified and which part still needs development.

Common mistakes

Forgetting gravity

If you leave out change "speed_y" by -1, the ball travels in a straight line and never falls. No shot curve appears.

Not resetting the variable

If you do not set speed_y back to power before each shot, the second shot starts with the leftover speed of the first one and behaves strangely. Set the starting values again for every shot.

Counting the score more than once

Without the stop block, the score keeps rising during the several steps that the ball touches the hoop. Stop the loop once a shot goes in.

Testing without writing the expected result

Saying “it does not work” is not enough. First write what you expect (“the ball should rise and then fall”), then observe what happens. Find the first step where they differ and fix only that step.

Safety note

This lesson is done entirely at a screen; no electronics or tools are used. Even so, looking at a screen for a long time can be tiring. Take a short break every 20–30 minutes, rest your eyes and, if you can, take a few shots with a real ball to get moving. Ask an adult before sharing your project online.

Lesson summary

• Planning a game project in plain sentences first makes the coding easier.
• Shot power and angle are represented by two variables and can be set with sliders.
• We imitate gravity by lowering the vertical speed a little on every step.
• Touching the hoop is a condition; when the condition is true, the score goes up.
• Test scenarios and fixing mistakes are the main ways to improve the game step by step.

Check questions

1. What does the speed_y variable represent in the game?
2. Which line makes the ball fall along a curve in the air?
3. Which category is the <touching "Hoop"?> block in, and what does it do?
4. Which values must you reset before each shot, and why?
5. If we leave out the stop block, what scoring mistake happens?

Answers

1. speed_y holds the vertical (up–down) speed of the ball. Gravity lowers this value so the ball rises first and then falls.
2. The line change "speed_y" by -1. It lowers the vertical speed each step and creates the shot curve.
3. It is in the Sensing category. It checks whether the ball touches the hoop and is used as a condition.
4. At least speed_y (back to the power value), the starting position and the direction. This way every shot starts from the same clean state and does not mix with the leftover speed of the previous shot.
5. The score rises several times in one shot, because the condition stays true for the several steps that the ball touches the hoop.

Source and verification note

For “Project: Basketball Shooting Game”, verification focuses on whether the relationship between Planning the game and Sprites and variables we will use remains consistent across examples. Block names are kept consistent with the current core Scratch categories. Project behaviour should be tested separately for start-up, normal play, errors and restarting.

Next lesson

Project: Robot Mission Simulation