In the last stage, students wrote some very simple functions - but more sophisticated functions demand a more thoughtful approach. The Design Recipe is a structured approach to writing functions that includes writing a purpose statement and test cases to ensure that the function works as expected. Once students have mastered the Design Recipe process, they can apply it to any word problem they encounter.

In this stage students practice using the Design Recipe to write functions which solve for word problems. Towards the end of the lesson students should be ready to begin using the Design Recipe on problems from your own math curriculum.

Determining when objects on the screen touch is an important aspect of most games. In this lesson we'll look at how the Pythagorean Theorem and the Distance Formula can be used to measure the distance between two points on the plane, and then decide whether those two points (or game characters) are touching.

Students discuss the components of their favorite video games and discover that they can be reduced to a series of coordinates. They then explore coordinates in Cartesian space, identifying the coordinates for the characters in a game at various points in time. Once they are comfortable with coordinates, they brainstorm their own games and create sample coordinate lists for different points in time in their own game.

To finish up their video games, students will apply what they have learned in the last few stages to write the final missing functions. We'll start by using booleans to check whether keys were pressed in order to move the player sprite, then move on to applying the Pythagorean Theorem to determine when sprites are touching.

Students get their first look at the inside of their own video games. They will start development by substituting in new Images, Strings, and Numbers for existing variables.

Returning to the Big Game we started in stage 7, students will use the Design Recipe to develop functions that animate the Target and Danger sprites in their games.

Booleans are the fourth and final data type that students will learn about in this course. In this stage, students will learn about Boolean (true/false) values, and explore how they can be used to evaluate logical questions.

Using Boolean operators, students will write code that compares values to make logical decisions.

Using Boolean operators, students will write code that checks the location of a sprite to make sure it doesn't go off-screen.

Using the same logic from the previous lesson, students will write code that checks whether their Target and Danger sprites have left the screen. If their function determines that a sprite is no longer visible on screen, it will be reset to the opposite side.

Currently, even when passing parameters to functions, our outputs follow a very rigid pattern. Now, suppose we want parameters with some values to create outputs using one pattern, but other values to use a different pattern. This is where conditionals are needed. In this stage students will learn how conditional statements can create more flexible programs.

Using conditionals, students will write functions and programs that change their behavior based on logical evaluation of input values.

In this lesson students explore the benefits (and potential security concerns) associated with routing traffic across the Internet. Building on their introduction to IP addresses in the previous lesson, students use a version of the Internet Simulator that allows messages to be sent only to an intended recipient, as indicated by the IP address. The Internet Simulator also allows students to examine the traffic that goes through all of the (simulated) routers on the network. They will discover that messages go through many different routers, may not always take the same path to reach the final destination, and that the routers (and their owners) can *see all of this traffic*!

In this and the subsequent lesson, we consider some of the strategies used to construct networks and find paths for data in them. While this has a connection to ideas about the Internet, the focus of these lessons is on algorithms, formal techniques, and processes for solving problems. Students will explore and solve the Minimum Spanning Tree (MST) problem, first, in an unplugged fashion on paper. The real challenge is not in solving a particular instance of the minimum spanning tree, but to develop an algorithm, a clear series of steps, that if followed properly, will solve any instance of the problem. There is a possible misconception to look out for: the MST has a definite, verifiable optimal solution, as opposed to the Text Compression problem (from Unit 1), which does not.

In this lesson students will explore the Single Source Shortest Path problem, by solving the problem with pencil and paper first, then by following a famous algorithm that solves the shortest path problem known as Dijkstra’s Algorithm. Even though this is an algorithms detour, there is a strong connection in this lesson to routing algorithms used on the Internet. This lesson also introduces ideas about how we analyze algorithms: looking for correctness, efficiency and running time. As foreshadowing: in the next lesson students will act out another distributed shortest path algorithm used by routers to learn about the Internet dynamically.

This lesson is the last of the algorithm series. Building off of the previous lesson about shortest path algorithms, the activity in this lesson shows how routers learn about the rest of the Internet in order to route traffic so it takes the shortest path. In the previous lessons, students use the Internet Simulator to send packets to other students through simulated routers. The path that the packet follows, and how the router knows where to send it, however, has been largely untouched. Today, students simulate the process of a router joining a network and generating a router table that would allow them to send packets to anyone else in their network as efficiently as possible. They then reflect on the process by comparing the similarities between the SSSP problem and the process the used today, and how it facilitates the structure of the Internet.

In this lesson student develop a protocol for reliably sending a message over an unreliable internet. The Internet Simulator has been setup for this lesson to restrict messages to no more than 8 characters each, and messages get dropped messages with some probability on every hop.

Students are given time to experiment with the Internet Simulator and develop their own protocol, possibly testing or demonstrating their protocol to their peers. At the conclusion of the lesson, students watch a short video explaining how these challenges are addressed in the real world with [v TCP] - the Transmission Control Protocol.

The core idea of this lesson occurs in the unplugged activity that kicks off the lesson, in which students try to keep track of IP addresses that had been randomly assigned to each student in the class, while at the same time the teacher occasionally changes students' addresses. This leads to identifying the need for an authoritative system for name-to-address mappings, known as the Domain Name System or [v DNS].

Students then briefly experiment with a DNS protocol in the Internet Simulator. The activity is similar, in that students will have to grapple with IP addresses changing in real time and use the built in DNS protocol to resolve the issues.

The lesson ends with students doing some rapid research about DNS and some of its vulnerabilities, particularly what are known as Denial of Service Attacks.

In this lesson students are introduced to another high-level protocol of the Internet, [v HTTP]. The lesson begins with a review of the layers of the Internet covered thus far, before transitioning to a video covering high-level protocols of the Internet, most notably HTTP. Students will investigate HTTP traffic generated within their own browser by accessing the browser’s developer tools and visiting a variety of websites. A handout summarizing the structure of HTTP is provided to help students understand the components of the HTTP requests and responses they will observe. The lesson concludes with students sharing their findings with their classmates and a reflection on how the layers of the Internet make use of abstraction.