Code a Game: Algorithms and Debugging

You need: Chalk or masking tape · A 5 × 5 grid about 50 cm per square · Arrow cards: forward, turn left, turn right · A soft toy as the target

1. Draw the grid on the court or tape it on the classroom floor.
2. Put the robot (a classmate) on a start square, facing one way. Place the target.
3. The programmers lay out arrow cards in order without speaking to the robot.
4. The robot follows the cards exactly. If they walk off the grid or into an obstacle, that is a bug.
5. Fix the program by changing only the cards that were wrong.
6. Add obstacles and try again. Can you find a shorter program?

How you'll know: Your robot reaches the target on the first run of your final program, and you can point to the card that caused any earlier bug.

Safety: Play on a dry, clear surface, walking only, and keep away from the edge of the court.

Go further: Add a 'repeat 3' card and rewrite your program with fewer cards.

You need: A device with Scratch · A starter project or a blank project

1. Choose a player sprite and an object sprite, like a bucket and a piece of fruit.
2. Make the player move left and right with the arrow keys.
3. Make the object start at a random x at the top and glide or fall down inside a forever loop.
4. Make a variable called score. Add: if touching player, change score by 1 and send the object back to the top.
5. Make a variable called lives. If the object touches the bottom, change lives by -1.
6. Add: if lives = 0 then say 'Game over' and stop all, else keep playing.

How you'll know: Your score goes up when you catch, lives go down when you miss, and the game ends properly at zero lives.

Go further: Make the object fall faster every time the score reaches a multiple of 5.

You need: Five cards with 1, 2, 4, 8 and 16 dots on one side and blank on the back · Paper for recording

1. Lay the cards in a row from 16 on the left to 1 on the right, all dots showing. Notice each is double the one to its right.
2. Turn cards over so only the dots you need show to make 5. Which cards are face up?
3. Write face up as 1 and face down as 0. 5 is 00101.
4. Make 10, 17, 21 and 31 and write each in binary.
5. What is the biggest number you can make with five cards? What about six?
6. Challenge a partner: say a binary number, they turn the cards to find it.

How you'll know: You can turn any number from 0 to 31 into binary and back again without counting dots one by one.

Go further: Use binary to send a secret letter: A = 1, B = 2 and so on. Decode your partner's message.

You need: Your six-panel storyboard · Cut-out paper sprites · A large sheet as the 'stage' · A timer

1. Lay the stage on the table. Put the paper sprites where the game starts.
2. Explain the game to your tester in one sentence only.
3. The tester says what they want to do; you move the paper pieces as the computer would.
4. Do not help or explain further. Note every time they hesitate or ask a question.
5. Play for three minutes, then ask: what was the goal? What was confusing?
6. Change one rule or instruction on your storyboard before you code anything.

How you'll know: Your tester can say the goal of the game in their own words after one play.

Go further: Test with someone much younger at home and compare their questions with your classmate's.

You need: The teacher's buggy Scratch project · A bug log sheet · A rubber duck or any toy (optional)

1. Play the game and write down everything that goes wrong. Don't fix anything yet.
2. For each bug, predict which sprite and which script is causing it.
3. Read that script out loud, block by block, to your partner or the duck.
4. Change one thing only. Test again. Did it fix the bug or create a new one?
5. Record in your log: what happened, what should happen, the cause, the fix.
6. Sort your bugs: sequence bug (wrong order), logic bug (wrong condition), or input bug (wrong key or value).

How you'll know: Your log shows all four bugs fixed, each with a cause and a type.

Go further: Plant two sneaky bugs in your own copy and swap with a partner.

You need: Your game on a device · An observation sheet with tally columns · A pencil

1. Sit beside your player, not in front of the screen.
2. Say only: 'This is a game I made. Have a go.'
3. Tally each time they look confused, click the wrong thing, laugh or say 'again'.
4. Help only if they ask twice, and write down what they asked.
5. At the end, ask two questions: 'What was the best bit?' and 'What was tricky?'
6. Circle the three biggest problems to fix.

How you'll know: You have tallies and quotes from at least two players, and three clear changes to make based on them.

Go further: Time how long each player keeps playing and compare version one with version two.

You need: Your game · The fair-game checklist · A partner

1. Privacy: check there are no real names, photos, school names or locations in the game or its notes.
2. Copyright: list every image and sound. Mark each as 'I made it', 'Scratch library' or 'openly licensed with credit'.
3. Fairness: does the game have a clear ending? Does it pressure players to keep going? Is losing kind?
4. Accessibility: can a player who cannot read yet understand it? Are buttons big enough?
5. Swap with a partner and check each other's game against the list.
6. Fix anything that fails and note it in your journal.

How you'll know: Your game passes every item on the checklist, and you can explain one change you made for fairness or privacy.

Go further: Look at a game you play at home. Find one design trick that keeps you playing, and decide whether it is fair.