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 every variable name in camelCase, mark never-changing values with const, 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 pagePick one of four problems with your partner, settle it on a flowchart, and get all ten checks green. The build lesson does not open until this one does.
Turn the chart you just passed into a documented, straight-line program. Ten checks, all of them things Chapter 1 taught. Auto-graded.
The writeup that goes with the live demo: who did what, three test cases, and where four of Chapter 1's five sections show up in your program. AI-graded with hints.
→ View full module pageEight questions: three on the ideas of Chapter 1, five where you read a short program and say what it prints. One submission, nothing marked on screen.
Three short answers: umbrella activities, what is wrong with a badly written program that also computes the wrong answer, and high-level against low-level languages. One submission, no feedback on screen.
A book-order receipt with four bugs in it. Repair all four and name what kind each one was. Auto-checked.
Pick one of three problems and chart it alone, using only the three shapes the book teaches. Part 5 writes the steps for the same problem.
Pseudocode for the problem you charted in Part 4. Plain English arranged like code, one instruction per line, indentation carrying the branches.
→ View full module pageConditionals slides: if / else if / else, comparison operators, the logical operators && || !, and the ternary operator ?.
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.
Fix an if condition that uses a single = where it should compare with ===. Auto-graded.
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.
Learn why parentheses make a condition's intent clear even when they aren't strictly required. Read before 2.1.37 Combine &&, ||, and !.
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.
Stretch problems. Every challenge is required to continue. 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.
A while loop checks its condition before every run. Learn when to choose it over for, 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.
Loop through a string and count how many times one letter appears. Auto-graded.
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.
Stretch problems. Every challenge is required to continue. 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.
Stretch problems. Every challenge is required to continue. 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.
Stretch problems. Every challenge is required to continue. 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.
Stretch problems. Every challenge is required to continue. Auto-graded.
→ View full module pagePick one of four problems with your partner, settle it on a flowchart, and get all eleven checks green. The build lesson does not open until this one does.
Turn the chart you just passed into a documented, loop-driven program. Ten checks, all of them things Chapter 2 taught. Auto-graded.
The writeup that goes with the live demo: who did what, three test cases, and where all five of Chapter 2's sections show up in your program. AI-graded with hints.
→ View full module pageEight questions: three on the ideas of Chapter 2, five where you read a short program and say what it prints. One submission, nothing marked on screen.
Three short-answer questions. Explain the ideas in your own words. AI-graded: submit, read the feedback, and revise as many times as you like.
Four bugs in one program. Run it, read what happens, fix each one, and name what kind of bug it was. Fixed, the program runs top to bottom and prints a correct receipt.
Pick one of three problems and chart its loop on a flowchart. All eleven checks must pass. The chart is graded as a legal drawing, never against the answer.
One problem, pick one of three, write the JavaScript it describes: a nested loop, a branch, a break or continue, a guard. Three attempts, no Run button.
→ 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.
Spot which lines are function calls and count how many run. Checked instantly.
Trace what JavaScript actually does when it reads a function definition versus when it runs a call — and why a call written above its definition still works.
Take a broken function header — missing parentheses, wrong-case name — and fix both problems. Auto-graded.
Three reasons to write functions at all: modularity, reusability, maintainability.
Watch the same three distance calculations shrink from nine lines to three once the math moves into one function.
Write a parameterless function, concessions(), that prints the food and drink options at a cinema, then call it. Auto-graded.
Write terms(), a parameterless function that asks the user to accept terms and conditions, then call it once per user in a loop. Auto-graded.
The starter prints a repeated header three times. Rewrite it so the header lives in one function, called three times, with the output unchanged. Auto-graded.
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.
Take your grade-advisor program from 2.1.42 and break it into two named, parameterless functions: decideGrade() and printAdvice(). Auto-graded.
Draw the grade-advisor program you just refactored, using the double-rail shape for decideGrade() and printAdvice(). The after-chart to 3.1.12's before-chart.
Eight multiple-choice questions on identifying calls, defining functions, hoisting, naming, and benefits. Checked instantly.
→ View full module pageParameters and Return Values slides. Placeholder until the deck is built from the book.
Parameters let you pass inputs into a function. return sends a value back out so you can store or use it.
A function with a parameter leaves a blank for the caller to fill, so one definition can produce a different result every time you call it.
These two words are used interchangeably in conversation but mean different things precisely: a parameter lives in the definition, an argument is passed at the call.
A function matches arguments to parameters by position, not by name, so swapping two arguments changes the answer without raising an error.
Define findRectangleArea(width, height) that works out the area and prints it, then call it twice. Auto-graded.
Draw a program that passes a value into a function with a parameter, and get the call shape and the value flow right.
return ends a function and hands a value back to the caller, so the call becomes an expression you can store, print, or use in arithmetic.
return does two jobs at once: it hands back a value and stops the function right there, so anything after it does not run.
Write a function whose first check returns early when the input is invalid, so the valid path runs without an else. Auto-graded.
console.log shows a value to a human; return gives it to the program. A function that prints produces undefined, which is why its result is unusable.
A function computes correctly but prints its result, so the caller gets undefined. Fix it to return, and prove the fix with arithmetic. Auto-graded.
Because a call to a returning function is itself a value, calls can be fed straight into other calls, which is how small functions build up to big programs.
Draw two nested calls so the value handed from the inner function to the outer one is visible on the chart.
Write two returning functions, then feed one result into the other and log the chain. Auto-graded.
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.
Write a global and a local variable, then try to read the local one outside its function and watch the ReferenceError. Auto-graded.
Define two functions, findMax(a, b) and isEven(n), that take parameters and return a value. Auto-graded.
Define sumToN(n) that uses a for loop to add every integer from 1 to n and returns the total. Auto-graded.
Eight multiple-choice questions on parameters, arguments, return, and why printing is not returning. Checked instantly.
→ 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 how assigning to arr[i] replaces one item without changing the array's length. Read before the index-assignment lab.
Reassign one value inside an array by its index to update a score in place. Auto-graded.
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 .unshift() and .shift(), the front-of-list partners to .push() and .pop() you already know. Read before the queue lab.
Use push and shift to move people through a queue, first in first out. Auto-graded.
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.
Learn how a whole array can be one function parameter, and how a function can build and return a new array. Read before the filter-function lab.
Write a function that builds and returns a new array of transformed values, proving the original is untouched. Auto-graded.
Learn how an array can hold other arrays, which is how you store a grid or a table of rows. Read before the nested-array lab.
Read and reassign values in a nested array with double-index syntax, then sum every cell with a nested loop. Auto-graded.
Work with lists of values: create, add, remove, and iterate.
→ View full module pageFunction Expressions and Arrow Functions slides. Placeholder until the deck is built from the book.
A function can be stored in a variable, copied, and passed around like a number or a string. Read before the function-expression exercises.
When a function is a value, you can write it directly on the right of an equals sign. Meet the function expression and how it differs from a declaration.
Take a named function declaration and rewrite it as a function expression assigned to a const, then call it. Auto-graded.
Arrow functions are a shorter way to write a function expression. Learn the (parameters) => result shape and see one function in all three forms.
The four optional shortenings of an arrow function, including the implicit return and the classic braces mistake that produces undefined.
Expand a one-line arrow into the steps it actually runs: read the parameters, call the callback, decide whether it has run twice, and print the result.
Write three one-line arrow functions using implicit return, and call each one. Auto-graded.
Because a function is a value, it can be an argument. Learn what a callback is and why passing one separates the loop from the rule.
Write a helper that takes a callback, then pass it a one-line arrow. Auto-graded.
A declaration is hoisted and can be called from above its line; an expression or arrow cannot. Learn the one real difference and when to choose each.
Chart the rule for choosing between a declaration, an expression, and an arrow: is it a main operation or a short helper, and how many parameters does it take?
Convert three function declarations into one-line arrow expressions and confirm each still behaves the same. Auto-graded.
A two-parameter arrow function was written without the parentheses around its parameters, so the line will not parse. Fix it. Auto-graded.
Write a counting helper that takes a callback, then use it with a one-line arrow to count matching values in an array. Auto-graded.
Chart one operation walking through all three function forms, so the piece each form adds or drops — name, return, parens — is visible side by side.
Group code into reusable logic blocks with parameters and return values.
Eight multiple-choice questions on function values, expressions, arrow shorthand, callbacks, and hoisting. Checked instantly.
→ View full module pageObjects and Properties slides. Placeholder until the deck is built from the book.
Why an object exists: several facts about one thing, grouped under a single name with key: value pairs.
Read a property with a dot, change or add one by assignment, remove one with delete, and know why a missing property is undefined, not an error.
Build one object, read a field with a dot, change a field, add a new field, and print the object. Auto-graded.
When dot notation cannot work: keys with spaces, and keys held in a variable. Square brackets evaluate the name first.
Read a key with a space and a key held in a variable, and print every key/value pair with Object.keys. Auto-graded.
A property's value can be another object or an array. Read a nested chain left to right, and see the array-of-objects shape.
Chart a loop that reads a nested field inside an array, then a decision on a nested value. Get the loop's arrows landing in the right place.
Build an object with a nested object and an array of objects, then read values out of it. Auto-graded.
A method is a property whose value is a function, called with parentheses. See why word.toUpperCase needs () but word.length does not.
Give an object a method, call it, and print its return value. Auto-graded.
Pass one options object instead of several positional arguments, so every value carries its name to the call site and order cannot swap it.
Take a function with three positional parameters and rewrite it to read one options object instead. Auto-graded.
Unpack properties into variables in one statement. Objects match by name, arrays match by position.
Chart a function whose body destructures its parameter, and see the unpack as its own task before the work that uses it.
Unpack three fields in one statement, use the bare names, and rewrite a function to destructure its parameter. Auto-graded.
Refactor three parallel arrays into one array of records, then read the fields back with a dot. Auto-graded.
Build an array of records, read fields with dots and brackets, and destructure a record into variables. Auto-graded.
Eight multiple-choice questions on object literals, dot vs bracket access, nesting, methods, options objects, and destructuring. Checked instantly.
→ View full module pagePass by Value/Reference slides. Placeholder until the deck is built from the book.
Primitives (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.
Write one function that reassigns a number parameter and one that mutates an array parameter, then log the caller's variables to prove which change escaped. Auto-graded.
Mutating an object changes what it holds; reassigning a name points it somewhere else. Only one of those reaches the caller.
Trace a function that mutates an array and then reassigns it, and chart which write the caller can see.
A function is supposed to update the caller's array but reassigns its parameter instead, so nothing changes. Fix the body so the update reaches the caller. Auto-graded.
A side effect is a change that outlives the call. Make it the whole job or work on a copy so the caller's data survives.
Protect the original by copying before you change: spread [...arr] makes a new array so mutations stay in your copy.
Mutate a property on an object parameter and prove the caller sees it, then write a non-mutating version that keeps the original untouched. Auto-graded.
Show that a spread copy is only one level deep: change a nested array inside the copy and the original still changes. Then fix it with a deep copy. Auto-graded.
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.
Build a small scorebook that adds scores without harming the caller's array, and a function that updates an object's property the caller can see. Auto-graded.
Eight multiple-choice questions on primitives vs objects, mutation vs reassignment, side effects, and defensive copying. Checked instantly.
→ View full module pageArray Methods slides. Placeholder until the deck is built from the book.
Learn how .map() builds a new array by calling your callback once per element, and why the original list is never changed. Read before the .map() lab.
Use .map() to build a transformed copy of an array, then demonstrate the original is unchanged. Auto-graded.
Draw what .map() does to each element: an implicit loop, one callback call per item, and the collected results. Get the loop-back arrow right.
Learn how .slice(start, end) copies part of an array, why the end index is excluded, and why the original is never changed. Read before the .slice() lab.
Create an array, copy a middle range and a run to the end with .slice(), then show the original is unchanged. Auto-graded.
Learn how .concat() returns a new array with another array's items added on the end, leaving both originals untouched. Read before the .concat() lab.
Join two arrays into a new one with .concat(), then show both originals are unchanged. Auto-graded.
Learn how the spread operator ... unpacks an array into separate arguments, and how the same three dots mean the opposite in a function definition. Read before the spread-call example.
Learn how spread copies contents into a new array or object literal, and how { ...obj, field } makes a copy with one value changed. Read before the spread labs.
Draw the two directions the three dots can point: a definition that gathers arguments into an array, and a call that unpacks an array into arguments.
Use spread to combine two arrays and to add loose values around a copied one, without changing any input. Auto-graded.
Use object spread to copy an object with one property overridden and one property added, leaving the original untouched. Auto-graded.
Meet the array methods this book does not teach but other people's code uses: filter, forEach, reduce, indexOf, includes, sort, reverse, and every. Read to recognize them.
Demonstrate one method that changes its array and one that returns a new array, logging before and after each. Auto-graded.
Combine the module's non-mutating tools: build a list, transform it with .map(), take a range with .slice(), join with .concat() or spread, and copy an object with an override. Auto-graded.
Eight multiple-choice questions on .map(), .slice(), .concat(), spread, rest, and mutating versus non-mutating methods. Checked instantly.
→ View full module pageSaving and Loading Data slides. Placeholder until the deck is built from the book.
See why a value that only lives in memory is gone the moment the tab closes, and why everything that stores data stores text. Read before the stringify reading.
Learn how JSON.stringify turns an object or array into a single string with every property intact, and what changes from a JavaScript literal. Read before the stringify lab.
See how the second and third arguments to JSON.stringify turn compact text into indented, human-readable output, and when to use each form.
Learn what JSON silently drops — functions and undefined values — and why that is JSON storing data rather than behaviour, not a bug.
Build an object that has a method and an undefined property, stringify it, and find out in the output what JSON refused to carry. Auto-graded.
Learn how JSON.parse turns a JSON string back into a real value whose numbers add and whose arrays have a length. Read before the round-trip labs.
Save an object to JSON text, restore it with JSON.parse, and prove the restored copy is independent of the original. Auto-graded.
Round-trip a game-state shape — an object holding an array of item objects — through stringify and parse, then read a nested field back. Auto-graded.
Learn that JSON.parse throws a SyntaxError on malformed text, and why text you loaded is text you did not write so the call belongs in a try...catch.
Write a function that parses text and returns a usable fallback instead of letting a bad string stop the program. Auto-graded.
Learn how localStorage saves a string under a name you choose, why everything comes back as a string, and why a never-saved key gives null. Read before the save/load labs.
Draw the whole save-and-load pattern: stringify to save, read the key, decide whether anything was stored, parse inside a try, and fall back to defaults. Get both decision exits right.
Turn a state object into JSON text and store it under a key so it survives the page closing. Auto-graded.
Read a saved key, cope with a never-saved key, and parse the stored text back into a usable object with a fallback. Auto-graded.
Learn why a browser page gets no filesystem access at all, and why reading a local file requires the user to pick it. Read to close out the module before the sandbox example.
Combine the whole module: save a state object by key, load it back with the missing-key and bad-parse guards, and print the restored values. Auto-graded.
Apply the save/load pattern to an array of records rather than a single object, and read one record's field back out. Auto-graded.
Eight multiple-choice questions on JSON.stringify, JSON.parse, what does not survive a round trip, parse failures, saving by key with localStorage, and the browser sandbox. Checked instantly.
→ View full module pagePick one of four problems with your partner, settle who owns which function, and get all eleven checks green. The build lesson does not open until this one does.
Turn the chart you just passed into five documented functions and a short main section. Eleven checks, all of them things Chapter 3 taught. Auto-graded.
The writeup that goes with the live demo: who did what, three test cases, and where all eight of Chapter 3's sections show up in your program. AI-graded with hints.
→ View full module pageEight questions: three on the ideas of Chapter 3, five where you read a short program and say what it prints. One submission, nothing marked on screen.
Three short-answer questions. Explain the ideas in your own words. AI-graded, summative: one submission, nothing marked on screen.
Four broken programs. Identify each bug, name its type (syntax / runtime / logic), and fix it. One sitting; your teacher marks it afterwards.
Pick one of three problems and chart its functions and its loop on a flowchart. All eleven checks must pass. The chart is graded as a legal drawing, never against the answer.
One problem, pick one of three, write the JavaScript it describes: functions with parameters and returns, an array of records, map, spread, and a save/load round trip. One attempt, no Run button.
→ View full module pageQ1 Synthesis Project 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 Q1 Synthesis 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 Q1 Synthesis Project.
Design day: chart the whole program before any build time. One double-rail per planned function, under twenty shapes. The build lessons open when this is green.
Q1 synthesis: build a program that meets a checklist of requirements. Arrays of objects, functions, sorting, save/load, and your own tests — the rest is your call.
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 moSHion calls setup() once and draw() every frame. Read before 5.1.5 (Canvas).
How new Canvas(w, h) opens the drawing area and why (0, 0) is top-left with y increasing downward. Read before 5.1.6 (Sprite).
How new Sprite(x, y, w, h) creates a rectangle the engine renders for you, and how .color sets its fill. Read before 5.1.7 (lab).
Practice from 5.1.6: 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 5.1.9.
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 5.1.10.
How to read and write the core sprite properties pos, rotation, and layer after the sprite is created. Read before 5.1.4 (worked example).
Your first moSHion 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 5.1.15 (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 5.1.14.
The canonical if/else-if/else pattern that maps key presses to velocity changes inside draw(). Read after 5.1.15.
Why velocity persists across frames and why the else branch is what stops the sprite. Read after 5.1.16.
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 5.1.18.
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 pageGravity, ground-gated actions, bounciness and friction, forces, and cleanup slides. Placeholder until the deck is rebuilt from bookSHelf.
world.gravity.y and dynamic vs static sprites. Read before 5.2.3 Lab: Tune Gravity.
Try different world.gravity.y values on the same scene and describe how each one feels. Non-graded: discuss with a partner.
colliding() and edge-triggered kb.presses vs level-triggered kb.pressing. Read before 5.2.5 Lab: Add a Jump.
Gate a jump on a key press and a ground check. Auto-graded.
The two properties and the combining rule. Read before 5.2.7 Bouncy Ball.
Learn how bounciness and friction change how sprites feel.
applyForce vs setting .vel directly. Read before 5.2.9 Lab: Wind Zone.
Push the player with applyForce inside a conditional zone. Auto-graded.
delete() vs .visible. Read before 5.2.11 Lab: Reaching the Goal.
A single-fire win check with delete(). Auto-graded.
Build a pinball-style scene: static obstacles, a bouncy ball, gravity, and a reset key. Auto-graded.
Why setting .vel every frame fights the physics engine, and when applyForce is the better tool. AI-graded with hints.
Add a second, harder-to-reach goal and track a two-goal completion count. Auto-graded.
→ 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 moSHion 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 5.3.4.
What new does mechanically: allocate, run constructor, return. Read right after 5.3.3.
How the constructor receives arguments from new and stores them on this. Read right after 5.3.4.
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 5.3.6 / 5.3.12 worked examples and the 5.4.10 Enemy class worked example.
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 5.4.
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 6.1.5 Groups Sandbox.
moshion docs chapter on Groups. Read before 6.1.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 6.2.2 Apple Catcher.
moshion docs chapter on collisions and overlap detection. Read before 6.2.5 Safe Despawn.
Live demo of why for (let i = 0; i < group.length; i++) + .delete() skips items, and how to fix it. Watch before 6.2.5 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 6.3.4 Edge-triggered Input.
moshion docs chapter on input: kb.pressing (level-triggered) vs kb.presses (edge-triggered). Read before 6.3.4 Edge-triggered Input.
The infinite-jump bug live, and the colliding(ground) fix. Watch before 6.3.7 Ground Detection.
moshion docs on sprite.colliding(other) and the ground-gated jump idiom. Read before 6.3.7 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 6.4.9 Animated Sprites Sandbox.
moshion docs chapter on Animation. Read before 6.4.9 Animated Sprites Sandbox.
How sprite.addAni(name, frame1, ...) registers a named animation and makes it the active default. Read before 6.4.5 (changeAni).
How sprite.changeAni(name) swaps the active animation between previously registered names. Read before 6.4.8 (Worked Example).
How sprite.animation.frameDelay = N slows or speeds an animation cycle. Read before 6.4.9 (Animated Sprites Sandbox).
How sprite.image = url displays a still image without any animation cycle. Read before 6.4.9 (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 6.4.16 Worked Example: Camera Follow.
moshion docs chapter on Camera. Read before 6.4.16 Worked Example: Camera Follow.
How assigning camera.x and camera.y shifts the viewport center each frame. Read before 6.4.13 (Camera-follow pattern).
How camera.x = player.pos.x inside draw() locks the viewport onto a moving sprite. Read before 6.4.16 (Worked Example: Camera Follow).
How lerp(current, target, t) replaces a hard-set camera follow with a smooth elastic trail. Read before 6.4.17 (Worked Example: Smooth Camera).
How sprite.layer = N controls draw order so HUD elements always render on top of world geometry. Read before 6.4.18 (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 6.5.6.
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 moSHion 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 opening slides: the input ideas you need before the capstone: mouse position, click vs. held, dragging, and two-player key schemes. Joints and the slingshot pattern follow in Unit 6.8. 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 6.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 6.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.
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 6.7.16 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 6.7.15 Worked Example: Bounciness Comparison.
Three 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.
applyForce(fx, fy) adds a one-frame impulse to a sprite: the physics engine turns it into motion. Read this before 6.8.9 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 6.8.9 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.
Three optional stretch prompts for Unit 6.8: build a SliderJoint piston sandbox, a trebuchet that uses a DistanceJoint + HingeJoint together, or a swinging rope chain with three or more HingeJoints.
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.
You've built every piece: mouse input, joints, forces, two-player games, state machines, saves. This short video closes Units 6.7 and 6.8 and previews what Unit 7.1 asks you to do: design and pitch your own game from scratch.
→ 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 pageMeet reSHape: a part is a recipe of steps you can always go back and change, in millimetres, shown as buttons or as text.
Add your first box in reSHape and set its size in the Dimensions panel. Auto-graded.
Reselect an earlier step in the timeline and change one of its numbers. Auto-graded.
Pick a face and drill a hole through it with the Hole tool. Auto-graded.
Pick a single edge and smooth it with the Round tool. Auto-graded.
Hollow out the box into an open-topped shell with the Hollow tool, with walls 3 mm thick. Auto-graded.
Every button you press on the Build side writes a line of text on the Code side. Same part, two views.
Find the number that controls the hole in the script, and change it. Auto-graded.
Write a box and a hole in Code, from scratch, with no buttons. Auto-graded.
Draw a flat rectangle, then pull it up into a solid 10 mm tall. Auto-graded.
Put it all together: a box, hollowed into a tray, with one softened edge. Auto-graded.
→ View full module page