Unit 1.1 slides — software lifecycle, umbrella activities, task sets, SDLC methodologies, and the four Ps. Served live from bookSHelf; a push there updates this deck with no shCode rebuild.
How to print values with console.log and how JavaScript runs code top-to-bottom. Read before the A1.2 console lab.
Open the browser console, run five ready-made statements, then change two of them to print your own text. Auto-graded.
Learn what a program is, then write six lines of JavaScript with console.log() — text, math, joined strings and a true/false comparison — and watch them run in order.
A ~6-minute overview of the whole software development lifecycle. Watch before The Four Phases reading so you can see the shape of a project before naming its parts.
Read about process models and the four framework activities before you classify project tasks in the next lab.
Read each task from a school-lunch app and log which of the four phases it belongs to. Auto-graded.
Read about umbrella activities — the work that runs alongside every phase — before the Name That Umbrella lab.
Read a testing scenario and log which umbrella activity it belongs to. Auto-graded.
Read about software engineering actions — the named jobs inside a phase — before you write a task set.
Read about task sets — the checklist one action needs — before you write a task set of your own.
List a task set for the requirements-definition action. AI-graded with hints.
Read about SDLC methodologies and why teams follow one, before the Four Ps reading.
Read about the four Ps and why two projects elaborate the same framework differently.
Five multiple-choice questions on the four Ps and why two teams elaborate the same framework differently. Checked instantly.
Read about prescriptive process models — an orderly, prescribed sequence — before the reading on where they break.
Read about where prescriptive models break — rigid, inflexible, and poor fits for changing requirements.
Four multiple-choice questions on prescriptive process models and where they break. Checked instantly.
Describe the four framework activities, walk a real product through them, and map them onto the five-phase naming. AI-graded with hints.
Ten multiple-choice questions on the four phases, umbrella activities, actions and task sets, the four Ps, and prescriptive models. Checked instantly.
→ View full module pageVariables and Data Types slides.
Declare variables with let and const, reassign a let, and choose between the two. Read before the variables-and-types lesson.
Eight types, and the whole language is built from them. The map before the tour.
A variable is not locked to one type. Convenient, and the reason a whole class of bug only shows up when you run the code.
Give one variable three different types in a row and print what typeof says each time. Auto-graded.
Whole numbers and decimals are the same type in JavaScript. One type, not two.
Learn arithmetic operators and the biggest JS beginner trap: why "5" + 3 equals "53". Read before the operators-expressions lesson.
Three values that are numbers without being numbers. Definition 1.2.1, and why JavaScript never crashes on bad maths.
Once NaN appears in a calculation it spreads to the whole result. Example 1.2.1, with the one exception.
Four expressions. Write down what you expect, then run them and find out. Auto-graded.
Past 9007199254740991, ordinary numbers stop being exact. Definition 1.2.2 and the n suffix.
Double, single and backtick. Two of them are interchangeable and one is not. Definition 1.2.3.
Drop a variable or a whole calculation into the middle of a string. Backticks only.
Build strings with backtick template literals and use .length, .toUpperCase(), and .includes(). Read before the variables-and-types lesson.
Build a greeting with a template literal, then prove single quotes cannot do the same job. Auto-graded.
Practice arithmetic, string concatenation, and comparison operators.
Exactly two values, and most of them come out of a comparison rather than being typed by hand. Definition 1.2.4.
Four comparisons, four boolean answers, and the habit of reading a comparison as a value.
Deliberately nothing. A type with exactly one value in it. Definition 1.2.5.
What JavaScript puts in a variable you declared but never filled. Definition 1.2.6, and why not to write it yourself.
Tell the two empties apart and say when you'd write each. AI-graded with hints.
Seven types hold one thing each. The eighth holds collections. Definition 1.2.7.
Ask any value what type it is. Definition 1.2.8, and the syntax that looks like a function but isn't one.
Three answers that need explaining, including a bug the language has kept on purpose since 1995.
Run typeof over six different values and find the one answer that lies. Auto-graded.
Understand how to store and work with data using let, const, and typeof.
The whole type system on one page, now that you have met every row of it.
Ten broken variable declarations. Fix each one and say in a comment what was wrong. Auto-graded.
Six variables describing something in the room, printed as a sentence with a template literal. Auto-graded.
A four-minute tour of the whole type system: eight basic types, seven of them primitive, dynamic typing, and the typeof operator — including the one answer typeof gets wrong. Watch after the readings as a second pass over the same ground.
Eight multiple-choice questions on dynamic typing, the seven primitives, and null vs undefined. Checked instantly.
→ View full module pageDocumentation and Coding Conventions slides.
Write variable names in camelCase and see why descriptive names beat short mystery names.
Apply consistent indentation, operator spacing, and semicolons so code is easy to scan.
What single-line and block comments do, and why they matter. Read before A3.1.
Why comments and READMEs matter once more than one person touches the code.
A name should say what it holds without needing a comment. Definition 1.3.1, first rule.
A single letter tells the reader nothing. Definition 1.3.1, second rule — and the one exception.
data and value are too vague to help anyone. Definition 1.3.1, third rule — and the other ditch.
If the team says "user", never write "visitor". Definition 1.3.1, fourth rule — the one that only bites in groups.
Three lines, twice. Nothing about how it runs changes — only how fast a reader understands it. Example 1.3.1.
Two snippets of single-letter code. Rename every variable so each line explains itself. Auto-graded.
Six names, and one that is genuinely borderline. Judge each and say which rule it breaks. AI-graded with hints.
A box labelled "books" that you keep putting shoes in. Book §1.3.2, and the habit to break early.
It saves a little typing and buys you a debugging problem. Also: extra variables do not slow your program down.
Walk a reused variable line by line, then split it. Try It Now 1.3.2, done out loud.
One variable doing four jobs. Give each job its own well-named variable. Auto-graded.
Your teammate wrote cartItems. You wrote basketItems. Say what the problem is and what you do about it. AI-graded with hints.
The one file written for someone who has not read your code yet. Three questions it has to answer.
Twelve lines with no comments, no spacing and terrible names. Fix it to the class style guide and write the README. Auto-graded.
Three minutes on why good variable names matter and why giving one variable several jobs costs more than it saves. Watch after the readings.
Nine multiple-choice questions on naming, comments, documentation and READMEs. Checked instantly.
→ View full module pageProgramming Paradigms and Languages slides.
Languages are purpose driven. "Which is best?" is not a well-formed question — best for what?
Four jobs, four languages. Log the language each job was designed for. Auto-graded.
How much machine detail a language makes you handle — and why hiding it is a choice, not a shortcut.
One runs fast, one is written fast. Definition 1.4.1 and the trade-off behind it.
Five multiple-choice questions on levels of abstraction and picking a language level against a deadline. Checked instantly.
Two programs can solve the same problem and be organised in completely different ways. Definition 1.4.2.
The style you have been writing since §1.2: steps in order, acting on data held somewhere else.
Procedural programming with a discipline attached, and a surprisingly strong claim. Definition 1.4.3 — and SLO-2.
The three structures every program is built from, one at a time, with where Chapter 2 teaches each.
Three programs, read one at a time, naming the structures in each. The identification habit, done out loud.
Four described programs. Log which of the three structures each one needs. Auto-graded.
The first example in this course of a restriction being a feature. No arbitrary jumps, and what that buys.
Name the three structures of structured programming and give an everyday example of each. AI-graded with hints.
Bundling data with the behaviour that acts on it. Definition 1.4.4, and why Chapter 5 exists.
Two snippets, same output, different paradigm. What actually tells them apart is not what you'd guess.
Five multiple-choice questions on where behaviour lives in procedural versus object-oriented style. Checked instantly.
Same input, same output, nothing else disturbed. The paradigm that is careful about change.
Some languages commit to one style. JavaScript supports all three — and real programs mix them.
Three snippets, three paradigms. Log which is which, then name what JavaScript itself is. Auto-graded.
A short survey of the language landscape. Watch after the readings, as a second pass over the same ground in someone else's words.
Eight multiple-choice questions on purpose-driven languages, levels of abstraction, and the three paradigms. Checked instantly.
Pick two languages that aren't JavaScript and explain what each is for and why its paradigm fits. AI-graded with hints.
→ View full module pageProgram Design Tools and Environments slides.
A program has two separate difficulties. Typing solves one of them, and doing both at once is why you get stuck.
The bridge between a problem and its solution. Definition 1.5.1, and why a computer cannot do this part for you.
Decomposition, pattern recognition, abstraction, algorithms — and the table analogy that explains why you need all four.
Abstraction, automation, analysis — the shorter framing, and the step people skip.
Five instructions, read back literally by something that knows nothing. Watch where they break.
Write instructions for a task, then find the first one that breaks when read literally. AI-graded with hints.
Redefining one hard task as a set of easy ones. Definition 1.5.2.
Categories are compression. Twelve unrelated facts become three groups you can hold.
The two directions logical thinking runs, and where each one shows up when you are debugging.
Build Table 1.5.1 from nothing, and watch the empty columns tell you what you forgot.
Five multiple-choice questions on decomposition and what makes a part self-contained. Checked instantly.
Keep what matters, discard the rest. Definition 1.5.3, and the one test that decides which is which.
Real systems stack abstractions so each layer minds its own job. You already trust dozens of them.
All four techniques on a problem nobody would call programming, which is the point.
Five multiple-choice questions on abstraction, the drop test, and why it is relative to the problem. Checked instantly.
Explain the four parts of computational thinking in your own words, with a worked example of each. AI-graded with hints.
Finite, ordered, unambiguous. Definition 1.5.4, and why all three words are doing work.
Two ways to write an algorithm down before you write any code: pseudocode in structured English, and a flowchart in three shapes.
One instruction per line, and indent what is inside something else. Definition 1.5.5 — that is the whole ruleset.
The voting check, planned before it is coded. Example 1.1, and what the plan deliberately does not say.
The sandwich grows a decision, and pseudocode grows keywords: START, INPUT, IF, THEN, ELSE, OUTPUT.
Five multiple-choice questions on reading a broken plan, indentation, and why nothing running it is the point. Checked instantly.
Five multiple-choice questions on reading pseudocode plans: which is pseudocode, which plan is correct, and what makes a loop end. Checked instantly.
Oval, rectangle, diamond. Definition 1.5.6, and Table 1.5.2 — nearly every flowchart is these three.
One way in, two ways out, and the paths rejoin. This is §1.4's selection, drawn.
Neither is better. They are good at different things, and most programmers use both.
Five shapes: get a number, ask whether it is even, print one of two answers, rejoin. Your first chart, ungraded.
The rule for the rest of the course: every graded build opens with a flowchart, and the flowchart goes first. What gets checked, what does not, and how big a chart should be.
Chart the printer-credit rule using only the three shapes the book teaches. The first and gentlest run of the flowchart gate: nothing is graded, and you can redraw as often as you like.
Turn the chart you just passed into working JavaScript, and confirm the code matches the plan. Auto-graded.
Three ways the same instructions can be carried out, and why two of them finish sooner.
A process that calls itself on a smaller version of the same problem. Definition 1.5.7 — read it, don't write it yet.
Cause the error deliberately, so you recognise it when it happens by accident.
F12, then Console. A scratchpad that forgets everything, which is exactly what makes it comfortable. Definition 1.5.8.
The console is a scratchpad; the editor holds the program. The difference is permanence.
Two expressions, one pair of brackets, and a question answered in four seconds. Auto-graded.
The kind, the detail, the place. Usually the most useful sentence available, and usually skimmed.
Break it, read the three parts, say which one solved it, then fix it. Auto-graded.
You have to know what the answer should be before you can tell that it isn't.
Most bugs never produce a message. Definition 1.5.9, and the two habits that make printing work.
A program that prints 9 instead of 20, found by narrowing rather than by staring.
Three bugs, none of which produce an error message. Narrow them down with labelled prints. Auto-graded.
Three and a half minutes on the four cornerstones of computational thinking, the three words that define an algorithm, and when to reach for pseudocode versus a flowchart. Covers the design half of this module.
Twelve multiple-choice questions on computational thinking, decomposition, abstraction, pseudocode, flowcharts, recursion and debugging. Checked instantly.
→ View full module pageConditionals slides. Placeholder until the deck is built from the book.
A short tour of how programs choose a path with if/else. Watch before 2.1.3 Reading — If / Else if / Else.
Learn how to make your code choose a path: if, else if, and else. Read before the conditionals practice lesson.
Draw the if/else you just traced as a flowchart. One diamond, two labelled exits, both branches rejoining.
Write an if statement that logs a message when a number meets a threshold. Auto-graded.
Extend an if statement with an else branch to handle both outcomes. Auto-graded.
Write an else if chain with at least three branches. Auto-graded.
Learn how to put one if statement inside another to ask a follow-up question. Read before the nested-if practice lesson.
Write an if statement inside another if statement to ask a follow-up question. Auto-graded.
Learn the six falsy values and how if converts any value to true or false. Read before the truthy-check practice lesson.
Write an if statement that tests a variable directly, relying on truthy/falsy conversion. Auto-graded.
Learn the six comparison operators and why === is safer than ==. Read before the conditionals practice lesson.
Log four comparison expressions, including at least one ===, and observe the results. Auto-graded.
Learn why parentheses make a condition's intent clear even when they aren't strictly required. Read before the ternary operator lessons.
Learn the ternary operator: condition ? value1 : value2. Read before the ternary practice lesson.
Use the conditional operator ? to assign one of two values to a variable. Auto-graded.
Learn how to chain conditional operators to pick from more than two values. Read before the chained-ternary practice lesson.
Chain at least two conditional operators to pick from three or more values. Auto-graded.
Learn the rule of thumb: use ? to pick a value, use if to run different code. Read before the rewrite practice lesson.
Take a ternary used for its side effect and rewrite it as an if/else statement. Auto-graded.
Learn how to combine conditions with AND, OR, and NOT. Read before the conditionals practice lesson.
Write an if statement whose condition combines two checks with &&. Auto-graded.
Write an if statement whose condition combines two checks with ||. Auto-graded.
Use the ! operator to flip a boolean inside an if condition. Auto-graded.
Fix a door-unlock condition that uses || where it should use &&. Auto-graded.
Write one if condition that uses all three logical operators together. Auto-graded.
Predict the output of an else if chain and a chained ternary before running them. Auto-graded.
Given filament type and layer height, print a recommended print temperature using else if and logical operators. Auto-graded.
Optional stretch problems. Auto-graded.
Use score, attendance, and lateAssignments to print a grade recommendation. Auto-graded.
Five multiple-choice questions on === vs ==, operator precedence, and tracing three conditional snippets. Checked instantly.
→ View full module pageAlgorithms and Loops slides. Placeholder until the deck is built from the book.
An algorithm is a precise, ordered set of steps to solve a problem. See how that idea turns directly into code.
An algorithm is the plan. A program is that plan written in a language a computer can run. See the same decision as English, then as JS.
Four shapes carry nearly every flowchart. Learn what each one means and the two rules that make a flowchart readable, before you draw one.
You just wrote the largest-of-three algorithm as code. Now draw the same algorithm as a flowchart, without looking at the code.
Draw the ticket-price algorithm as a flowchart. One start, one decision diamond with two labelled exits, one end. Green here unlocks 2.2.8 A2.2.1 (Part A).
Define algorithm in your own words, then write a precise numbered algorithm for an everyday task. AI-graded.
Learn the three-part for loop: init, condition, increment. Count to five, then sum a range — the two moves you'll use everywhere.
Draw the sum-1-to-5 loop as a flowchart using the loop-setup hexagon, and get the return arrow landing in the right place.
Write a for loop that logs every integer from 1 to 10. Auto-graded.
while checks the condition before each run; do…while runs once first. Learn both, and how to avoid an infinite loop.
Write a while loop that counts down from 10 to 1, logging each value. Auto-graded.
Write a JS program with at least one for loop and one while loop that solves a counting or accumulation problem. Auto-graded.
A flowchart arrives with five red checks and one actual mistake. Find the mistake, and learn to read the checker instead of guessing.
A canonical algorithm is a well-known pattern worth knowing by name. Meet linear search: check one item at a time until you find what you're looking for.
Optional stretch problems. Auto-graded.
→ View full module pageThe Switch Statement slides. Placeholder until the deck is built from the book.
See why a long else-if chain that keeps testing the same variable is a sign JavaScript has a better tool for the job. Read before 2.3.3 Reading — switch Statements.
Learn how a switch statement picks one case from many without a long if/else chain. Read before 2.3.4 Worked Example — A Menu of Options.
Draw a three-case switch as a flowchart and see why break matters: without it, the arrows fall straight into the next case.
Write a switch that prints the sound an animal makes, with a default for anything else. Auto-graded.
Write two switch statements, predicting the output before you run each one — including one where default is written in the middle. Auto-graded.
See what JavaScript actually does when a case has no break, and why the bug is easy to miss. Read before 2.3.10 Worked Example — switch vs if-else-if.
Write a three-case switch where the first case deliberately has no break, predict the output, then run it and check. Auto-graded.
This code should print exactly one line but prints two. Find the missing break and fix it. Auto-graded.
Learn how to stack case labels with no code between them so several values share one block. Read before 2.3.15 Worked Example — Weekend or Weekday.
Write a switch with grouped cases that prints Vowel for a, e, i, o, u and Consonant for anything else. Auto-graded.
See why a case can silently never match when the switched value is the wrong type. Read before 2.3.19 case false vs case 0: Predict, Then Run.
Write a switch with case false, case 0, and case '0', then predict which one a number, a boolean, and a string each match. Auto-graded.
This code should print Second place and prints No medal instead. Fix it without changing the case values. Auto-graded.
Learn the one question that tells you which statement fits a problem. Read before 2.3.24 Worked Example — When switch Fits: Command Dispatch.
Rewrite an if/else-if chain that checks a traffic light color as an equivalent switch statement. Auto-graded.
Explain which statement fits a given problem and why. AI-graded.
Write a switch with at least four cases and a default that prices a drink by size. Auto-graded.
Rewrite an if/else-if chain as a switch statement with at least two cases, a default, and break. Auto-graded.
Write a switch on filamentType with at least four cases and a default, printing a recommended temperature and speed for each. Auto-graded.
Optional stretch problems. Auto-graded.
→ View full module pageLoop Control and Nested Loops slides. Placeholder until the deck is built from the book.
for and while can do the same job. Learn the test that tells you which one to reach for. Read before Predict: Which Loop Fits?
Write a for loop for a known-count task and a while loop for an unknown-count task. Auto-graded.
while and do...while test their condition at different ends, and that changes whether the body ever runs at all. Read before Predict: while vs do...while.
Draw a do...while loop as a flowchart and see why the diamond sits at the bottom instead of the top.
Write a do...while loop that prints 1 through 5, then a second one whose condition starts false and still runs once. Auto-graded.
break ends a loop the moment you tell it to, even if the loop's own condition never becomes false. Read before Searching Without a Known End.
Draw a while (true) + break search as a flowchart. The loop has no condition of its own — the diamond inside the body is the only way out.
Count up from 1 and break as soon as the square of the count exceeds 50. Auto-graded.
continue is gentler than break — it skips only the current round and keeps the loop running. Read before Filtering While You Loop.
Draw the skip-the-evens loop and route continue's arrow back to the hexagon, not to End. Compare it against a break chart.
In a for loop, continue still runs the increment. In a while loop it can jump straight past your update line — and hang the program. Read before The continue Trap, and Its Fix.
Loop over 1 to 20 and print only the multiples of 3, using continue to skip the rest. Auto-graded.
An infinite loop never crashes and never errors — it just never finishes. Learn the three usual reasons before you have to debug one. Read before Making an Infinite Loop Safe.
A chart arrives whose diamond only has one exit — the loop can never leave. Add the missing branch so a reader can see where it stops.
Five loop programs are broken: two never stop, two are off by one, one has a do...while logic error. Fix all five and explain each bug in a comment. Auto-graded.
A loop inside a loop is a nested loop, and the inner one runs all the way through for every single round of the outer one. Read before A Multiplication Table.
Draw the row/col nested loop with two loop-setup hexagons, one nested inside the other's body.
Two nested loops over 1,000 items each is a million rounds. Learn to count the cost before you look anywhere else for a slowdown. Read before Triangle of Stars.
Use a nested loop to print a triangle of stars, one row at a time, where the inner loop's limit depends on the outer loop's counter. Auto-graded.
A nested loop is supposed to print each pair once but prints every pair twice, including pairs of a number with itself. Fix the inner loop's starting value. Auto-graded.
Write a nested-loop program that prints a grid of at least 5x5, with the dimensions controlled by variables, not hardcoded loop bounds. Auto-graded.
Optional stretch problems. Auto-graded.
→ View full module pageHandling Errors with try/catch slides. Placeholder until the deck is built from the book.
See what a runtime error does to a running program, and tell it apart from a syntax error. Read before 2.5.3 Runtime or Syntax?.
Write code that fails at runtime, not at parse time, and confirm which lines still run. Auto-graded.
Learn how try...catch lets a program recover from a runtime error instead of stopping cold. Read before 2.5.5 Worked Example — Only Wrap What Can Fail.
Rewrite a try that wraps too much so the total still prints even when the risky line fails. Auto-graded.
Draw try/catch as a flowchart: attempt a step, then branch on whether it failed.
Write a try...catch that falls back gracefully when a variable doesn't exist, and confirm the program still finishes. Auto-graded.
Build a try...catch and predict exactly which of four lines print. Auto-graded.
See why a catch block that does nothing is worse than no try...catch at all. Read before 2.5.11 Fix the Silent Catch.
An empty catch block is hiding a failure. Add a report so the next person can see it. Auto-graded.
Read err.name and err.message to say exactly what went wrong. Read before 2.5.13 Worked Example — Reporting Instead of Guessing.
Cause a TypeError on purpose and print both err.name and err.message. Auto-graded.
Raise your own error with throw when a value breaks the program's rules, not the language's. Read before 2.5.16 Worked Example — Validate, Then Trust.
Draw two validation checks in a row, each throwing on the branch that fails.
Decide when a problem deserves a throw and when a plain if is simpler. Read before 2.5.19 Reject the Bad Input.
Throw an error when a password is too short, and catch it with a clear message. Auto-graded.
Build a try block where a throw sits between two other lines, and confirm exactly which lines run. Auto-graded.
Run cleanup code whether try succeeded or failed. Read before 2.5.22 When Does finally Run?.
Build a try/catch/finally and confirm finally runs in both the success and the failure case. Auto-graded.
Two limits worth knowing: try...catch can't save a syntax error, and it only guards code that runs inside it. Read before 2.5.24 Guard Only What's Inside.
Write two risky lines: one guarded by try...catch, one left outside it, and see which one crashes. Auto-graded.
Predict the output of a try/catch/finally with a throw inside it, then build it and check. Auto-graded.
Loop over three raw readings and use try/catch to reject bad input with a friendly message instead of crashing. Auto-graded.
Optional stretch problems. Auto-graded.
→ View full module pageFunctions: Definition and Calls slides. Placeholder until the deck is built from the book.
Understand how to define a function with function name() {} and call it. Defining a function is not the same as running it.
A new shape arrives: the double-rail rectangle stands for a whole sequence defined somewhere else, and flow comes back from it.
Redraw your grade-advisor plan with each function as one double-rail shape. The gate for A3.1.1: chart first, refactor second.
Define two functions: findMax(a, b) that returns the larger number, and isEven(n) that returns true when n is even. Auto-graded.
Define sumToN(n) that uses a for loop to add every integer from 1 to n and returns the total. Auto-graded.
Group code into reusable logic blocks with parameters and return values.
→ View full module pageParameters let you pass inputs into a function. return sends a value back out so you can store or use it.
A variable declared inside a function is local — it only exists while that function runs and is invisible outside it. Global variables are accessible everywhere.
→ View full module pageArrays slides. Placeholder until the deck is built from the book.
Learn how arrays store ordered lists, how zero-based indexing works, and how push, pop, and length let you grow and shrink the list. Read before the array exercises.
Learn two ways to visit every item in an array: a plain for loop using the index, and the cleaner for...of loop. Read before the array iteration exercises.
Learn how .split() turns one big string into an array of lines — the same pattern used when reading a text file. Read before the file-processing exercises.
Use a for loop and .length to add up all numbers in an array, then log the total. Auto-graded.
Draw the menu loop with the hexagon, and get the arrow that leaves the loop pointing at the right place.
Work with lists of values: create, add, remove, and iterate.
→ View full module pagePrimitives (numbers, strings, booleans) are copied when passed to a function — the original is safe. Objects and arrays are shared — a function can change the original.
Protect the original by copying before you change: spread [...arr] makes a new array so mutations stay in your copy.
Explain pass by value and pass by reference in your own words, give one example of each, and describe a bug that could happen if you forget the difference.
→ View full module pagePrint Shop (Q1 Synthesis) slides. Placeholder until the deck is built from the book.
Write the steps as comments first, then fill in the code underneath. Read before the Print Job Manager project.
The last two shapes, for the first chart too big to fit on a page: a jump that replaces a long arrow, and a note for the reader.
Call a function with a known input and print PASS or FAIL based on whether the result matches what you expected. Read before the Print Job Manager project.
Design day: chart the whole Print Shop before any build time. One double-rail per planned function, under twenty shapes. The build lessons open when this is green.
Q1 synthesis: a console-only pricing and queue tool for the class printers. Arrays of objects, functions, sorting, save/load, and your own tests.
Reflect on your first quarter of programming and connect your experience to the SDLC. AI-graded with hints.
→ View full module pageHello Sprite and Movement slides — canvas, sprites, keyboard input, and the frame loop. Placeholder until the deck is rebuilt from bookSHelf.
5-min walkthrough introducing canvas, sprite, and run cycle. Watch before the Hello Sprite lesson.
How shplay calls setup() once and draw() every frame. Read before 2.1.3a (Canvas).
How new Canvas(w, h) opens the drawing area and why (0, 0) is top-left with y increasing downward. Read before 2.1.3b (Sprite).
How new Sprite(x, y, w, h) creates a rectangle the engine renders for you, and how .color sets its fill. Read before 2.1.3c (lab).
Practice from 2.1.3b: create a canvas, drop a single sprite at the centre, and set its color. Three steps, no movement yet.
Why you declare a let at file scope and assign the sprite in setup() — and what goes wrong when you create sprites inside draw(). Read before 2.1.3e.
Why background(color) must be the first call inside draw() to clear the previous frame — and what motion trails look like without it. Read before 2.1.3f.
How to read and write the core sprite properties pos, rotation, and layer after the sprite is created. Read before 2.1.4 (worked example).
Your first shplay sketch: a canvas, a sprite, a background color.
3-min walkthrough of the setup/draw frame loop at 60 fps. Watch after Hello Sprite, before Make it Move.
How kb.pressing(key) checks whether a key is held this frame. Read before 2.1.7a (Velocity).
Teacher-led walkthrough of the if/else-if/else pattern for keyboard movement and the drift-bug. Read before Make it Move.
How sprite.vel.x and vel.y work as pixels-per-frame values the engine integrates into position. Read after 2.1.7.
The canonical if/else-if/else pattern that maps key presses to velocity changes inside draw(). Read after 2.1.7a.
Why velocity persists across frames and why the else branch is what stops the sprite. Read after 2.1.7b.
Start from a working WASD movement pattern, delete the two else lines, observe drift, then restore them.
Why graded labs use 'a'/'d'/'w'/'s' instead of arrow keys, and how to swap them into the movement pattern. Read after 2.1.7d.
Drive a sprite with the arrow keys by setting vel.x and vel.y based on what's pressed.
Build a sprite playground combining canvas, WASD-controlled sprite, auto-motion, and on-screen text. Auto-graded.
Written reflection on setup/draw and the 60fps math. AI-graded with hints.
Pick one or more of the stretch challenges and implement them in the editor. Auto-graded.
A dynamic block falls under gravity and lands on a static floor. Read the example, then experiment.
→ View full module pageClasses and Objects slides — this, and procedural vs OOP. Placeholder until the deck is rebuilt from bookSHelf.
4-min DevTools walkthrough. Opens a running shplay sketch, inspects a Sprite instance, and names what a class is. Watch before the DevTools reveal example.
The words class and instance and how they relate — a class is a blueprint; new builds one instance from it. Read before 2.2.3a.
What new does mechanically: allocate, run constructor, return. Read right after 2.2.3.
How the constructor receives arguments from new and stores them on this. Read right after 2.2.3a.
A property is data stored on a single instance via this.name = value. Read before the property labs.
Read b.color and b.size off a Box instance and print them to the on-canvas console using console.log. First practice with dot-notation reads.
Mutate b.color on a space-bar press to practice assigning a new value to an instance property. First practice with dot-notation writes.
Instantiate b1 and b2 from the same class with different colors, then mutate only b1 to confirm each instance's state is independent.
this always refers to one specific thing — the instance the method was called on. Read before the substitution rule example.
Low-stakes autograded practice. Instantiate the Sprite class twice (rectangle form and circle form), set properties on each instance, and give one sprite a stroke. Bridges the 2.2.4 / 2.2.5 worked examples and the 2.2.8 Enemy class lab.
A tour of the Sprite class re-read as OOP. Every new Sprite(...) is a constructor call; every .color / .stroke is a property on an instance.
3-min whiteboard walkthrough of this inside methods. Shows why this.color and this.hp refer to the specific instance the method was called on.
Method declaration syntax: inside a class body, methods are written without the function keyword. Read before the method labs.
Write Counter.tick() — a method that takes no arguments and mutates this.n. First method you write from scratch.
Add Counter.addBy(n) — a method that takes an argument and uses it to increment this.n. Keys 1/2/3 add different amounts.
Add Counter.isHigh() which returns true when this.n > 10. The driver uses the return value to color the display red.
Write Counter.bigStep() which calls this.addBy(5) and returns this.isHigh() — one method dispatching another on the same instance.
Draw a method calling another method. Two double-rails, and flow that comes back from both.
Composition over inheritance: why wrapping a Sprite as this.sprite is safer than inheriting from it. Read before the sprite mutation labs.
Write Mover.moveRight(dx) which adds dx to this.sprite.x, reaching through composition to move the wrapped sprite.
Write Bubble.pop() which calls this.sprite.delete() so the object removes its own sprite on click.
Instantiate e1, e2, and e3 from the Enemy class at three different positions — three independent instances, each in its own named variable.
Store five Enemy instances in a single array by pushing new Enemy(...) calls into enemies — practice managing many instances without separate named variables.
Write a for...of loop in draw() that calls .render() on each enemy — dispatching a method to every element in the array with one loop.
Side-by-side comparison of the same problem (an 'enemy fleet') solved two ways: with parallel arrays (procedural) and with an array of class instances (OOP). Read between the Enemy class example and the Procedural-vs-OOP example.
The same feature drawn twice, procedural and object-oriented. No drawing — read both and answer what happens when a fourth enemy arrives.
Three yes-or-no questions that tell you whether a class is the right tool. Read after the Procedural vs OOP example.
Write a Collectible class, instantiate at least 5, and detect overlap with the player. SLO-2 lab — the class is the point. Auto-graded.
Comparison of procedural and object-oriented programming.
Name the three OOP pillars you'll encounter in downstream courses — no implementation required this week. Read at the close of Unit 2.2.
Pick one (or more) OOP stretch challenges — extend your Enemy class, write a Player class, or try subclassing with extends. Auto-graded.
Groups and Overlaps slides — overlap detection, safe despawn, edge-triggered input, and ground-gated jumping. Placeholder until the deck is rebuilt from bookSHelf.
Why a Group is a class with shared defaults — and how a single line creates fifty enemies. Watch before 2.3.5 Groups Sandbox.
shplay docs chapter on Groups. Read before 2.3.5 Groups Sandbox.
Groups let you treat many sprites as one. Create, configure, spawn into, and clean up a Group.
→ View full module pageThe two flavors of overlaps() and why the callback form is cleaner for despawn-on-collide. Watch before 2.3.7 Apple Catcher.
shplay docs chapter on collisions and overlap detection. Read before 2.3.10 Safe Despawn.
Live demo of why for (let i = 0; i < group.length; i++) + .delete() skips items, and how to fix it. Watch before 2.3.10 Safe Despawn.
Combine Groups, overlap detection, and safe despawn into a playable asteroid scene. WASD steers the ship; an overlap with any asteroid ends the game.
Pick one (or more) Groups stretch challenges — add a lives counter to Apple Catcher, vary apple sizes for varied points, or implement a cull() helper. Auto-graded.
Physics Applications slides. Placeholder until the deck is built from the book.
Why holding space launches a super-jump 60 frames in a row, and how the edge-triggered form fixes it. Watch before 2.3.15 Edge-triggered Input.
shplay docs chapter on input — kb.pressing (level-triggered) vs kb.presses (edge-triggered). Read before 2.3.15 Edge-triggered Input.
The infinite-jump bug live, and the colliding(ground) fix. Watch before 2.3.18 Ground Detection.
shplay docs on sprite.colliding(other) and the ground-gated jump idiom. Read before 2.3.18 Ground Detection.
Build a one-sprite platformer: WASD moves, space jumps — but only when touching the ground.
Build a two-wheeled car using WheelJoints and drive it up a ramp with WASD. The harder of the two A14 options.
→ View full module pageAnimated Sprites and Camera slides — addAni / changeAni, camera follow, smoothing with lerp, and layer for render order. Placeholder until the deck is rebuilt from bookSHelf.
How addAni registers named animations and changeAni swaps the active one — driven by player state (idle vs run). Watch before 2.4.5 Animated Sprites Sandbox.
shplay docs chapter on Animation. Read before 2.4.5 Animated Sprites Sandbox.
How sprite.addAni(name, frame1, ...) registers a named animation and makes it the active default. Read before 2.4.3b (changeAni).
How sprite.changeAni(name) swaps the active animation between previously registered names. Read before 2.4.4 (Worked Example).
How sprite.animation.frameDelay = N slows or speeds an animation cycle. Read before 2.4.5 (Animated Sprites Sandbox).
How sprite.image = url displays a still image without any animation cycle. Read before 2.4.5 (Animated Sprites Sandbox).
Drive a sprite's visual from input state — the same swap pattern used by addAni / changeAni, with sprite.image swapping as the asset-free placeholder. Idle when standing, run when moving, jump when 'w' is held.
Why the camera is a coordinate transform, not a 'real' object — the world stays put, only the viewport moves. Watch before 2.4.8 Worked Example — Camera Follow.
shplay docs chapter on Camera. Read before 2.4.8 Worked Example — Camera Follow.
How assigning camera.x and camera.y shifts the viewport center each frame. Read before 2.4.7b (Camera-follow pattern).
How camera.x = player.pos.x inside draw() locks the viewport onto a moving sprite. Read before 2.4.8 (Worked Example — Camera Follow).
How lerp(current, target, t) replaces a hard-set camera follow with a smooth elastic trail. Read before 2.4.9 (Worked Example — Smooth Camera).
How sprite.layer = N controls draw order so HUD elements always render on top of world geometry. Read before 2.4.10 (A15.1 Platformer).
Combine animated sprites, a camera that follows the player, three or more platforms, working jump mechanics, and a visible end goal into a playable side-scroller. Auto-graded.
Pick one (or more) Animation & Camera stretches — parallax background, mirror the sprite when it walks left, or add vertical camera follow. Auto-graded.
→ View full module pageSave and Load opening slides — why game data disappears on refresh, what persistence means, and the plan for building a save/load system your players can count on. Placeholder until the deck is rebuilt from bookSHelf.
A game resets to zero on refresh. Variables live in RAM — gone when the tab closes. Saved data lives on disk — still there tomorrow. This short video contrasts both so you understand what persistence actually means.
How storeItem(key, value) writes a value into the browser's save slot so it survives page reloads. Your game can remember things between sessions.
Step-by-step: build a survival game, detect when the game ends, and use storeItem to save the player's high score so it survives a reload.
How getItem(key) reads back a value your game saved earlier. Covers the basics of retrieving save data — the string type gotcha is in 2.5.5a.
getItem always gives you a string, even when you stored a number. String comparisons give wrong results — here's the Number() fix and the || 0 fallback.
Read your saved high score on startup, coerce it with Number(), display it next to the current score, and update it when the player beats their record.
A high score is one number. But your game has position, level, inventory — many pieces. JSON bundles them together.
JSON.stringify takes a JS object and turns it into a string you can store. Think of it as packing your game state into a box.
JSON.parse unpacks a JSON string back into a JS object. It's the reverse of JSON.stringify.
The full pattern: build a save object, stringify it, store it. Then getItem, parse, and restore. Complete round-trip.
Build a game with a moving player, score, and level. Save everything as one JSON object with storeItem.
Load a saved game: getItem, JSON.parse, coerce numbers, then apply to your game objects.
loadJSON loads external JSON files (levels, dialogue, config) — different from save/load. It's async and needs a callback.
One save isn't enough — games have multiple slots. Each slot is just a different key name passed to storeItem/getItem.
removeItem(key) deletes one saved key. clearStorage() wipes everything. When and how to use each.
Build three save slots. Each slot is a differently-named key. Press 1/2/3 to save, load with a simple text menu.
Manage save slots: delete old saves with removeItem, confirm before overwriting, handle the empty-slot case.
If a save exists, show 'Continue'. If not, only 'New Game'. The title screen pattern every game uses.
Build a title screen that checks for a save on startup. If save exists, show 'Press C to Continue'. Always show 'Press N for New Game'.
No drawing. Read the title-screen save check and answer five questions about what a first-time player sees.
When the player tries to save over an existing slot, show an 'Are you sure?' prompt before writing.
Not every save needs a button press. Auto-save triggers on level transitions, checkpoints, or a timer — the player doesn't think about it.
An auto-save fires when something important happens — reaching a checkpoint, finishing a level, hitting a score milestone.
Implement two auto-save triggers: when the player reaches a level-complete zone, and a timer-based save every 30 seconds.
Graded: build a game with a complete save system — at least 3 save slots, load functionality, auto-save on level complete, and a Continue option on the title screen.
Extend your save system: save file previews (show slot contents before loading), save timestamps, multiple profiles, or a 'delete all saves' with double-confirmation.
→ View full module pageGame State Machines opening slides — title screen, gameplay, pause, game over. Every screen is a state. One variable controls which screen is active. Placeholder until the deck is rebuilt from bookSHelf.
Every game has states: title → play → game over → title. A state machine is just a variable that remembers which screen you're on.
switch is like if/else but cleaner when checking one variable against many values. Syntax: switch(variable) { case VALUE: ... break; }
In shplay games, switch goes inside draw(). Each frame, it checks the state variable and draws the right screen.
A plain switch with three cases that each draw different text. Not a game yet — just getting comfortable with the syntax.
break exits the switch; without it, execution falls through to the next case. default handles unexpected values.
One variable controls which screen is visible. Every frame, draw() checks state to decide what to render. This is the single source of truth for your game's screen.
Build three distinct screens — red, green, blue backgrounds with different text — all controlled by one state variable with switch.
Use lowercase strings for state names: 'title', 'play', 'pause', 'gameover'. Be consistent. Good names make the switch statement self-documenting.
A title screen is just a state. It shows the game name, maybe instructions, and waits for the player to press a key to start playing.
Build a title screen state that shows the game name and 'Press ENTER to start'. When they press Enter, change state to 'play'.
The game over screen shows the final score and 'Press R to restart'. Restart means resetting variables + changing state back to 'play' (or 'title').
The complete beginner state machine: title screen → gameplay → game over → restart. The classic arcade loop.
Draw the title / play / gameover machine. This is the chart that pays for itself: a state machine is far easier to argue about as a picture than as a switch.
Input-driven transitions happen when the player presses a key. Title → Play (press Enter), Play → Pause (press P). The player is in control.
Build a game where every state transition is triggered by the keyboard: Enter (start), P (pause/unpause), Escape (quit to title).
Condition-driven transitions happen automatically when something in the game changes. Score ≥ 100 → 'win', health ≤ 0 → 'gameover'. The game state triggers it.
Implement condition-driven transitions: score reaches 50 triggers a win screen, health drops to 0 triggers game over. The game decides when states change.
Real games have more than 3 states. Pause freezes the action. Inventory shows items. Settings adjusts volume. All use the same switch pattern you already know.
Add a pause state to your game. When paused, stop movement and physics, show a PAUSED overlay. Press P to toggle pause on and off.
Someone half-wired a pause feature and the chart shows it. Find what the red checks are pointing at and repair it.
A win screen shows when the player reaches the goal. It's a distinct state with congratulations, final stats, and a 'Play Again?' option.
States and saves work together: when the player reaches 'gameover', auto-save their score. When they hit 'win', save their victory. States trigger saves.
Graded: build a game with at least 4 states (title, play, pause, gameover) with full save/load integration. Saves trigger on state transitions. Continue restores the right state.
Extend your state machine: animated transitions, a loading screen state, state history (undo last transition), or an options/settings state that modifies gameplay.
You've built save systems and state machines — real game infrastructure. Unit 3 preview: what comes after the fundamentals.
→ View full module pageAdvanced Input and Joints opening slides — the three big ideas before capstone: mouse input, joints, and the slingshot pattern. Everything in this unit feeds directly into A17.1 and your capstone design. Placeholder until the deck is rebuilt from bookSHelf.
This is the last content unit before you design your own game. Mouse input, joints, and the slingshot pattern are the final building blocks — learn them here and you'll have everything you need to pitch and build a real project.
mouse.x and mouse.y give you the cursor's position on the canvas every frame. Read this before the mouse input worked examples.
mouse.pressing() is true every frame the mouse button is held down. Read this before 2.7.5 so you understand the held vs. one-shot difference.
mouse.presses() is true on exactly one frame — the moment the button first goes down. Read this after 2.7.4 to see how one-shot input differs from held input.
A hit-test checks whether the cursor is currently over a sprite. This technique gates click-and-drag — the drag only starts when the mouse is on the sprite.
Clicking is one-shot, but dragging follows the cursor across frames — and physics will fight you if you don't know the trick. This video shows the snap-and-zero-velocity pattern that makes a drag feel smooth before you code it yourself.
How to move a sprite exactly to the cursor position each frame during a drag. Zeroing the velocity is the step that keeps physics from fighting your snap.
Someone charted the grab half of drag-and-drop and never charted the letting go. Find what the red checks are pointing at.
applyForce(fx, fy) adds a one-frame impulse to a sprite — the physics engine turns it into motion. Read this before 2.7.19 Worked Example — Launch a Sprite with applyForce.
Two numbers — dx and dy — encode the direction from one sprite to another. This is the math behind every force that points somewhere on purpose. Read this before 2.7.19 Worked Example — Launch a Sprite with applyForce.
This is the moment the unit snaps together: a joint holds the ball, you drag it back with the mouse, release removes the joint, and a force vector launches it toward the target. Watch the whole pattern before you read the code.
Chart the three-stage slingshot: aim, stretch, release. The stage nobody draws is the one where nothing is happening yet.
One keyboard, two players — WASD on the left, arrow keys on the right, each with their own sprite and score. This video shows the pattern once so you can wire it up in A17.1 without guessing.
Two players on one keyboard means two separate key sets and two separate sets of variables — one for each player. Read this before 2.7.25 Worked Example — Two Paddles, Two Schemes.
sprite.bounciness controls how much energy a sprite keeps after a collision — 0 is a dead thud, 1 is nearly lossless. Read this before 2.7.24a Worked Example — Bounciness Comparison.
Graded: build a two-player Pong-Sumo game — two paddles, one ball, push the ball past the opponent to score. Incorporates two-player input, push-collision physics, a win condition, and at least one joint. Auto-graded.
Three optional stretch prompts for Unit 2.7: build a SliderJoint piston sandbox, a trebuchet that uses a DistanceJoint + HingeJoint together, or a swinging rope chain with three or more HingeJoints.
You've built every piece — mouse input, joints, forces, two-player games, state machines, saves. This short video closes Unit 2.7 and previews what Unit 2.8 asks you to do: design and pitch your own game from scratch.
→ View full module pageThree joint types in five minutes: a distance joint keeps two sprites a fixed length apart, a hinge lets one pivot around another, and a slider rides a track. You don't need to master all three — just watch and pick the one that fits your game.
How DistanceJoint constrains two sprites to stay at a fixed distance from each other. Read this before the pendulum worked example.
How HingeJoint pins two sprites to a shared pivot point so they rotate around it. Read this before the rotating-arm worked example.
How joint.delete() releases a constraint at runtime so previously-joined sprites become independent. This is the release step in the slingshot pattern.
→ View full module pageQ2 synthesis: ship a game you designed. The checklist is the spec — twelve things the game must contain. Everything else is your call.
Reflect on the game you shipped and the process that got it there. AI-graded with hints.
→ View full module page