LEVEL UP YOUR PYTHON
& BUILD THE GAME

Open code.org and try one Hour of Code activity on functions - student-led, just click and play.

By the end of this lesson you will be able to define a function with one or more parameters, call it with different arguments, and explain the difference between a parameter and an argument.

1. Open Thonny and create a new file. Functions are reusable blocks of code defined with def:
   def greet(name):
   print("Hello,", name, "!")
   
   greet("Alex")
   greet("Priya")
2. Run it. Notice name is a parameter - a placeholder. "Alex" and "Priya" are arguments - the actual values passed in.
3. Functions can take more than one parameter. Try:
   def add_numbers(a, b):
   result = a + b
   print("The total is", result)
   
   add_numbers(4, 7)
   add_numbers(100, 250)
4. Save this file as task1_practice1.py. Add two more functions of your own with at least one parameter each.
5. Challenge: write a function called describe_pet(name, animal) that prints a sentence describing a pet using both parameters.

Open checkio.org and read through one beginner Python puzzle - think about the logic before coding. Student-led.

By the end of this lesson you will be able to write functions that use return to send a value back to the caller, and use that returned value in further calculations.

1. So far your functions have used print() inside them. Now try return instead:
   def add_numbers(a, b):
   return a + b
   
   total = add_numbers(4, 7)
   print("The total is", total)
2. Notice the difference: return sends the value back so it can be stored in a variable (total) and reused - print() just displays it and the value is gone.
3. Write a function calculate_average(a, b, c) that returns the average of three numbers. Call it with three different sets of numbers and print each result.
4. Now combine two functions - use the return value of one function as the input to another:
   def square(n):
   return n * n
   
   def double(n):
   return n * 2
   
   result = double(square(5))
   print(result) # square(5) -> 25, then double(25) -> 50
5. Save your work as task1_practice1.py (continuing from Lesson 1) - add your new functions below the existing ones.

Scratch: explore how Scratch saves and loads project files - student-led discussion of "what does saving actually mean?"

By the end of this lesson you will be able to open a file in write mode, write text to it using with open(), and explain why this is needed for data to survive after a program ends.

1. Every variable in Python disappears when the program ends - unless you save it to a file. Try this:
   with open("notes.txt", "w") as f:
   f.write("Hello from Python!\n")
   f.write("This line was written by my program.\n")
2. Run it, then look in your file browser for notes.txt - open it to see what was written. Notice \n creates a new line.
3. The with statement automatically closes the file when you're done - this is the safe, modern way to handle files in Python.
4. Write a program that asks the user for three favourite movies (using input()) and writes each one to a file called movies.txt on its own line.
5. Save this as task1_practice2.py. Run it twice with different answers - notice "w" mode overwrites the file each time.

Kahoot teacher-run quiz on functions and file writing from Weeks 1-2. Student-led from there - just join and play!

By the end of this lesson you will be able to open a file in read mode, loop through its contents line by line, and use the data inside your program.

1. Using the movies.txt file from last lesson, read it back:
   with open("movies.txt", "r") as f:
   for line in f:
   print(line.strip())
2. Notice .strip() removes the trailing newline character - without it you'd see extra blank lines.
3. Write a function load_movies(filename) that opens the given file, reads every line into a list, and returns the list.
4. Call your function and print the returned list, then loop through it to print each movie on its own line with a number (e.g. "1. Movie Name").
5. Save this as task1_practice3.py - it should combine a function, a return value, and file reading all in one program.

Open codingame.com and browse a beginner Python challenge - read the problem and plan your approach. Student-led.

By the end of this lesson you will be able to handle the case where a file doesn't exist yet using try/except, and begin building your high-score tracker.

1. Start a new file: highscores.py. The problem: if highscores.txt doesn't exist yet, opening it in "r" mode will crash your program.
2. Use try/except to handle this gracefully:
   def load_scores(filename):
   try:
   with open(filename, "r") as f:
   return [line.strip() for line in f]
   except FileNotFoundError:
   return []
3. This function returns an empty list the first time the program runs (no file yet), and the saved scores every time after that.
4. Write a function save_score(filename, name, score) that appends a new line in the format name,score to the file (use "a" mode).
5. Write the main program: ask the player for their name and a score (e.g. for a number-guessing game from earlier this year), call save_score(), then call load_scores() and print everything saved so far.

By the end of this lesson you will be able to sort a list of scores, display a leaderboard, finish your high-score tracker program, and submit all Task 1 files with a written reflection.

1. Your saved scores are strings like "Alex,120". To sort by score, split each line and convert the score to an integer:
   scores = load_scores("highscores.txt")
   parsed = []
   for line in scores:
   name, score = line.split(",")
   parsed.append((name, int(score)))
2. Sort the list of tuples by score, highest first, using sorted() with a key:
   leaderboard = sorted(parsed, key=lambda x: x[1], reverse=True)
   print("=== LEADERBOARD ===")
   for i, (name, score) in enumerate(leaderboard, start=1):
   print(str(i) + ". " + name + " - " + str(score))
3. Run your program multiple times with different names and scores. Confirm the leaderboard updates and stays sorted correctly each time.
4. Write your reflection (5-8 sentences): what was the hardest part of this task - functions, return values, or file handling? How did you work through it? Use correct terminology.

Open tynker.com and try one Hour of Code level involving collections or arrays - student-led, just click and play.

By the end of this lesson you will be able to create a list, access items by index, loop through a list with for, and add new items with append().

1. A list stores multiple values in one variable, in order. Try:
   fruits = ["apple", "banana", "cherry"]
   print(fruits)
   print(fruits[0]) # first item - lists start at index 0
   print(fruits[2]) # third item
2. Loop through every item in a list:
   for fruit in fruits:
   print("I like", fruit)
3. Add new items with .append():
   fruits.append("mango")
   print(fruits)
   print("There are", len(fruits), "fruits")
4. Save this as task2_lists.py. Create a list of at least 5 of your favourite songs, artists, or games. Loop through it and print each one numbered (e.g. "1. Item").
5. Challenge: write a program that asks the user for 5 numbers (using input() and append()), then prints the total and average using sum() and len().

Open checkio.org and read through a beginner puzzle involving lists or sorting - think about the logic before coding. Student-led.

By the end of this lesson you will be able to sort a list, check whether an item exists using in, remove items, and use slicing to access parts of a list.

1. Continue in task2_lists.py. Try sorting:
   scores = [85, 42, 90, 67, 73]
   scores.sort()
   print(scores) # lowest to highest
   scores.sort(reverse=True)
   print(scores) # highest to lowest
2. Check if an item exists using in:
   names = ["Alex", "Priya", "Sam"]
   if "Priya" in names:
   print("Found her!")
   else:
   print("Not in the list.")
3. Remove items with .remove(), and access a range with slicing [start:end]:
   names.remove("Sam")
   print(names)
   
   numbers = [10, 20, 30, 40, 50]
   print(numbers[1:4]) # items at index 1, 2, 3
4. Write a program: create a list of 6 test scores. Sort it, print the highest and lowest (first and last after sorting), and print the top 3 using slicing.
5. Add to your song/artist list from Lesson 1: write code that checks if a specific title is in your list, and removes one item.

Kahoot teacher-run quiz on lists from Week 4. Student-led from there - just join and play!

By the end of this lesson you will be able to create a dictionary, access values by key, add new key-value pairs, and update existing values.

1. A dictionary stores data as key-value pairs - instead of a numbered index, you look things up by name:
   student = {
   "name": "Alex",
   "score": 85,
   "grade": "B"
   }
   print(student["name"])
   print(student["score"])
2. Update or add values using the key:
   student["score"] = 92 # update existing key
   student["year"] = 10 # add a new key
   print(student)
