ENDE
Start creating

For teachers

Game logic in class

A lesson-planning path, not a technical one: how to split variables, conditions and character interaction across single lessons, and how to judge the result without playing twenty-five projects yourself.

Audience
Teachers, classes aged 8–14
Length
3 to 4 lessons
Before this
Pocket Code intro completed
A thick path running in from the left that splits at a diamond into two branches, one going up and one going down, each ending in a small square.

Three ideas, three lessons

  1. 01

    Give the game something to remember

    Start with a single variable the class can see change, such as a score or a count. Keep it to one variable and one clear trigger, a tap, a collision, a timer, so every pupil can point at the moment it changes. This lesson does not need to look like a game yet; it needs to look like a number that responds to something.

  2. 02

    Give the game something to decide

    Once there is a variable to test, add a single condition built on it: above a number, below it, equal to it. Ask pupils to predict what happens before they run it, then check whether the character actually does two different things depending on the test. A condition without a visible difference between its outcomes is hard to mark and harder to understand, so keep both branches on screen.

  3. 03

    Make characters react to each other

    This is where the previous two lessons combine: one character's variable or condition now depends on what another character does. It is the hardest of the three steps, because two separate scripts have to agree on what a message or a collision means, and it is worth the extra lesson slot the facts above allow for. Treat a working interaction between two characters as the finish line for this path, not a stretch goal.

Splitting the concepts across lessons

Variables, conditions and character interaction are usually taught as three separate ideas, and that is the safest way to fit them into single lesson slots. Trying to cover all three in one sitting leaves the weaker half of the class behind by the second idea, and leaves nothing finished if the lesson gets cut short by a fire drill or an assembly.

The order matters. Variables come first because they are the easiest to make visible: a number on screen that changes when something happens. Conditions come second, because a condition needs something to test, and a variable is the simplest thing to test against. Character interaction comes last and is the hardest of the three, since it usually means combining both earlier ideas inside two separate scripts that have to agree with each other.

A fourth lesson, where classes that moved through the first three quickly put a small project together using all three ideas, is worth keeping as an optional extension rather than a fixed requirement. Not every class needs it, and making it compulsory risks the same problem as covering everything on day one.

Borrowing examples from outside programming

None of these three ideas are new to a class that has never coded. A variable is the same shape as a running total in maths or a tally kept during a science experiment: a value that starts somewhere and changes as something happens. A condition is the same shape as an if/then rule a class already uses when marking punctuation in an English exercise or reading the key on a map.

Naming the concept in the vocabulary of the lesson it is borrowed from, rather than insisting on the word 'variable' from the first sentence, can lower the barrier for pupils who are still building confidence with the software itself. Pocket Code and Create@School were both built around exactly this idea: the coding is a means to a subject outcome, not the subject itself.

What confusion looks like on the screen

You will not usually hear a pupil say they have misunderstood a variable or a condition. You will see it on screen instead, and the same handful of patterns turn up in most classes.

  • A variable that is set once at the start and never updated again, because it is being used as a label rather than a value that changes.
  • A condition with no else path, so the character simply does nothing when the test fails instead of showing a clear alternative.
  • Two characters that look like they are reacting to each other but are actually running on independent timers that happen to line up.
  • A score variable that climbs every time its block runs, when it was only meant to change once, because the trigger fires on every frame.
  • A condition copied from one character to another that still checks a variable that only exists on the original.

Marking without playing every project, and living with different speeds

Twenty-five projects cannot be played from start to finish in the time available, and they do not need to be. Because each lesson is built around one visible outcome, a project can be checked for that outcome in the few seconds it takes to see whether the variable changes, whether the condition produces two different results, or whether the two characters visibly respond to each other.

The pacing problem is the one every teacher raises first: in any class of 25, some pupils will be finished within ten minutes and others will still be working when the lesson ends. Neither is a sign that the lesson has failed. Fast finishers can be pointed at a second variable, a second condition, or a small extension to the same script rather than a new task, which keeps them inside the same lesson's concept instead of racing ahead into the next one. Pupils who do not finish can still be marked on whatever stage they reached, because the visible outcome for each lesson is small enough to be partially achieved and still show understanding.

Keep the extension work optional and keep the core task small enough that most of the class reaches the visible outcome inside the lesson. A task that only the fastest third of the class ever completes is not testing understanding of variables, conditions or interaction. It is testing typing speed.