-
Notifications
You must be signed in to change notification settings - Fork 1
Teaching Chapter VI
Teacher-facing notes for running Chapter VI in class.
| Sections | 10 (1 tutorial, 9 exercises) |
| Estimated time | 2 weeks for a mixed-ability Year 9 class (8 to 10 lessons) |
| Prerequisites | All of Chapters I through V. Functions with parameters (especially position parameters) are essential. |
| Live chapter | dbbudd.github.io/06.html |
Students leave able to: decompose a real-world object into primitive geometric shapes, compose multiple function calls from Chapter V into a coherent scene, position shapes using coordinate arithmetic, and reason about layering (z-order) in 2D drawings.
The mathematics. Composite figures: shapes built by combining simpler shapes. Decomposition: breaking a complex real-world object into primitive shapes the student already knows how to draw. Coordinate arithmetic: placing shapes relative to each other using anchor coordinates. The area of a composite figure by summing and subtracting its components (inclusion and exclusion, first introduced in Chapter II).
The programming. Composition: calling multiple functions from a main routine. Z-order (layering): shapes drawn later appear on top of shapes drawn earlier, so the order of function calls matters. The accumulator pattern: tracking a running offset as you place a row of shapes. Structuring a program as a main routine that orchestrates smaller functions. This is the first time students are writing code at the architectural level rather than the expression level.
Chapter VI is deliberately different from the others. There's only one tutorial (section 1, A Square) and the rest are nine progressive exercises that build from a single shape to a full neighbourhood scene. The sequence follows a classic "build, then compose, then elaborate" pattern that matches how students think about drawing.
Section 1 (A Square) is the tutorial. Draw a single square using a function call. Trivial compared to anything in Chapter V, but it establishes the chapter's pattern: every exercise is "write a function that draws one thing".
Sections 2 and 3 (A Triangle, A Cross) are simple shape builders. One function per shape. Students are re-practising Chapter V skills with no new concepts.
Section 4 (A Church) is the first composite figure: a rectangle body with a triangle roof and a cross on top. Three function calls, carefully positioned. This is the a-ha moment of the chapter: the student realises they can combine the shapes from sections 2 and 3 into something bigger.
Section 5 (Row of Churches) adds the accumulator pattern: a loop that places several churches side by side, tracking the x-offset as it goes. This is the first time a loop, a function, and coordinate arithmetic all show up in the same code block.
Section 6 (A Pretty House) is the ambitious single-building exercise: a house with walls, a roof, a door, windows, maybe a chimney. Students decompose the house into 5 or 6 shapes and write a function for each, then compose them.
Sections 7 and 8 (A Fence Post, A Whole Fence) teach the pattern of "build the unit, then repeat the unit". A fence post is one tall rectangle; a whole fence is many of them side by side, connected by horizontal rails. The rail is drawn last so it appears on top of the posts (z-order).
Section 9 (Broom Broom) is the car: a body, wheels, maybe windows. Uses circles (which students haven't really used much until now) as wheels.
Section 10 (Neighbourhood Scene) is the capstone. Students compose houses, fences, a car, maybe a church, maybe a tree, into one complete suburban scene. There's no single correct answer; this is creative work. The assessment is less about correctness and more about decomposition and composition: did the student break the scene into sensible primitives?
The idea that big programs are built from small functions, called in the right order. This is true of every software system ever built, from shell scripts to operating systems. A student who leaves Chapter VI thinking "the house is just three functions and some coordinate arithmetic" has internalised the most important principle in software engineering: decomposition.
The mathematical corollary: complex shapes are just simple shapes in the right place. This is composite-figure thinking, and it's the approach students will use for the rest of Year 9, Year 10, and the foundational years of any STEM degree.
Students new to composition sometimes try to put the whole scene into one 100-line function. It works, technically, but it's unreadable and impossible to debug.
Fix: from section 4 onwards, enforce a "one function per visible thing" rule. A house is one function. A door is another function. A window is another function. The main routine just calls them in sequence. The code gets longer in line count but shorter in complexity.
It does. Drawing a house and then drawing a tree on top of it looks different from drawing the tree first and then the house on top. Students sometimes write the calls in a random order and are confused when a wheel ends up behind the car body.
Fix: use the phrase "z-order" or "painter's algorithm" to give the concept a name. Write on the board: "background first, foreground last". This is the rule every video game and animation tool uses. Students remember it because it's named.
Some students conclude that the maths is in the coordinates and the programming is easy. They have it backwards. The coordinates are just arithmetic; the programming is the architectural choice of how to decompose the scene. Coordinate arithmetic is routine; decomposition is the insight.
Fix: when you introduce Row of Churches (section 5), don't dwell on the x-offset arithmetic. Dwell on the accumulator pattern: "we have a variable called x, and every time we draw a church, we add the church width to x, so the next church is next to the previous one." That's the pattern. The arithmetic is secondary.
Some students are paralysed by the freedom of section 10. They want a specific spec. This is a sign of a student who has learned the mechanics of programming without yet trusting their own creativity.
Fix: give them a spec, but make it minimal: "draw three houses, a fence, a car, and a tree. Anywhere on the canvas." Then step back. Let them struggle with the freedom. When they finish, celebrate the specific choices they made.
For any composite exercise, start on paper before touching the iPad. Draw the target shape. Outline every primitive (rectangle, triangle, circle). Label each one with a name ("body", "roof", "chimney"). This step is the essence of composition and students skip it at their peril. Make it mandatory for sections 4, 6, and 10.
When you reach the first exercise where z-order matters (section 4, A Church, or section 8, A Whole Fence), do a live demo on the board or projector. Draw three overlapping shapes in one order, then redraw them in the opposite order, and ask students to identify what changed. The insight is immediate.
When you teach Row of Churches (section 5), name the pattern explicitly: "this is called the accumulator pattern". Then write on the board:
1. Start with a variable
2. Loop
3. Use the variable
4. Update the variable
5. Repeat
This is a pattern students will see in every programming context for the rest of their lives. Naming it here makes it memorable.
Section 10 (Neighbourhood Scene) is creative. Use it as formative assessment. You're not looking for a specific answer; you're looking for:
- Did the student decompose the scene into sensible primitives?
- Did the student use functions rather than copy-pasting?
- Did the student handle z-order correctly?
- Did the student use the accumulator pattern for repeated elements?
- Is the code readable? Can you scan it and understand what the scene contains?
Grade on those five criteria, not on "how good does the drawing look". The grade is about the thinking, not the art.
Section 10: Neighbourhood Scene. It's the hardest because it's the most open. There's no specific target to draw; the student has to invent the scene. For most students, the difficulty isn't the code; it's the creative decision-making.
How to teach it: run it across two lessons. Lesson 1 is planning. Students draw their scene on paper, label every primitive, write a list of the functions they'll need. No code yet. Lesson 2 is coding. They already know what to build; they just have to type it. The split makes the exercise feel manageable.
- A tree with branches. Using a simple recursive function (a preview of Chapter V or a bonus lesson). The tree grows fractally. Advanced and beautiful.
- A vehicle that moves. Use a loop to draw the same car multiple times at slightly different positions, creating a motion trail. Animation isn't in the curriculum, but this is a great bridge to it.
- A scaled version of their scene. Add a global scale factor variable. Change it from 1.0 to 0.5 and watch the whole neighbourhood shrink. This reinforces the similarity lesson from Chapter V.
- A winter version. Take their neighbourhood scene and make every shape white. Students realise that decomposition lets them reskin a whole scene by changing a few colour variables. Good lesson in the power of reusable code.
When introducing composition (section 4):
"Up to now, one function has been one shape. Now we're going to build something bigger by calling several functions from a main routine. A church is a body, a roof, and a cross. That's three function calls. The code is short. The result looks like a real building. This is how every computer graphic ever made works."
When explaining z-order (section 4 or 8):
"The order of your function calls is the order things get painted on the canvas. Later calls paint on top of earlier calls. If you want a wheel to be on top of a car body, you draw the body first, then the wheel. If you want a roof to be on top of a house, you draw the walls first, then the roof. This is called z-order, or the painter's algorithm. Background first, foreground last."
When introducing the accumulator pattern (section 5):
"You have a row of churches. How do you place them next to each other? You need to know how wide each one is, and you need to keep track of where the last one ended. That's the accumulator pattern: a variable that you update every time you place something. Let me show you."
When launching the Neighbourhood Scene (section 10):
"This is the final exercise of the whole curriculum. You're going to build a complete scene: houses, fences, cars, trees, whatever you want. I'm not going to tell you exactly what to draw. I'm going to tell you to plan it on paper first, break it into primitives, write a function for each primitive, and then compose them in a main routine. That's the entire skill you've been building across six chapters. Today is the day you use it for real."
Closing the course:
"Look at what you just drew. A month ago you drew a single line. Today you drew a neighbourhood. You didn't just learn Swift; you learned how to break a complicated thing into simple things, and put them back together. That's the skill. Everything else was the vehicle."
Fill this section in after your first classroom run.
- Chapter VI on the live site
- Previous: Teaching Chapter V
- Up: Home
Geometry Playground · a Swift Playgrounds curriculum for high school geometry · dbbudd.github.io · built by Daniel Budd