3. Loop through all keys and values:
   for key, value in student.items():
   print(key, "->", value)
4. Save this as task2_dictionaries.py. Create a dictionary representing yourself (name, age, favourite game, etc.) with at least 4 keys. Print each key and value using .items().
5. Challenge: write a function describe(person) that takes a dictionary as a parameter and returns a sentence describing them using the dictionary's values.

Open codingame.com and browse a beginner challenge involving data records - read the problem and plan your approach. Student-led.

By the end of this lesson you will be able to combine lists and dictionaries to represent multiple records, and loop through them to find or filter specific entries.

1. This is the structure your students.py program will use - a list of dictionaries, where each dictionary is one record:
   students = [
   {"name": "Alex", "score": 85},
   {"name": "Priya", "score": 92},
   {"name": "Sam", "score": 67}
   ]
2. Loop through the list - each student is one dictionary:
   for student in students:
   print(student["name"], "scored", student["score"])
3. Search for a specific record:
   search_name = input("Enter a name to search: ")
   for student in students:
   if student["name"] == search_name:
   print("Found:", student)
4. Calculate the class average:
   total = 0
   for student in students:
   total += student["score"]
   average = total / len(students)
   print("Class average:", average)
5. Start students.py: build the list of dictionaries above with at least 5 students, then implement the search and average code from steps 3-4.

By the end of this lesson you will be able to write a function that takes a list as a parameter and modifies it, and use conditionals to assign a grade based on a score.

1. Write a function add_student(students) that asks the user for a name and score, then appends a new dictionary to the students list:
   def add_student(students):
   name = input("Enter student name: ")
   score = int(input("Enter their score: "))
   students.append({"name": name, "score": score})
2. Notice this function doesn't need to return anything - because lists are mutable, changes made inside the function affect the original list directly.
3. Write a function get_grade(score) that returns a letter grade based on the score (A: 85+, B: 70+, C: 50+, D: 40+, E: below 40).
4. Update your average calculation to also print each student's name with their grade, using your get_grade() function:
   for student in students:
   grade = get_grade(student["score"])
   print(student["name"], "-", student["score"], "- Grade", grade)
5. Put it all together: your program should add students, search by name, calculate the average, and display each student's grade.

By the end of this lesson you will be able to build a simple menu-driven program using a while loop, test your program thoroughly, and submit Task 2 with a written reflection.

1. Tie your program together with a menu loop so the user can choose what to do:
   while True:
   print("\n1. Add student")
   print("2. Search for a student")
   print("3. Show class average")
   print("4. Quit")
   choice = input("Choose an option: ")
   if choice == "1":
   add_student(students)
   elif choice == "4":
   break
2. Fill in the remaining menu options (2 and 3) by calling the functions you've already written.
3. Test your program thoroughly: add at least 2 new students, search for one that exists and one that doesn't, and confirm the average updates correctly.
4. Write your reflection (5-8 sentences): explain the difference between a list and a dictionary using a specific example from your own program, and describe one bug you fixed and how.

Open code.org and try one Hour of Code activity - student-led, just click and play, while thinking about how "things" in the game have properties (health, position, etc.).

By the end of this lesson you will be able to define a class with __init__, give it attributes, and create multiple objects (instances) from it.

1. A class is a blueprint for creating objects. Try this:
   class Pet:
   def __init__(self, name, animal_type):
   self.name = name
   self.animal_type = animal_type
   self.hunger = 5
   
   my_pet = Pet("Rex", "Dog")
   print(my_pet.name)
   print(my_pet.animal_type)
   print(my_pet.hunger)
2. __init__ runs automatically when you create a new object. self refers to "this specific object" - every attribute you set with self. belongs to that object.
3. Create a second object from the same class:
   second_pet = Pet("Whiskers", "Cat")
   print(second_pet.name)
   print(my_pet.name) # still "Rex" - separate objects!
4. Save this as task3_classes.py. Create your own class with at least 3 attributes (e.g. a Character, Vehicle, or Player class - your choice for your final simulation). Create 2 different objects from it and print their attributes.
5. Challenge: create a list containing both of your objects, then loop through the list and print each object's name attribute.

Open checkio.org and read through a beginner puzzle involving objects or classes - think about the logic before coding. Student-led.

By the end of this lesson you will be able to add methods to a class that change an object's attributes and return information about its state.

1. A method is a function that belongs to a class. Add one to your Pet class:
   class Pet:
   def __init__(self, name, animal_type):
   self.name = name
   self.animal_type = animal_type
   self.hunger = 5
   
   def feed(self):
   self.hunger -= 1
   print(self.name, "has been fed. Hunger is now", self.hunger)
2. Call the method on your object:
   my_pet = Pet("Rex", "Dog")
   my_pet.feed()
   my_pet.feed()
   print(my_pet.hunger)
3. Add a second method that returns something instead of just printing - e.g. a method is_hungry(self) that returns True if hunger > 7, otherwise False.
4. In task3_classes.py, add at least 2 methods to the class you created in Lesson 1 - one that changes an attribute, and one that returns information based on the current attribute values.
5. Test your methods by creating 2 objects, calling the methods on each, and confirming each object's state changes independently.

Kahoot teacher-run quiz on classes, objects, and methods from Week 7. Student-led from there - just join and play!

By the end of this lesson you will be able to plan a simulation involving two classes that work together, and begin building it in simulation.py.

1. Choose your simulation idea. Some examples: a Zoo (Zookeeper class manages a list of Animal objects), a Garage (Mechanic class repairs Car objects), a Classroom (Teacher class manages a list of Student objects), or a Game (Player class fights Monster objects).
2. On paper or in a comment block, plan: What are your two classes called? What attributes does each have (from __init__)? What methods does each have? How do they interact - does one class create or use objects of the other?
3. Example structure for a Zoo simulation:
   class Animal:
   def __init__(self, name, species):
   self.name = name
   self.species = species
   self.fed = False
   
   def feed(self):
   self.fed = True
   print(self.name, "has been fed.")
   
   class Zoo:
   def __init__(self, zoo_name):
   self.zoo_name = zoo_name
   self.animals = []
   
   def add_animal(self, animal):
   self.animals.append(animal)
4. Start simulation.py. Define your two classes with __init__ and at least their first attributes. Don't worry about methods yet - get the structure right first.
5. Submit your planning notes/diagram alongside your final files in Week 9.

By the end of this lesson you will be able to create objects that store and manage other objects, and write methods that make your two classes interact.

1. Continue building simulation.py. Add the methods you planned last lesson to both classes.
2. Create the "container" object first, then add other objects to it:
   my_zoo = Zoo("DigiTech Zoo")
   
   lion = Animal("Leo", "Lion")
   giraffe = Animal("Spots", "Giraffe")
   
   my_zoo.add_animal(lion)
   my_zoo.add_animal(giraffe)
3. Write a method on your container class that loops through its list of objects and calls a method on each - e.g. a feed_all(self) method on Zoo:
   def feed_all(self):
   for animal in self.animals:
   animal.feed()
4. Test: create at least 3 objects of your "item" class, add them all to your "container" class, and call a method that processes all of them.
5. If you have time, add one more method to each class - aim for at least 2 working methods per class by the end of this lesson.

Open projecteuler.net and read Problem 1 - think about how you'd structure a solution. Student-led.

By the end of this lesson you will be able to thoroughly test your simulation with multiple objects, identify and fix bugs, and add final touches like a simple menu or summary output.

1. Test your simulation by creating at least 3-4 objects of your "item" class and confirming each one behaves independently - changing one object's attributes should NOT affect the others.
2. Run through every method at least once. For each one, ask: does it do what I expect? Does it use self correctly?
3. Add a simple "summary" method or loop that prints the current state of all your objects - e.g. every animal's name and whether they've been fed.
4. If you have time, add a small menu loop (like Task 2) so a user can interact with your simulation - e.g. choose to feed a specific animal by name.
5. Fix any remaining errors. Make sure your final program runs from start to finish without crashing.

