Capstone: build a Turtle game

What you are building

By now you have met every part you need: Turtle the robot on the screen, loops that repeat, functions that tidy your code, lists that hold many things at once, and events that react to a key or a click. The capstone is where you assemble those parts into one small game that runs and that you can show to someone.

The goal is modest on purpose. Not a polished commercial game, just a working one: a turtle that moves when you press a key, something to reach or avoid, and a way to win or lose. If it runs and someone else can play it, it counts.

You can work alone or in a group. Most learners pair up, split the parts between them, and put the pieces together in the last sessions.

Pick your project

Choose one idea and stick with it. A finished small game beats an unfinished ambitious one. Four that fit Turtle well:

• Snake. A square moves around the screen with the arrow keys, grows each time it eats a dot, and ends if it hits the wall. This is the friendliest starting point.
• Tic-Tac-Toe. Draw a grid, let two players click squares to place X and O, and check for three in a row. Good if you prefer clicks over movement.
• Labyrinth (maze). Draw walls, drop the player at the start, and let the arrow keys guide it to the exit without crossing a wall.
• Conway's Game of Life. A grid of cells that turn on and off by simple neighbour rules. The most abstract of the four, and a lovely one if you like patterns.

The lecture demo was a small SpaceShip game built the same way: one turtle you steer, a loop that keeps the game going, and functions for each action. Whichever you pick, the skeleton is the same.

Build it in milestones

Do not try to write the whole game at once. Build it in small steps and run it after each one, so you always have something that works.

1. Design it on paper. One or two sentences: what the game is, what the player does, and how you win or lose. This is your map.
2. Move one turtle with the keys. Get an arrow-key-controlled turtle on the screen. Nothing else yet.
3. Add the goal. Food to eat, a wall to avoid, a square to claim. Keep positions in a list so you can add and remove them.
4. Add a score and an ending. A counter that goes up, and a condition that stops the game.
5. Polish. Colours, a title, a short "press an arrow to start" message.

Milestone 2 is the heart of it, and it is short. Here is a runnable scaffold: a white square you drive with the arrow keys.

import turtle

screen = turtle.Screen()
screen.title("My game")
screen.bgcolor("black")

player = turtle.Turtle()
player.shape("square")
player.color("white")
player.penup()

step = 20

def go_up():
    player.sety(player.ycor() + step)

def go_down():
    player.sety(player.ycor() - step)

def go_left():
    player.setx(player.xcor() - step)

def go_right():
    player.setx(player.xcor() + step)

screen.listen()
screen.onkey(go_up, "Up")
screen.onkey(go_down, "Down")
screen.onkey(go_left, "Left")
screen.onkey(go_right, "Right")

turtle.done()

Notice that every part you have learned is already here: a turtle stored in a variable, one small function per action, and event listeners that connect a key to a function. From this base, milestone 3 is just adding a second turtle for the food and a list of where the food sits.

Here is milestone 3 in code. Add a food turtle, a way to drop it at a random spot, and a check for when the player reaches it:

import random

food = turtle.Turtle()
food.shape("circle")
food.color("red")
food.penup()

def place_food():
    food.goto(random.randint(-9, 9) * 20, random.randint(-9, 9) * 20)

place_food()

score = 0

def check_food():
    global score
    if player.distance(food) < 20:
        score += 1
        place_food()

Add one line, check_food(), to the end of each of your four move functions. Now every time the player lands on the food, the score goes up and the next food appears somewhere new. That is milestone 3 and the start of milestone 4 in a dozen lines, built only from a turtle, a random position, a function per job, and the events you already wired.

Present it

The last session is a showcase. Groups spend the final meetings putting their pieces together into a working result, play each other's games, and then present. In the course grade the project is worth 30% and the presentation 10%, so the showing matters, not only the code.

A short, honest presentation works best:

• Show the game running first. Let people see it play before you explain anything.
• Say what it does in one sentence, then what was hardest and how you solved it.
• Name who did what if you worked in a group.
• It is fine if something is unfinished. Say what you would add next.

You are not being judged on making a perfect game. You are showing that you can take an idea, break it into parts, and build those parts with the tools from this course.

Before the questions below, put the build milestones back in the order that always leaves you with something that runs:

Check yourself

1. Why is it better to build your game in milestones and run it after each step, rather than writing the whole thing before you test it?
2. In the scaffold above, which two ingredients from earlier lessons connect a key press to a turtle moving?
3. If you had one session left and your game was not finished, what would you choose to show, and what would you say about the parts that are missing?