By the end of this lesson you will be able to write a reflection that explains classes and objects using your own program, and submit all Task 3 materials.

1. Do a final test run of simulation.py from start to finish - make sure there are no leftover debugging print statements you didn't mean to keep (unless they're part of your output).
2. Write your reflection (5-8 sentences). Include: what your two classes represent and why you chose them; one specific example of an attribute and a method from your own code, explained in your own words; and one challenge you faced with OOP and how you solved it.
3. Look back over Module 1 (Tasks 1-3): in 2-3 sentences, describe how functions, file handling, lists, dictionaries, and classes connect - how did each task build on the last?
4. Gather your final files: task3_classes.py, simulation.py, your planning notes/diagram, and your reflection.

Play a short round of any classic arcade game you have access to (browser-based or classroom). As you play, notice: what are the rules? What happens when you win or lose? Student-led.

By the end of this lesson you will be able to describe a game's core mechanic, rules, feedback, and win/lose conditions, and begin planning your own arcade game.

1. As a class, discuss: what is a mechanic (the core action the player repeats - jumping, shooting, dodging, collecting)? What are rules (what's allowed, what isn't)? What is feedback (sounds, animations, score changes that tell the player what just happened)?
2. Pick 2 games you know well (arcade, mobile, or console). For each, write down: the core mechanic, one rule, one piece of feedback, and the win/lose condition.
3. Brainstorm 3 ideas for your own simple arcade game. For each idea, write one sentence describing the core mechanic (e.g. "dodge falling obstacles", "collect coins before time runs out", "shoot approaching enemies").
4. Choose your favourite idea. Write your game design notes: core mechanic (1 sentence), win condition (1 sentence), lose condition (1 sentence), and the feeling you want the player to have (e.g. tense, fast-paced, satisfying).
5. Sketch (on paper or digitally) what your game's single screen will look like - where is the player, where do enemies/obstacles appear, where is the score shown?

By the end of this lesson you will be able to navigate the GDevelop interface, create a new project, add a scene, and place sprite objects on screen.

1. Open GDevelop (browser-based - no install needed, no consent required). Create a new empty project.
2. A GDevelop project is made of scenes (like levels or screens) and objects (sprites, characters, text, etc.) placed on those scenes. Explore the main editor: the scene view, the objects panel, and the events sheet.
3. Add a new Sprite object - this will become your player character. Choose or import an image, and place it on the scene.
4. Add 1-2 more objects based on your game design notes: an enemy/obstacle sprite, and a text object for displaying the score.
5. Save your project with a clear name (e.g. my_arcade_game). Get into the habit of saving regularly throughout this module.

Kahoot teacher-run quiz on game design vocabulary from Week 1. Student-led from there - just join and play!

By the end of this lesson you will be able to use GDevelop's events sheet to make your player object move in response to keyboard input.

1. Open your project's events sheet (usually below the scene editor). Events follow a pattern: Condition (something that must be true) → Action (something that happens).
2. Add a new event. For the condition, choose "Key pressed" and select an arrow key (e.g. Right arrow). For the action, choose your player object and "Move object" or "Change position" - set it to move right by a small amount each frame.
3. Repeat for Left, Up, and Down arrows (or WASD), each moving the player in the corresponding direction.
4. Preview your game (the "play" button). Test that your player moves smoothly in all 4 directions. If movement feels too slow or too fast, adjust the movement amount and test again.
5. Decide: should your player be able to move off the edges of the screen? If not, add a condition that keeps the player's position within the scene boundaries.

By the end of this lesson you will be able to detect collisions between objects, create a score variable, and update a text object to display the score.

1. Create a new scene variable called Score and set its starting value to 0 (usually done in "At the beginning of the scene" event).
2. Add a collision event: Condition = "Player is in collision with [other object]". For the action, choose what should happen - increase the Score variable by an amount (e.g. +10), and/or delete or hide the collided object (so it can't be collected twice).
3. Update your score display: add an event with no condition (always true), and an action that changes the text of your score text object to show the current value of the Score variable, e.g. "Score: " + Score.
4. Preview your game. Move your player into the other object and confirm the score updates and displays correctly.
5. If your design includes an enemy that should cause the player to lose (rather than score), set up a separate collision event for that - but leave full win/lose logic for Lesson 5.

Open gdevelop.io/games and play one or two example games made by other creators - notice how each one shows you've won or lost. Student-led.

By the end of this lesson you will be able to implement a win condition and a lose condition that clearly end the game and give the player feedback.

1. Refer back to your game design notes from Lesson 1 - what is your win condition? What is your lose condition? (e.g. "Score reaches 100" / "Player collides with enemy 3 times").
2. For your lose condition: add an event with the condition (e.g. collision with enemy, or a "lives" variable reaching 0), and an action that changes the scene to a "Game Over" scene, or displays a "Game Over" text object and pauses the game.
3. For your win condition: add an event with the condition (e.g. Score variable ≥ a target value), and an action that displays a "You Win!" message or changes to a "Victory" scene.
4. If you're using separate scenes for game over / victory, create them now with simple text and a way to restart (e.g. a button that returns to the main scene).
5. Preview and test BOTH conditions - deliberately try to lose, then deliberately try to win (you can temporarily lower the win target to test faster, then change it back).

By the end of this lesson you will be able to playtest your game with a classmate, make improvements based on feedback, and submit Task 4 with a written reflection.

1. Swap computers with a classmate (or have them play on your screen). Watch them play your game without giving instructions - can they figure out the controls and goal on their own?
2. Ask your playtester: was anything confusing? Did movement feel responsive? Was it clear when they won or lost?
3. Make at least 2 improvements based on the feedback - this might be adjusting movement speed, adding a simple instruction text, or fixing a bug they found.
4. Final check: play your game from start to finish at least twice - once trying to win, once trying to lose - confirming both conditions work correctly.
5. Write your reflection (5-8 sentences): describe your game's core mechanic and win/lose conditions, one piece of feedback you received and how you responded to it, and one challenge you faced building in GDevelop.

Think of a game you've played that gets harder over time. How does it get harder - faster enemies, more enemies, less time, smaller spaces? Discuss with a classmate. Student-led.

By the end of this lesson you will be able to plan how your game will become more challenging, either through distinct levels or a difficulty curve within one level.

1. Open your Task 4 project. Decide: will you build a second scene as Level 2 (copy your scene and make it harder), or make your single level get harder over time (more enemies spawn, speed increases, time limit decreases)?
2. Either approach is valid - choose based on what fits your game and what you can realistically build in 3 weeks.
3. Write a short plan: if levels, what's different about Level 2 (more enemies? faster? new obstacle)? If a difficulty curve, what variable will you use to track progress (a timer? the score?) and how will difficulty respond to it?
4. If building a second scene: duplicate your Task 4 scene, rename it (e.g. "Level2"), and add a transition event from Level 1 to Level 2 (e.g. when score reaches a target, change scene).
5. If building a difficulty curve: identify ONE value you'll change over time (e.g. enemy speed, spawn rate) and plan how it will increase - gradually, or in steps every X seconds.

By the end of this lesson you will be able to implement your planned levels or difficulty curve in GDevelop and test that it works as intended.

1. If building Level 2: finish duplicating and modifying your second scene now - add more/faster enemies, a new obstacle type, or a different layout. Add the scene-change event so Level 1 leads to Level 2.
2. If building a difficulty curve: GDevelop has a built-in TimeDelta and timers. Create a timer, and add an event: "If timer > X seconds, increase [enemy speed / spawn rate variable] by a small amount."
3. Preview your game and play through to where the change should occur. Does it feel right? If the difficulty jumps too suddenly or too slowly, adjust your numbers.
4. Add a second stage of difficulty increase (either a Level 3, or a further timer-based increase) so the progression has at least 2 distinct steps.
5. Save your project. You now have an expanded game ready for sound and visual polish next lesson.

Kahoot teacher-run quiz on Weeks 1-4 game design and GDevelop concepts. Student-led from there - just join and play!

By the end of this lesson you will be able to add sound effects to your game that play in response to specific events.

1. GDevelop includes a library of free sound effects, or you can use sounds your teacher provides. Browse the audio resources in your project's resource manager.
2. Choose a sound effect for your scoring event (collecting an item, hitting a target). Add a "Play a sound" action to your collision/scoring event from Task 4.
3. Choose a different sound effect for your lose condition (game over, hitting an enemy). Add a "Play a sound" action to that event.
4. Preview your game. Confirm both sounds play at the correct moments and aren't too loud or jarring.
5. If you have time, add a third sound - for example, a "level up" sound when difficulty increases, or background music that plays continuously.

By the end of this lesson you will be able to improve your game's visual presentation through backgrounds, simple animations, and clearer on-screen information.

1. Add a background image or coloured background to your scene(s) - this immediately makes a game feel more finished. Use GDevelop's built-in resources or images approved by your teacher.
2. If your player or enemy sprites have multiple images, set up a simple animation (e.g. a walking or rotating animation) using the Sprite object's animation editor.
3. Improve your UI: make sure your score text is clearly visible (good contrast against the background), and consider adding instructions text (e.g. "Use arrow keys to move") visible at the start of the game.
4. Tidy up any remaining visual issues - objects overlapping awkwardly, text running off screen, or inconsistent sizing.
5. Preview your game with fresh eyes - does it look more "finished" than your Task 4 version? Note 2-3 specific improvements you made for your playtesting log.

Think about the last time you gave feedback on something (a piece of work, a game, a video). What made your feedback useful - or not useful? Discuss with a classmate. Student-led.

By the end of this lesson you will be able to conduct structured playtesting with classmates and record specific, useful feedback.

1. Start your playtesting log - a simple table or list with columns: Tester Name, What They Said, What I'll Change.
2. Find a playtester (a classmate). Before they play, ask them NOT to ask you questions - just play and react naturally. Watch quietly and take notes on where they get stuck, confused, or frustrated.
3. After they play, ask 3 specific questions: "What was the goal of the game?" "Was anything confusing?" "What's one thing you'd change?"
4. Record their answers in your playtesting log. Repeat with a second playtester (this can happen across this lesson and the start of Lesson 6 if needed).
5. Look at both sets of feedback - are there common themes? Prioritise 2 changes you'll make based on what you heard.

By the end of this lesson you will be able to make targeted changes based on playtester feedback, and submit Task 5 with a completed playtesting log and reflection.

1. Implement the 2 priority changes you identified at the end of Lesson 5. For each, write a brief note in your playtesting log: what feedback prompted this, and what you changed.
2. If time allows, do a quick second playtest with the same or a different classmate - does the change improve things?
3. Do a final full playthrough yourself: confirm levels/difficulty progression works, sounds play correctly, and visuals look polished.
4. Finish your playtesting log - make sure it includes feedback from at least 2 testers and at least 2 documented changes.
5. Write your reflection (5-8 sentences): describe the iterative process - what feedback you received, what you changed, and whether the changes improved the game. Use the words "iteration," "playtesting," and "feedback" correctly.

Plug in a classroom Logitech controller and try it with any browser-based game that supports gamepads - notice how it's recognised. Student-led.

By the end of this lesson you will be able to connect a Logitech controller to your computer and research how GDevelop detects and uses gamepad input.

1. Connect your classroom Logitech controller via USB. Most modern browsers and GDevelop's preview will detect it automatically - no extra software needed.
2. In GDevelop, look in the events sheet for conditions related to "Gamepad" or "Joystick" - explore what's available (button presses, analog stick positions, triggers).
3. Research: search for "GDevelop gamepad controller tutorial" and read through how others have set up controller support. Note down the general approach.
4. Plan your mapping: start a controller mapping document. List your game's current actions (move up/down/left/right, score action, etc.) and which controller input you'll map each to (e.g. left analog stick = movement, A button = action).
5. Test that your controller is detected in a GDevelop preview - even before adding any events, check the "gamepad connected" condition shows true when you press a button.

By the end of this lesson you will be able to add events that move your player character in response to controller stick or D-pad input, alongside your existing keyboard events.

1. Open your existing movement events from Task 4 (Lesson 3). For each direction, you'll add an additional condition for controller input.
2. Add a new event: Condition = "Gamepad: left analog stick moved right" (or equivalent D-pad button), Action = same movement action as your keyboard "right" event.
3. Repeat for left, up, and down - either as separate events alongside your keyboard ones, or by adding the controller condition as an "OR" to your existing events if GDevelop's interface supports it cleanly.
4. Preview your game with the controller connected. Test movement in all 4 directions using the controller, then test again with the keyboard - both should work.
5. Update your controller mapping document: confirm which stick/D-pad inputs are now mapped to movement.

Kahoot teacher-run quiz on Module 2 concepts so far. Student-led from there - just join and play!

By the end of this lesson you will be able to map a non-movement action (e.g. jump, shoot, interact) to a controller button, and thoroughly test both keyboard and controller play.

1. Identify one non-movement action in your game - this might be jumping, shooting, an interaction, or pausing. Find the existing keyboard event for this action.
2. Add a controller condition for a face button (e.g. "Gamepad button 0 pressed" - often the A/X button depending on controller layout) that triggers the same action.
3. Preview and test: with the controller connected, confirm the button press triggers the action correctly. Then disconnect (or ignore) the controller and confirm the keyboard still triggers it too.
4. Update your controller mapping document with this new button assignment - be specific (e.g. "Button 0 (bottom-right face button) = Jump").
5. Do a full test playthrough using ONLY the controller, start to finish. Note any moments where something doesn't respond as expected.

By the end of this lesson you will be able to identify and fix remaining bugs, and ensure your game runs stably for a live showcase.

1. Do at least 3 full playthroughs of your game - once with keyboard only, once with controller only, and once switching between both mid-game. Note any bugs or unexpected behaviour.
2. Fix any bugs found. Common issues at this stage: controller and keyboard inputs conflicting (e.g. character moving twice as fast when both are used), or controller inputs not being recognised after a scene change.
3. Review your whole game one more time against your original Task 4 design notes and Task 5 additions - does everything still work together (levels/difficulty, sounds, visuals, controller)?
4. Prepare for the showcase: think about how you'll demonstrate your game in 1-2 minutes. What will you show first? What's the "highlight" moment you want classmates to see?
5. Finalise your controller mapping document - it should be clear enough that someone else could pick up the controller and know what each button does.

Think about a presentation or demo you've seen that was engaging. What made it work? Discuss with a classmate. Student-led.

By the end of this lesson you will be able to plan and rehearse a short, clear presentation of your finished arcade game.

1. Plan your showcase presentation (aim for 1-2 minutes): introduce your game's core mechanic and theme, demonstrate gameplay with the controller, point out one feature you're proud of (e.g. the difficulty progression, a sound effect, the controller mapping).
2. Practice your demo at least twice with a classmate. Time yourself - is it too long, too short, too rushed?
3. Get feedback from your practice run: was your explanation clear? Did the controller demo work smoothly?
4. Make any final small adjustments based on this feedback - to either your game or your presentation plan.
5. Write a brief outline (3-5 bullet points or sentences) of what you'll say and show during the showcase - this can be informal notes for yourself.

By the end of this lesson you will have presented your finished arcade game to the class, and submitted all Task 6 materials with a final reflection.

1. Showcase time! Present your game to the class (or in small groups, depending on class size) following your plan from Lesson 5 - introduce, demo with the controller, highlight one feature.
2. While watching classmates' showcases, note one thing you found interesting or impressive about a different game - you might use this as inspiration for your Module 4 capstone later in the year.
3. After the showcase, write your reflection (5-8 sentences): describe your controller mapping approach, one challenge in getting controller input to work correctly, and how your game changed across Tasks 4, 5, and 6.
4. Do a final check of your project file - make sure it's the most up-to-date version with controller support included.
5. Gather your final files: your GDevelop project, controller mapping document, and reflection.

Think of 3 web apps or websites you use regularly (school portal, a tracker, a game site). For each, what's the ONE main problem it solves for you? Discuss with a classmate. Student-led.

By the end of this lesson you will be able to identify a specific, realistic problem that a web app could help solve, and write a clear problem statement.

1. Brainstorm 5 problems you, your classmates, or your school face that involve organising information, tracking something, or making a decision. Examples: tracking homework across subjects, a roster for shared equipment, a habit tracker, a study timer, a simple quiz/flashcard tool.
2. For each idea, ask: who has this problem? How do they currently deal with it (or not)? Could a simple web app genuinely help?
3. Narrow to your top 2 ideas. For each, write 1-2 sentences describing the problem and who it's for.
4. Choose your final idea. Write your problem statement: "This app helps [who] to [do what], because currently [what's the problem]."
5. List 3-5 core features your app needs to solve this problem - keep it realistic for 3 weeks of planning + building static structure (you'll add interactivity in Task 8).

By the end of this lesson you will be able to create wireframes - simple layout sketches - for at least 2 screens of your web app.

1. A wireframe is a simple sketch showing where things go on a screen - boxes for content, lines for text, simple shapes for buttons. No colours or fonts needed yet - just layout.
2. List the screens your app needs (e.g. "Home / main view", "Add new item", "History / list view"). Most simple apps need 2-3 screens.
3. For your main screen, sketch: where is the title/heading? Where is the main content or input area? Where are any buttons or navigation?
4. Repeat for at least one more screen - what's different about it? How would a user get from this screen to the other one?
5. You can sketch on paper (photograph it) or use a simple digital tool (e.g. drawing in Google Slides/Docs, or a free wireframing tool your teacher suggests). Label each element clearly.

Kahoot teacher-run quiz on HTML/CSS basics from Year 9. Student-led from there - just join and play!

By the end of this lesson you will be able to create a user flow diagram showing how a user moves between your app's screens.

1. A user flow is a diagram showing the path a user takes through your app - boxes for screens, arrows for actions that move between them (e.g. "click 'Add' button" → goes to "Add Item screen").
2. Draw a box for each screen from your wireframes. Add arrows between boxes, labelling each arrow with the action that causes that transition (e.g. "Save button clicked").
3. Walk through your user flow as if you were a first-time user: starting from the home screen, can you reach every feature? Is there a way back to the home screen from every other screen?
4. If you find a "dead end" (a screen with no way back, or a feature with no path to reach it), update your wireframes or flow to fix it.
5. Finalise your wireframes and user flow - these are part of your Task 7 submission.

By the end of this lesson you will be able to build the HTML structure for your main screen using semantic elements that match your wireframe.

1. Create a new folder for your project, with index.html and style.css inside it.
2. Set up the basic HTML skeleton with semantic elements matching your wireframe:
   <!DOCTYPE html>
   <html lang="en">
   <head>
   <meta charset="UTF-8">
   <title>My App</title>
   <link rel="stylesheet" href="style.css">
   </head>
   <body>
   <header><h1>My App Name</h1></header>
   <nav><!-- navigation links --></nav>
   <main><!-- main content goes here --></main>
   <footer><p>&copy; 2026</p></footer>
   </body>
   </html>
3. Inside <main>, add the content elements your wireframe shows - headings, paragraphs, lists, input areas (even if not yet functional), buttons. Use <section> to group related content.
4. Open index.html in a browser. Does the order of content roughly match your wireframe, even unstyled?
5. Add placeholder text/content for anything not yet finalised - you can refine wording later. The goal today is structure.

Open Flexbox Froggy and complete a few levels - a fun way to practice flexbox properties. Student-led.

By the end of this lesson you will be able to use flexbox or grid in CSS to lay out your page's sections according to your wireframe.

1. In style.css, link your stylesheet (already done in Lesson 4) and start with basic resets:
   * {
   box-sizing: border-box;
   }
   body {
   font-family: Arial, sans-serif;
   margin: 0;
   }
2. Use flexbox for one-directional layouts (e.g. a row of navigation links, or items side-by-side):
   nav {
   display: flex;
   gap: 16px;
   padding: 12px;
   }
3. Use grid for two-dimensional layouts (e.g. a card grid):
   .card-grid {
   display: grid;
   grid-template-columns: repeat(2, 1fr);
   gap: 16px;
   }
4. Apply flexbox or grid to at least 2 sections of your page to match your wireframe's layout - e.g. navigation as a flex row, and any list/grid of items using CSS grid.
5. Check your page in the browser, resizing the window - does the layout hold together reasonably well at different widths?

By the end of this lesson you will be able to finalise your static HTML/CSS structure, check it against your planning documents, and submit Task 7 with a reflection.

1. Compare your index.html + style.css against your wireframes from Lesson 2 - does the layout match reasonably closely? Note any differences.
2. Add basic styling polish: consistent spacing (margin/padding), a simple colour scheme (2-3 colours), and readable font sizes. Keep it simple - you'll add more in Task 9.
3. If your app needs a second screen (from your user flow), you can create a second HTML file now (e.g. add.html) sharing the same stylesheet - or note this as next steps for Task 8.
4. Test your page in the browser one more time - check for broken layout, unclosed tags (use your code editor's error highlighting), and that navigation links (even if not yet functional) are visible.
5. Write your reflection (5-8 sentences): describe your app's purpose, how your wireframes and user flow shaped your HTML structure, and one decision you changed between planning and building.

Open any website, right-click, and choose "Inspect" - explore the Elements panel and find the HTML behind something on the page. Student-led.

By the end of this lesson you will be able to link a JavaScript file to your HTML, select page elements using querySelector, and change their content.

1. Create script.js in your project folder. Link it at the bottom of your HTML's <body>:
   <script src="script.js"></script>
   </body>
2. Test it's connected - add this to script.js and check your browser's console (F12 / Inspect → Console):
   console.log("script.js is connected!");
3. Use querySelector to select an element from your HTML (e.g. your main heading):
   const heading = document.querySelector("h1");
   console.log(heading);
4. Change the selected element's content:
   heading.textContent = "Welcome - JavaScript is working!";
5. Try selecting a different element by its id or class (you may need to add an id to it in your HTML first), and change its text or style.

By the end of this lesson you will be able to make a button or form respond to user interaction using addEventListener.

1. If you don't have a button or form in your HTML yet, add a simple one based on your wireframe - e.g. an input field and a button:
   <input type="text" id="taskInput" placeholder="Enter a task">
   <button id="addBtn">Add</button>
   <ul id="taskList"></ul>
2. In script.js, select the button and add a click listener:
   const addBtn = document.querySelector("#addBtn");
   addBtn.addEventListener("click", function() {
   console.log("Button clicked!");
   });
3. Get the input's value when clicked:
   const input = document.querySelector("#taskInput");
   addBtn.addEventListener("click", function() {
   console.log(input.value);
   });
4. If you're using a <form> element instead of a standalone button, listen for the "submit" event and call event.preventDefault() to stop the page from reloading.
5. Test: type something in the input, click the button (or submit the form), and confirm the console shows the value you typed.

Kahoot teacher-run quiz on JavaScript basics from Week 4. Student-led from there - just join and play!

By the end of this lesson you will be able to create new HTML elements with JavaScript and add them to the page dynamically.

1. Building on Lesson 2's button and input, create a new list item element when the button is clicked:
   const taskList = document.querySelector("#taskList");
   
   addBtn.addEventListener("click", function() {
   const li = document.createElement("li");
   li.textContent = input.value;
   taskList.appendChild(li);
   input.value = ""; // clear the input
   });
2. Test: type something and click "Add" - a new list item should appear, and the input should clear, ready for the next entry.
3. Add input validation: don't add empty items. Check input.value.trim() !== "" before creating the new element.
4. Write a function addItem(text) that takes the text as a parameter and does the create/append logic - then call it from your event listener with addItem(input.value).
5. Bonus: add a small "✕" button inside each new list item that, when clicked, removes that item from the list (using .remove()).

By the end of this lesson you will be able to save data to the browser's localStorage so it isn't lost when the page is refreshed.

1. So far, refreshing the page loses your list - localStorage fixes this. It stores data as strings, so we use JSON.stringify() to convert other data types:
   let tasks = []; // array to hold our task data
   
   function saveTasks() {
   localStorage.setItem("myTasks", JSON.stringify(tasks));
   }
2. Update your addItem(text) function from Lesson 3 to also add to the tasks array and call saveTasks():
   function addItem(text) {
   tasks.push(text);
   // ...existing code to create and append the li...
   saveTasks();
   }
3. Open your browser's DevTools → Application/Storage tab → Local Storage. After adding an item, confirm you can see "myTasks" with your data stored as a JSON string.
4. Refresh the page - notice the visible list disappears (we haven't loaded it back yet - that's next lesson), but the data in localStorage remains.

Open Kahoot teacher-run quiz on Weeks 4-5 JavaScript concepts. Student-led from there - just join and play!

By the end of this lesson you will be able to load previously saved data from localStorage when the page loads, and display it on the page.

1. Write a function loadTasks() that reads from localStorage, and handles the case where there's nothing saved yet:
   function loadTasks() {
   const saved = localStorage.getItem("myTasks");
   if (saved) {
   tasks = JSON.parse(saved);
   } else {
   tasks = [];
   }
   }
2. After loading, display each saved task on the page by looping through tasks and calling the same "create element and append" logic from Lesson 3 (consider refactoring this into its own function, e.g. renderTask(text), used by both addItem and loadTasks).
3. Call loadTasks() when the script first runs (e.g. at the bottom of script.js).
4. Test: add a few items, refresh the page - your items should still be there! Try closing and reopening the browser tab too.
5. If you added a "remove" button in Lesson 3, update it to also remove the item from the tasks array and call saveTasks() again, so removals persist too.

By the end of this lesson you will be able to thoroughly test your app's interactivity, fix console errors, and submit Task 8 with a reflection.

1. Open the browser console (F12) and use your app normally - adding items, removing items (if implemented), refreshing. Are there any red error messages? Fix them one at a time.
2. Test edge cases: what happens if you submit an empty input? What if you add many items - does the layout still look okay (check your CSS from Task 7 still works with dynamically added elements)?
3. Clear your localStorage (DevTools → Application → Local Storage → right-click → Clear) and reload - does your app handle "no saved data" gracefully (no errors, sensible empty state)?
4. If you have time, add one small improvement - e.g. a "Clear all" button, a counter showing how many items are saved, or basic styling for the dynamically added items.
5. Write your reflection (5-8 sentences): explain how your HTML, CSS, and JavaScript work together, describe how localStorage makes your app "remember" data, and describe one bug you fixed and how.

Open your app in the browser, then open DevTools (F12) and toggle "Device Toolbar" / responsive mode - see how it looks on a phone-sized screen. Student-led.

By the end of this lesson you will be able to identify layout issues on smaller screens and use media queries to fix them.

1. Using DevTools' responsive/device mode, view your app at a phone width (e.g. 375px). Note any issues: text too small, elements overflowing, navigation taking up too much space.
2. Add the viewport meta tag if you don't already have it - this tells mobile browsers to use the actual device width:
   <meta name="viewport" content="width=device-width, initial-scale=1.0">
3. Use a media query to adjust styles for narrow screens:
   @media (max-width: 600px) {
   nav {
   flex-direction: column;
   }
   h1 {
   font-size: 1.5rem;
   }
   }
4. Test your media query by resizing the browser window or using device mode - confirm the layout adapts at the breakpoint.
5. Fix at least 2 specific issues you noticed in step 1 using media queries or flexible units (e.g. switching a flex-direction from row to column on small screens).

By the end of this lesson you will be able to prepare your project files for deployment, ensuring everything is organised and working correctly.

1. Check your file structure: your main page should be named index.html (GitHub Pages looks for this by default). CSS and JS files should be correctly linked with relative paths (not full file paths from your computer).
2. Test your app one more time from a completely fresh state - clear localStorage, reload, and use the app as if for the first time.
3. Remove any leftover console.log() statements you used for debugging (unless intentional), and tidy up your code formatting.
4. Double-check all links (navigation, images, stylesheets, scripts) use relative paths like "style.css" or "script.js" rather than absolute paths like "C:/Users/..." - absolute paths will break when deployed.
5. Make a checklist for yourself: app works fully offline (locally), file structure is clean, all paths are relative, viewport meta tag present, no console errors. Tick each off before Lesson 3.

Kahoot teacher-run quiz on Weeks 1-7 web app concepts. Student-led from there - just join and play!

By the end of this lesson you will be able to deploy your web app to a live URL using GitHub Pages.

1. If you don't already have one, create a free GitHub account (check with your teacher about school account policies first).
2. Create a new repository (e.g. named after your app). Upload your project files - index.html, style.css, script.js - via GitHub's web interface (drag and drop files works fine for this).
3. In your repository's Settings, find the "Pages" section. Set the source to your main branch and root folder. Save.
4. GitHub will provide a URL (usually https://yourusername.github.io/repository-name/) - it may take a minute or two to become live.
5. Visit your live URL. Test everything: does the page load? Does the styling apply? Does your JavaScript and localStorage work the same as it did locally?

1. Go to app.netlify.com/drop.
2. Select your entire project folder and drag it onto the page (or click to browse). Netlify will deploy it automatically.
3. You'll get a randomly-named live URL (e.g. random-name.netlify.app) within seconds. Copy it and test it in your browser.
4. Note: the free drop URL expires after 24 hours unless you create a free Netlify account to claim it. Ask your teacher whether you need to do this for submission.

1. ZIP your project folder (right-click → Compress/Send to Zip).
2. Go to tiiny.host, upload your ZIP file, and enter a subdomain name for your site.
3. Click "Upload" - you'll get a live URL at yourname.tiiny.site within seconds. Test it.

By the end of this lesson you will be able to conduct user testing on your live, deployed web app and record useful feedback.

1. Start your user testing log - columns: Tester Name, Device/Browser Used, Feedback, Planned Change.
2. Share your live URL with a classmate (via the classroom chat, written down, or however your teacher suggests). Ask them to open it on their own device/browser.
3. Without giving instructions, ask them to try using your app for its intended purpose. Watch (or ask them to describe) what they do.
4. Ask 3 questions: "What did you understand the app was for?" "Did everything work as expected on your device?" "What's one thing you'd improve?"
5. Record their responses. Repeat with a second classmate - ideally on a different device/browser if possible (e.g. one on a laptop, one on a phone).

Kahoot teacher-run quiz reviewing the full deployment process. Student-led from there - just join and play!

By the end of this lesson you will be able to make changes based on user feedback, update your live deployment, and document the changes in a changelog.

1. Review your user testing feedback from Lesson 4. Choose at least 2 specific, achievable changes to make - prioritise things that affect usability the most.
2. Make the changes to your local files first. Test locally to confirm they work as expected.
3. Redeploy using whichever platform you used in Lesson 3:
   • GitHub Pages: upload the updated files to your repository (replacing old versions). Wait 1-2 minutes, then check your live URL.
   • Netlify Drop: drag your updated project folder onto app.netlify.com/drop again. You'll get a new URL - update your submission notes.
   • Tiiny.host: re-upload your updated ZIP with the same subdomain name to overwrite the previous version.
4. Start your changelog - a simple list: "Change 1: [what changed] - based on feedback from [tester] who said [brief summary]." Repeat for each change.
5. If time allows, do a final quick re-test with one of your original testers - does the change address their feedback?

By the end of this lesson you will be able to finalise your live web app, complete your changelog, and submit Task 9 with a reflection on the full Module 3 journey.

1. Do a final check of your live URL - open it fresh (e.g. in a private/incognito window) and confirm everything works as expected from a "new visitor's" perspective.
2. Finalise your changelog - make sure it includes at least 2 documented changes with the feedback that prompted them.
3. Write your Module 3 reflection (5-8 sentences). Include: a brief summary of your app's journey from problem statement (Task 7) to live deployment (Task 9); one specific piece of user feedback and how you responded; and one thing you'd do differently if you started again.
4. Gather your final materials: your live URL, updated HTML/CSS/JS files, user testing log, changelog, and reflection.

Think back over Year 10: Python (functions, files, OOP), GDevelop arcade games, and web apps. Which of these did you enjoy most? Discuss with a classmate. Student-led.

By the end of this lesson you will be able to review your skills from Years 9 and 10, and choose a capstone direction that builds on what you've learned.

1. Make a quick skills inventory: list the tools and skills you've used this year - Python (functions, files, lists, dictionaries, classes), GDevelop (game design, events, controllers), and web development (HTML, CSS, JavaScript, localStorage, deployment).
2. For each area, rate your confidence (1-5) and interest (1-5). Where are your highest combined scores?
3. Brainstorm 3 capstone ideas, each building primarily on one area: a Python idea (e.g. an expanded simulation, a data tool, a text-based game with save files), a game idea (e.g. a new GDevelop game with a different genre or mechanic), and a web app idea (e.g. a new app solving a different problem, or a significant expansion of your Task 9 app).
4. You can also combine areas - e.g. a web app with a Python backend script, or a game with a companion web page. Note any combination ideas too.
5. Discuss your 3 ideas with a classmate or your teacher - which feels most achievable AND most interesting to you?

By the end of this lesson you will be able to define your capstone project's goal and create a prioritised feature list.

1. Choose your final capstone idea from Lesson 1. Write a single clear goal statement: "My capstone project is a [type of project] that [does what], built using [technology]."
2. Brainstorm every feature you can think of for this project - don't filter yet, just list everything.
3. Sort your features into 3 categories: Must-have (the project doesn't work without these), Should-have (important but the project could function without them), and Nice-to-have (bonus, if time allows).
4. Check: do you have at least 3 must-have features? Is your must-have list realistic for 6 weeks? If it looks too big, move some features to "should-have" or "nice-to-have."
5. Write 1-2 sentences for each must-have feature describing what it does - this becomes the core of your proposal.

Kahoot teacher-run quiz reviewing project planning vocabulary. Student-led from there - just join and play!

By the end of this lesson you will be able to create a realistic week-by-week timeline for building your capstone project across Task 11 (Weeks 4-6) and Task 12 (Weeks 7-9).

1. You have 6 weeks of build time (Weeks 4-9), split across Task 11 (core development) and Task 12 (showcase and reflection - but Weeks 7-8 are still build time before the showcase in Week 9).
2. List your must-have features in the order you'll build them - usually, start with the foundational piece everything else depends on (e.g. the basic data structure or main screen) before adding features on top.
3. Assign each must-have feature to roughly 1-2 weeks. Be realistic - building AND testing a feature usually takes longer than just writing the code.
4. Add buffer: leave Week 8 or 9 lighter than the others, in case earlier features take longer than expected (they usually do!).
5. Write your timeline as a simple table: Week | Planned Work. This becomes part of your proposal.

By the end of this lesson you will be able to write specific, checkable success criteria for your capstone project.

1. For each must-have feature, write a success criterion that's specific and checkable - something you (or someone else) could verify by using the project. A vague example would be "The game should be fun." A specific example would be "A player can complete a full game (win or lose) without crashes, and the score updates correctly when collecting items."
2. Write at least 3 success criteria covering different aspects of your project: functionality (does it work?), usability (can someone else use it without help?), and completeness (does it do what your proposal says?).
3. Re-read your success criteria: could you check each one in under a minute by using your finished project? If not, make it more specific.
4. Combine your goal statement (Lesson 2), feature list, timeline (Lesson 3), and success criteria into a single draft proposal document.
5. Share your draft proposal with a classmate or the teacher for feedback before finalising.

Kahoot teacher-run quiz reviewing Module 1-3 vocabulary across the year. Student-led from there - just join and play!

By the end of this lesson you will be able to set up your chosen tool/environment and build a small proof-of-concept demonstrating it's ready for your capstone build.

1. Set up the tool/environment for your chosen technology: open Thonny for Python, GDevelop for a game, or create a new project folder with index.html/style.css/script.js for a web app.
2. Build a tiny "proof-of-concept" - the smallest possible working piece that proves your chosen approach will work. Examples: a Python program that creates and saves one object using the class structure you're planning; a GDevelop scene with one object that responds to one input; a webpage with one element that JavaScript can select and change.
3. Run/preview your proof-of-concept. Does it work without errors? This confirms your tool is set up correctly and your basic approach is viable.
4. Note down anything you learned from building this small piece - did anything take longer than expected? Does it change your timeline at all?
5. Save your proof-of-concept - you'll likely build directly on top of it in Task 11.

By the end of this lesson you will be able to finalise your capstone proposal document and submit it with your proof-of-concept and a reflection.

1. Compile your final proposal document with these sections: Goal statement, Feature list (prioritised), Timeline (Weeks 4-9), Success criteria.
2. Re-read your whole proposal as if you were someone else reading it for the first time - is it clear what you're building, why, and how you'll know it's done?
3. Address any feedback you received in Lesson 4 - make final adjustments to scope, timeline, or success criteria if needed.
4. Make sure your proof-of-concept from Lesson 5 is saved and ready to share.
5. Write your reflection (5-8 sentences): explain why you chose this project, how it connects to what you've learned in Year 9/10, and one thing you're looking forward to (or worried about) building.

By the end of this lesson you will be able to break your first must-have feature into small steps and begin building it from your Task 10 proof-of-concept.

1. Open your proof-of-concept from Task 10. Re-read your timeline - what's the first must-have feature you planned to build?
2. Break this feature into 3-5 small steps. For example, "add/save data" might break into: create the data structure, write a function to add an item, write a function to save it, test saving works, then connect it to the user interface.
3. Start your progress log now - create a simple document or text file with a heading for "Week 4" and note today's date and what you're starting.
4. Work through your first 1-2 small steps. Test as you go - don't write everything then test at the end.
5. At the end of the lesson, add to your progress log: what you completed, what's next, and anything that surprised you (took longer/shorter than expected, or worked differently than planned).

By the end of this lesson you will be able to complete your first must-have feature and test it against the success criteria from your proposal.

1. Continue building your first feature from Lesson 1's remaining steps.
2. Once complete, test it against the relevant success criterion from your Task 10 proposal - does it actually meet what you wrote down? Be honest.
3. If it doesn't fully meet the criterion yet, note in your progress log what's missing and whether you'll fix it now or come back to it.
4. If your first feature is working well, start breaking down your second must-have feature into small steps, the same way as Lesson 1.
5. Update your progress log: Feature 1 status (complete/partial), and what you're starting for Feature 2.

Kahoot teacher-run quiz reviewing debugging strategies from across the year. Student-led from there - just join and play!

By the end of this lesson you will be able to use systematic debugging strategies to fix problems in your capstone build, and document at least one in your progress log.

1. Continue building Feature 2 (or Feature 3 if Feature 2 is done). When something doesn't work as expected, don't panic - this is normal and expected.
2. Use a systematic approach: read any error message carefully (what line? what type of error?). Isolate the problem - comment out or temporarily simplify code until you find exactly what's causing the issue.
3. Add temporary print/console statements (Python) or console.log (JavaScript), or use GDevelop's debugger, to see what values your variables actually hold at each step.
4. Once you find and fix a genuine problem, write it up in your progress log: what was the symptom (what went wrong)? What was the actual cause? How did you fix it?
5. If you're stuck after trying these strategies for 10-15 minutes, that's the point to ask a classmate or the teacher - document that you asked for help too.

By the end of this lesson you will be able to honestly review your progress against your Task 10 timeline, and adjust your plan if needed.

1. You're now halfway through Task 11 (Week 5 of 6). Open your Task 10 timeline and your progress log side by side.
2. For each must-have feature, mark its status: done, in progress, or not started.
3. Be honest: are you on track, ahead, or behind your original timeline? This is completely normal either way - the important thing is recognising it now.
4. If you're behind: which remaining must-have features are most critical? Could any "should-have" or "nice-to-have" features be dropped to focus on must-haves? Update your timeline to reflect a realistic plan for Week 6 and Task 12.
5. If you're ahead: could you start on a "should-have" feature, or use the extra time to improve testing/polish on what's already built?
6. Write an updated timeline section in your progress log reflecting this check-in - this is exactly what the "Updated Timeline" part of your Task 11 submission should show.

Kahoot teacher-run quiz reviewing the full year's DigiTech vocabulary. Student-led from there - just join and play!

By the end of this lesson you will be able to continue building your remaining must-have features, integrating them with what's already working.

1. Following your updated timeline from Lesson 4, continue building your remaining must-have feature(s).
2. As you add each new feature, test that it works WITH your existing features, not just on its own - e.g. if Feature 1 saves data and Feature 2 displays it, confirm displaying actually shows what was saved.
3. Keep your progress log updated as you go - what you built, any issues, any further timeline adjustments.
4. If you finish all must-have features with time remaining, test everything together as a "mini end-to-end test" - use your project the way a real user would, start to finish.
5. Note in your progress log how many must-have features are now complete, and what's planned for Task 12 (Weeks 7-9).

By the end of this lesson you will be able to finalise your progress log and updated timeline, and submit Task 11 with a reflection connecting your progress to your success criteria.

1. Do a final check of your build - save your project file, and make sure it's the most recent working version.
2. Finalise your progress log - check it has an entry for every week (Weeks 4-6), including the problem you documented in Lesson 3.
3. Finalise your updated timeline from Lesson 4 - this should clearly show any changes from your original Task 10 plan, with brief reasons.
4. Write your reflection (5-8 sentences): which must-have features are complete? How do they measure up against your Task 10 success criteria? What's your plan for Task 12 (Weeks 7-9)?
5. Gather your final files: your project build, progress log, updated timeline, and reflection.

Think back to Week 1, Term 1 of Year 10. What did you know how to do then, compared to now? Discuss with a classmate. Student-led.

By the end of this lesson you will be able to complete any remaining must-have features, prioritising based on your Task 11 updated timeline.

1. Review your Task 11 updated timeline and progress log - what's left to do for your must-have features?
2. If all must-haves are done, this is a great position - consider whether a "should-have" feature would meaningfully improve your showcase, or whether your time is better spent on polish (Lesson 2) and presentation prep (Lesson 4).
3. If must-haves remain, prioritise based on which most directly affects your success criteria. Work through them using the same small-steps, test-as-you-go approach from Task 11.
4. Update your progress log with today's work.
5. By the end of this lesson, aim to have a version of your project that meets at least 2 of your must-have success criteria, even if not perfectly polished yet.

By the end of this lesson you will be able to polish your capstone project and conduct thorough final testing.

1. Do at least 2 full run-throughs of your project as if you were a first-time user. Note anything confusing, broken, or unfinished-looking.
2. Fix any bugs found. Prioritise bugs that affect your must-have success criteria over small cosmetic issues.
3. Add polish where time allows: clearer labels/instructions, consistent visual style, removing any leftover debug code or placeholder text.
4. If your project has any "rough edges" you won't have time to fix, that's okay - note them honestly for your reflection rather than hiding them.
5. Save a clearly labelled "final" version of your project.

Kahoot teacher-run quiz reviewing Module 4 concepts so far. Student-led from there - just join and play!

By the end of this lesson you will be able to honestly evaluate your finished project against every success criterion from your Task 10 proposal.

1. Open your Task 10 proposal and list every success criterion you wrote.
2. For each one, test your finished project and record: Met / Partially Met / Not Met, with a brief explanation (1-2 sentences) of what you found.
3. For anything "Partially Met" or "Not Met," briefly explain why - was it a time issue, a technical difficulty, or did your understanding of the problem change as you built it?
4. This becomes your "Final Success Criteria Check" document - a simple table: Criterion | Status | Explanation.
5. Look at the overall picture: how many criteria were fully met? Does this feel like a successful project to you - and why or why not?

By the end of this lesson you will be able to plan and rehearse a short presentation of your finished capstone project.

1. Plan your showcase presentation (aim for 1-2 minutes): briefly introduce your project's goal (what problem does it solve, or what does it do?), demonstrate it live, highlight one feature you're proud of, and mention one challenge you overcame.
2. Practice your presentation at least twice with a classmate. Time yourself.
3. Get feedback: was your explanation clear? Did the live demo go smoothly? Is there anything you should show differently?
4. Make any final small adjustments based on feedback - to your presentation plan, or to your project if a quick fix would improve the demo.
5. Write a brief outline (3-5 points) of what you'll say and show - informal notes for yourself are fine.

Kahoot teacher-run quiz reviewing the full Year 10 course. Student-led from there - just join and play!

By the end of this lesson you will have presented your finished capstone project to the class and reflected on what you saw from classmates.

1. Showcase time! Present your project to the class (or in small groups, depending on class size) following your plan from Lesson 4.
2. While watching classmates' showcases, take brief notes on at least 2 projects: what did they build? What's one thing you found interesting or impressive?
3. If there's time, give brief positive feedback to at least one classmate about their project - be specific (e.g. "I liked how your save system worked" rather than just "good job").
4. After all showcases, reflect briefly: how did your presentation go? Did the live demo work as expected?
5. Keep your presentation notes and any feedback received - you'll use this in your final reflection.

By the end of this lesson you will be able to write a final reflection connecting your capstone project to your growth across Year 10, and submit Task 12.

1. Finalise your Success Criteria Check document from Lesson 3 if you haven't already.
2. Write your final reflection (8-12 sentences). Include: a summary of your capstone project and what it does; how it went against your success criteria - including anything not fully met, and why; one challenge you faced and how you handled it; and how this project connects to specific skills from earlier in Year 10 (Python, GDevelop, web development) - or even back to Year 9.
3. Think back to Week 1, Term 1 of Year 10. What did you know how to do then, compared to now? Add a sentence or two about this growth to your reflection.
4. Do a final save of your project, making sure it's the version you presented (or your most polished version if changes were made after the showcase).
5. Gather your final materials: your finished project, Success Criteria Check, and final reflection.