Lessons Used in This Pathway

Working together using a Driver/Navigator group setup, students experiment with the Editor. They explore Number and String datatypes, and how they behave in this programming language.

Driver/Navigator 🖼Show image When programming in this class, you’ll be working together using the Driver/Navigator model. Each group can only have one "Driver" - their hands are on the keyboard, and their job is to manage the typing, clicking, shortcuts, etc. If you’re not a Driver, you’re a "Navigator" - your job is to tell the Driver where to go, what to type, etc. A good Driver types only what the Navigator tells them to, and a good Navigator makes sure to give clear and precise instructions.

Students should open code.pyret.org (CPO) in their browser, and click "Sign In". This will ask them to log in with a valid Google account (Gmail, Google Classroom, YouTube, etc.), and then show them the "Programs" page. This page is empty - they don’t have any programs yet! Have them click "Open Editor".

Our Editing Environment 🖼Show image This screen is called the Editor, and it looks something like the diagram you see here. There are a few buttons at the top, but most of the screen is taken up by two large boxes: the Definitions Area on the left and the Interactions Area on the right.

The Definitions Area is where programmers define values and functions that they want to keep, while the Interactions Area allows them to experiment with those values and functions. This is like writing function definitions on a blackboard, and having students use those functions to compute answers on scrap paper.

Math is a language, just like English, Spanish, or any other language. Languages have nouns (e.g. “ball”, “tomato”, etc.) and verbs, which are actions we can perform on these nouns (e.g. - I can “throw a ball”). Math and programming also have values, like the numbers 1, 2 and 3. And, instead of verbs, they have functions, which are actions we can perform on values (e.g. - “I can square a number”).

Languages also have rules for syntax. In English, for example, words don’t have ! and ? in the middle. In math and programming numbers don’t have & in them.

Languages also have rules for grammar. The cat sat. is a sentence, whereas The sat cat. is nonsense, even though all the words are valid syntax. The order of the words matters!

Keeping the importance of syntax and grammar in mind is helpful when learning to program!.

In Pyret, writing decimals as .5 (without the leading zero) results in a syntax error. Make sure students understand that Pyret needs decimals to start with a zero!

Our programming language knows about many types of numbers, and they behave pretty much the way they do in math. Discuss what students have learned:

Error messages are a way for Pyret to explain what went wrong, and are a really helpful way of finding mistakes. Emphasize how useful they can be, and why students should read those messages out loud before asking for help. Have students see the following errors:

This lesson introduces students to Booleans, a unique datatype with only two values: "true" and "false", and why they are useful in both the real world and the programming environment.

Boolean-producing expressions are yes-or-no questions and will always evaluate to either true (“yes”) or false (“no”). The ability to separate inputs into two categories is unique and quite useful!

For example, some rollercoasters with loops require passengers to be a minimum height to make sure that riders are safely held in place by the one-size-fits all harnesses. The gate keeper doesn’t care exactly how tall you are, they just check whether you are as tall as the mark on the pole. If you are, you can ride, but they don’t let people on the ride who are shorter than the mark because they can’t keep them safe. Similarly, when you log into your email, the computer asks for your password and checks whether it matches what’s on file. If the match is true it takes you to your messages, but, if what you enter doesn’t match, you get an error message instead.

Debrief student answers as a class.

Students learn how to apply functions in Pyret , reinforcing concepts from standard Algebra, and practice reading error messages to diagnose errors in code.

Students know about Numbers, Strings, Booleans and Operators -- all of which behave just like they do in math. But what about functions? Students may remember functions from algebra: fx = x + 4$\displaystyle f(x) = x + 4$.

Arguments (or "inputs") are the values passed into a function. This is different from variables, which are the placeholders that get replaced with input values! Pyret has lots of built-in functions, which we can use to write more interesting programs.

Have students log into code.pyret.org (CPO) , open the editor, type the words include image on Line 1 of the Definitions area (left side) and press "Run" to load the image library. Then type num-sqrt​(​16​) into the interactions area and hit Enter.

Have students type string-length​(​"rainbow"​) into the interactions area and hit Enter:

Have students complete Applying Functions (Page 4) to investigate the triangle function and a series of error messages. As students finish, have them try changing the expression triangle​(​50, "solid", "red"​) to use "outline" for the second argument. Then have them try changing colors and sizes!

Debrief the activity with the class.

This activity introduces the notion of Contracts, which are a simple notation for keeping track of the set of all possible inputs and outputs for a function. They are also closely related to the concept of a function machine, which is introduced as well. Note: Contracts are based on the same notation found in Algebra!

When students typed triangle​(​50, "solid", "red"​) into the editor, they created an example of a new data type, called an Image.

The triangle function can make lots of different triangles! The size, style and color are all determined by the specific inputs provided in the code, but, if we don’t provide the function with a number and two strings to define those parameters, we will get an error message instead of a triangle.

As you can imagine, there are many other functions for making images, each with a different set of arguments. For each of these functions, we need to keep track of three things:

The Name, Domain and Range are used to write a Contract.

Where else have you heard the word "contract"? How can you connect that meaning to contracts in programming?

An actor signs a contract agreeing to perform in a film in exchange for compensation, a contractor makes an agreement with a homeowner to build or repair something in a set amount of time for compensation, or a parent agrees to pizza for dinner in exchange for the child completing their chores. Similarly, a contract in programming is an agreement between what the function is given and what it produces.

Contracts tell us a lot about how to use a function. In fact, we can figure out how to use functions we’ve never seen before, just by looking at the contract! Most of the time, error messages occur when we’ve accidentally broken a contract.

Contracts don’t tell us specific inputs. They tell us the data type of input a function needs. For example, a Contract wouldn’t say that addition requires "3 and 4". Addition works on more than just those two inputs! Instead, it would tells us that addition requires "two Numbers". When we use a Contract, we plug specific numbers or strings into the expression we are coding.

Let’s take a look at the Name, Domain, and Range of the functions we’ve seen before:

Optional: Have students make a Domain and Range Frayer model (Page 5) and use the visual organizer to explain the concepts of Domain and Range in their own words.

Have students complete pages Practicing Contracts: Domain & Range (Page 6) and Matching Expressions and Contracts (Page 7) to get some practice working with Contracts.

This activity digs deeper into Contracts. Students explore image functions to take ownership of the concept and create an artifact they can refer back to. Making images is highly motivating, and encourages students to get better at both reading error messages and persisting in catching bugs.

(If needed, you can print a copy of these contracts pages for your students.)

Students are given contracts for some more interesting image functions and see how much more efficient it is to write code when starting with a contract.

You just investigated image functions by guessing and checking what the contract might be and responding to error messages until the images built. If you’d started with contracts, it would have been a lot easier!

Have students turn to Using Contracts (Page 8), Using Contracts (continued) and use their editors to experiment.

Once they’ve discovered how to build a version of each image function that satisfies them, have them record the example code in their contracts table. See if you can figure out what aspect of the image each of the inputs specifies. It may help you to jot down some notes about your discoveries. We will be sharing our findings later.

Have students turn to Triangle Contracts (Page 9) and use the contracts that are provided to write example expressions. If you are ready to dig into triangle-sas, you can also have students work through Triangle Contracts (SAS & ASA).

Sometimes it’s helpful to have a contract that tells us more information about the arguments, like what the 3 numbers in a contract stand for. This will not be a focal point of our work, but to give students a taste of it, have them turn to Radial Star (Page 10) and use the contract to help them match the images to the corresponding expressions. For more practice with detailed contracts you can have them turn to Star Polygon to work with the detailed contract for a star-polygon. Both of these functions can generate a wide range of interesting shapes!

Make sure that all students have completed the shape functions in their contracts pages with both contracts and example code so they have something to refer back to.

Students are very likely to randomly experiment, rather than to actually use the Contracts. You should plan to ask lots of direct questions to make sure students are making this connection, such as:

Divide students into groups of 3-4, and distribute a set of Function Cards to each group. Write down pairs of integers on the board, representing the "starting numbers" and "ending numbers". These integers should range from -50 to +50, but you can change the difficulty of the activity by making that span wider (more difficult) or more narrow (less difficulty). You can find a random integer generator here.

Give students time to experiment with this. You can make the activity more challenging by asking them to find the shortest path from start to end, using the smallest number of compositions.

If two groups come up with different compositions that achieve the same end result, have them share their ideas!

The Circles of Evaluation are extended to provide a visual-spatial metaphor for function composition, in addition to Order of Operations.

Three of the function cards we just used were for the functions f, g and h:

We can compose those function in any order. If we composed them as f(g(h(x))) and evaluated them for x = 4 what would happen?

We can diagram the function composition using Circles of Evaluation (see first column, below). In the second column, we’ve replaced the function names in each Circle of Evaluation with what each function does:

The circles show us that in order to evaluate f(g(h4)))$\displaystyle f(g(h(4))))$

Have students turn to Diagramming Function Composition (Page 12) to practice writing, translating and evaluating Circles of Evaluation of composed functions.

The Circles of Evaluation are extended to functions that do more than compute values.

Have students log into code.pyret.org (CPO) open a new program and save it as Function Composition.

Have students open to Function Composition — Green Star (Page 13), in which they will be drawing circles of evaluation to help them write expressions to compose a series of images.

Then have students open to Function Composition — Your Name (Page 14) in which they will create a text image of their name and experiment with other functions.

If you have time, you can also have students work with Function Composition — scale-xy (Page 15) and/or Function Composition Matching Activity (Desmos)

Students identify multiple expressions that will create the same image, and think about the merits of one expression over another.

Students complete More than one way to Compose an Image! (Page 16).

There is a special function in code.pyret.org (CPO) that let’s us test whether or not two images are equal.

is-image=:: Image, Image -> Boolean

Use it to test whether all of the expressions you wrote successfully build the same images.

This activity introduces the problem with duplicate code, leveraging Mathematical Practice 7 - Identify and Make Use of Structure. Students identify a common structure in a series of expressions, and discover how to bind that expression to a name that can be re-used.

Note that in Pyret definitions work the way variable substitution does in math, as opposed to variable assignment you may have seen in other programming languages.

Take a look at the expressions below:

There are lots of potential problems with duplicate code:

Since we’re using that star over and over again, wouldn’t it be nice if we could define a "nickname" for that code, and then use the nickname over and over in place of the expression? And then, if we wanted to change something about all of the stars, we would only have to make the change once, in the definition.

Once we’ve defined x to be the value 4 and clicked "run", anytime we use x, the computer will remember that it is defined as 4. We can use that definition to get an answer. For example, x + 2$\displaystyle x + 2$ will evaluate to 6.

Of course, the whole point of defining a value is so that it sticks around and can be used later! That’s why programmers put their definitions on the left-hand side, known as the Definitions Area.

Now that we know how to define values, we’ve got two more things to consider:

Have students open to Defining Values - Chinese Flag (Page 19). It will direct them to open the Chinese flag Starter File (Pyret) once they complete the first half of the questions on the page.

Students learn about the put-image function.

As you’ve already seen, overlay sticks two images together, so that the center of the first image is placed exactly on top of the center of the second image. But what if we want to put the dot somewhere besides the center?

The put-image function works like overlay, but instead of placing the centers of each image on top of one another, it translates the center of the top image by some distance in the x- and y-direction.

Have students open the Flags Starter File , and click Run.

There are some special lines in this file called comments. The programmer who wrote this code included a series of messages - called comments - that will never be read by the computer.

Professional programmers work with teams who need to be able to follow each other’s thinking in order to collaborate efficiently. Comments are a way for programmers to leave notes for one another, and even for a single programmer to keep track of their thinking when they come back to their code another day.

Have students open the Flags of Netherlands, Ireland, Mauritius Starter File , and click Run.

Once you’ve discussed the code for the flag of the Netherlands with your class, have them keep working with this starter file to write code for the flags of Ireland and Mauritius. Some students will make it through the challenges. Some students may only complete one flag. All of them will be synthesizing how to apply put-image and locate images on the coordinate grid.

Could we completely replace overlay with put-image? Why or why not?

Students focus on decomposing complex images into simple ones, and using put-image to combine them.

Let’s dig into the process for how the flags we’ve seen so far were made:

1) Decompose the Image

We observe that the Japanese flag is made up of two simpler images: a black, outline rectangle and a red dot.

2) Define those parts

We define dot and background. Once we’ve defined those images, we test them out in the Interactions Area to make sure they look right!

3) Find the Coordinates

For each image, calculate what the x- and y-coordinates of the center should be. TIP: this is a lot easier if you have a sheet of graph paper handy!

4) Build the Image & Check that it Matches the Target Image

We stack the parts on top of the bottom image using the coordinates we found. TIP: don’t cram all the code into one line! If you break it up into new lines (for example, hitting "Return" before the x-coordinate and after the y-coordinate), you’ll notice that the code forms a "staircase" pattern. Be sure to compare the image you get with the target image!

If you have time, these matching activities will support student thinking.

Which flags were the easiest to make? The hardest?

Why is it useful to define each part of the flag first, before stitching the images together?

In this lesson, students will build their flexibiltiy of thinking by engaging with multiple representations. Students will search for structures that are dynamic, meaning they change in a predictable way. This is the foundation for defining functions.

Students should have their workbook, pencil, and be logged into code.pyret.org on their computer.

I Love Green Triangles 🖼Show image

I Love Green Triangles 🖼Show image

This is a fun lesson to make silly! Dramatically confess to your students, "I LOVE green triangles!" Challenge them to use the Definitions Area to code as many unique, solid, green triangles as they can in 2 minutes.

Walk around the room and give positive feedback on the green triangles. When the time is up, ask for some examples of green triangles that they wrote and copy them to the board. Be specific and attend to precision with the syntax such that students can visually spot the pattern between the different lines of code.

Select a student to act out gt. Make it clear to the class that their Name is "gt", they expect a Number, and they will produce an Image. Act out some examples before having the class add their own and record them on the board:

Thank your volunteer. Assuming they did a wonderful job, ask them:

Have students turn to Matching Examples and Definitions (Math) (Page 26).

You may also want to have students complete Matching Examples & Function Definitions (Desmos)

Now that we’ve seen how this works in math, let’s go back to gt.

400 🖼Show image

400 🖼Show image

You may also want to have students complete Matching Examples & Function Definitions (Desmos) .

Have students turn to Matching Examples and Contracts (Page 28).

Confirm that everyone is on the same page before moving on. You may want to have students turn to a partner, compare their findings, and discuss their thinking about anything they didn’t agree on at first.

Have students open the gt starter file (Pyret) .

Have students turn to Contracts, Examples & Definitions (Page 29)

If you have time, have students complete

In this lesson students build on what they already know about multiple representations of functions (contracts, examples and definitions) to write purpose statements and gain fluency with the Design Recipe.

Have students turn to Creating Contracts From Examples (Page 32) and write contracts for the examples provided.

You’ve started to master most of the steps of the Design Recipe, but there’s one part you haven’t seen yet: writing a purpose statement. On its own, a contract is not enough information to generate examples and write a function definition. We need to know what the function is supposed to do with what it takes in. Programmers and Mathematicians alike find it helpful to restate a problem in their own words. After all, if you can’t explain a problem to someone else, you probably don’t understand it yourself!

Debrief the notice and wonder as a class. Then have students write examples that satisfy each of the contracts and purpose statements on Writing Examples from Purpose Statements (Page 33).

OPTIONAL: For more practice, have students complete Writing Examples from Purpose Statements 2.

What are the important elements of purpose statements? Why are purpose statements useful?

Students are given a non-working program, which uses a linear function to determine the height of a rocket after a given length of time. The "broken" code is provided to lower cognitive load, allowing students to focus on comprehension (reading the code) and making use of structure (identifying where it’s broken).

Students should have their workbook, pencil, and be logged into code.pyret.org on their computer.

Ask students to open the rocket-height Starter File (Pyret) and click "Run". By typing start(rocket-height), they will see the simulation start to run on their computer.

Survey the class on their "Notices" and "Wonders" and record on the board before moving on to the discussion.

Let’s use the Design Recipe to fix rocket-height, and get comfortable with writing purpose statements.

Have students turn to Word Problem: rocket-height (Page 34), read the problem statement with their partner and write down the Contract and purpose statement. Then, given the contract and purpose statement, write two examples of how rocket-height should work after two different lengths of time.

Once the Design Recipe has been completed in the workbook, students can type the code into the rocket-height program, replacing any incorrect code with their own code.

The Design Recipe allows us to trace mistakes back to the source!

For teachers who cover quadratic and exponential functions, this activity deepens students' understanding of functions and extends the Design Recipe to include those. This can also be a useful activity for students who finish early, or who need more of a challenge.

Now that rocket-height is working correctly, explore the rest of the file and try the following:

Debrief - what did students try? Have students share their experiments with one another!

Students are introduced to Reactors, Pyret’s mechanism for created animated time-based simulations or interactive programs. With Reactors serving as the bridge between making images and defining data structures, students begin to create simple animations.

You’ve learned how to create data structures, and how to create images. Now it’s time to put these together to create an animation in Pyret. We’ll even go a step further than what we did in Bootstrap:Algebra, creating an animation with movement in two dimensions.

In Bootstrap:Algebra, many decisions about your animation were made for you. We told you how many characters you had and which aspects of them could change during the animation. The danger always moved in the x-axis, the player always moved in the y-axis. In Bootstrap:Reactive, we give you much more control of your game: you decide how many characters you will have, and what aspects of them can change (position, color, size, etc). In order to have this flexibility, we need to do a little more work to set up the animation. Let’s break down an animation to see what we need.

Let’s create an animation of a sunset. The sun will start at the top-left corner of the screen and fall diagonally down and right across the sky. Here’s a running version of the animation we are trying to create. Notice that the sun dips below the horizon in the bottom-right corner.

🖼Show image

In Bootstrap:Algebra, we talked about how an animation is made of a sequence of images that we flip through quickly. We continue to think of an animation as a sequence of images in Bootstrap:Reactive. For example, here are the first three frames of the sunset animation:

🖼Show image

Where will we get this sequence of images? We don’t want to create them all by hand. Instead, we want to write programs that will create them for us. This is the power of computer programming. It can automate tasks (like creating new images) that might otherwise be tedious for people to do. There are four steps to creating animations programs. You’ve actually already done the first three in the first two units, but now we need to show you how to put them together.

This is a key point at which to emphasize why functions are important to computer science. Computers are good at repetition, but they need instructions telling them what steps to repeat. Functions capture those instructions.

The first step is to develop a data structure for the information that changes across frames. To do this, we need to figure out what fields our data structure will need.

To identify the fields, we have to figure out what information is needed to create each frame image. Information that changes from frame to frame must be in the data structure.

Hopefully, you identified two pieces of changing information: the x-coordinate of the sun and the y-coordinate of the sun. Each image also contains the horizon (the brown rectangle), but that is the same in every frame. Let’s write down a data structure that captures the two coordinates.

You should have come up with something like this: a data block with numbers for the two coordinates.

The term state is used in computer science to refer to the details of a program at a specific point in time. Here, we use it to refer to the details that are unique to a single frame of the animation.

We have the students copy the images into the workbook partly to make sure they understand what images they are working with and partly so that they have a self-contained worksheet page for later reference.

Any time we make a data structure, we should make some sample instances: this helps check that we have the right fields and gives us data to use in making examples later.

The second step in making an animation is to write a function that consumes an instance of one state and produces the image for that instance. We call this function draw-state. For sunset, draw-state takes a SunsetState instance and produces an image with the sun at that location (dipping behind the horizon when low in the sky). This function should use put-image, as we did with the hikers in unit 1.

You may have noticed that we used SunsetState instead of sunset as the domain name. Remember that sunset is just the name of the constructor, while SunsetState is the name of the type. We use SunsetState whenever we need a type name for the domain or range.

We can now draw one frame, but an animation needs many frames. How can we draw multiple frames? Let’s simply the problem a bit: if you have the instance for one frame, how do we compute the instance for the next frame? Note we didn’t ask how to produce the image for the next frame. We only asked how to produce the next SunsetState instance. Why? We just wrote draw-state, which produces the image from a SunsetState. So if we can produce the instance for the next frame, we can use draw-state to produce the image.

The third step in making an animation is to write a function that consumes an instance of one state and produces the instance for the next state. We call this function next-state-tick. For sunset, next-state-tick takes a SunsetState instance and produces a SunsetState instance that is just a little lower in the sky.

Together, the draw-state and next-state-tick functions are the building blocks for an animation. To start to see how, let’s first use these two functions to create the first several frames of an animation by hand (then we’ll show you how to make more frames automatically).

Do you see the sun getting lower in the sky from image to image? Do you see how we are creating a “chain” of images by alternating calls to draw-state and next-state-tick? We use next-state-tick to create the instance for a new frame, then use draw-state to produce the image for that frame.

Do you see what this sequence of expressions does? Each one starts with the sun in the upper-left corner, calls next-state-tick one or more times to compute a new position for the sun, then draws the state. Notice that this sequence only has us write down one SunsetState instance explicitly (the first one). All the others are computed from next-state-tick. If we could only get Pyret to keep making these calls for us, and to show us the images quickly one after the next, we’d have an animation!

The fourth (and final) step in making an animation is to tell Pyret to create an animation using an initial SunsetState instance and our draw-state and next-state-tick functions. To do this, we need a new construct called a reactor. A reactor gathers up the information needed to create an animation:

A reactor is designed to “react” to different events. When the computer’s clock ticks, we’d like to call next-state-tick on the reactor’s state, and have it update to the next state automatically. Reactors have event handlers, which connect events to functions.

Here, we define a reactor named sunset-react for the sunset animation:

init tells the reactor which instance to use when the program starts. In this example, the program will start with a SunsetState instance with the sun at (10, 30). on-tick and to-draw are event handlers, which connect tick and draw events to our next-state-tick and draw-state functions.

Separating the instance from the image of it is key here: when we produce an animation, we actually produce a sequence of instances, and use draw-state to produce each one. Students may need some practice to think of the instance as separate from the image that goes into the animation.

If you run your sunset program after adding the reactor, nothing seems to happen. We have set up an animation by defining sunset-react, but we haven’t told Pyret to run it. You could define multiple reactors in the same file, so we have to tell Pyret explicitly when we want to run one.

What happens when we call interact? The following diagram summarizes what Pyret does to run the animation. It draws the initial instance, then repeatedly calls next-state-tick and draw-state to create and display successive frames of your animation.

🖼Show image

These are the same computations you did by hand in the interactions window a little while ago, but Pyret now automates the cycle of generating and drawing instances. By having functions that can generate instances and draw images, we can let the computer do the work of creating the full animation.

Functions are essential to creating animations, because each frame comes from a different SunsetState instance. The process of drawing each instance is the same, but the instance is different each time. Functions are computations that we want to perform many times. In an animation, we perform the draw-state and next-state-tick functions once per frame. Animations are an excellent illustration of why functions matter in programming.

Summarizing what we have seen so far, we have to write four things in order to make an animation:

At this point, you could create your own animation from scratch by following these four steps. If you do, you may find it helpful to use one of the animation design worksheets at the back of your workbook: it takes you through sketching out your frames, developing the data structure for your animation state, and writing the functions for the animation. It also gives you a checklist of the four steps above. The checklist mentions a fifth (optional) step, which involves getting your characters to respond when the user presses a key. You’ll learn how to do that in the next unit.

The animation-design worksheet is a condensed summary of the steps to creating an animation. If your students still need more scaffolding, follow the sequence of sheets that we used to develop sunset, including explicit worksheets for draw-state and next-state-tick. If your students are doing fine without the scaffolding of the design recipe worksheets, the condensed worksheet should suffice to keep them on track (though they should still write tests and follow the other steps of the design recipe as they work).

You have just seen the incredible power of functions in programming! Functions let us generate content automatically. In the early days of making cartoons, artists drew every frame by hand. They had to decide at the beginning how many frames to create. Here, we let the computer generate as many frames as we want, by letting it call next-state-tick over and over until we stop the animation. If we want to slow down the sunset, we simply change the new coordinates within next-state-tick. If we start with a larger screen size, the computer will continue to generate as many images as we need to let the sun drop out of the window. The computer can give us this flexibility as long as we provide a function that tells the computer how to generate another frame.

An animation that only changes one number (e.g. - the x-coordinate of a plane flying across the sky, or the y-coordinate of a balloon floating upwards) uses that number as the Reactor state. But what if we wanted to do something more complex, which relied on keeping track of more than one number? This activity uses more complex animation to motivate the need for data structures.

🖼Show image You’ve learned the components of an animation in Pyret. The data structure for the state lies at the heart of the animation: each of the initial state, the draw-state function and the next-state-tick function are based on the data structure you choose. Being able to figure out the data structure you need for an animation is therefore a critical skills in making your own animations. In this lesson, we are going to practice identifying the data and creating the data structures for various animations. We will not write the entire animation. We are just going to practice identifying the data and writing the data structures.

Exercise: Jumping Cow — Look at this animation of a cow jumping over the moon.

When you chose which frames to draw, did you include ones with different images or heights of the cow? Choosing images with some variation will help you think through the data in your animation.

In this case, the cow’s x-coordinate and y-coordinate are both changing. The image changes too, but the position (coordinates) determines which image to use. The state data structure therefore only needs to store the coordinates.

If students want to include the image in the state, that is fine too. Examples like this are good for raising discussion about what parts of an animation depend on one another. The image doesn’t need to be in the state, but it isn’t wrong to include it there either.

🖼Show image Exercise: Bicycle Ride — Look at this animation of a person riding a bicycle along a street.

In this case, there are two pieces of information: the x-coordinate of the cyclist, and the angle of rotation of the bike tires.

🖼Show image Exercise: Pulsing Star — Look at this animation of a star that pulses as it moves across the sky.

When you chose which frames to draw, did you show the star getting smaller and then getting larger again?

The x- and y-coordinates of the star change, as does the size of the star. These changes are easy to see across two frames. Something else changes too, but you have to look across at least three frames to see it. Imagine you had a single frame with the star at size 25. In the next frame, should the star be larger or smaller? It’s hard to tell, because we don’t know whether the star is currently in a “growing” phase or a “shrinking” one. This animation actually has a fourth state field: the direction of growth of the star. When the star is getting bigger, the star’s size should increase in the next frame. When the star is getting smaller, the size should decrease in the next frame.

What type did you choose for the field that tracks the direction of growth? You have several choices: a boolean such as is-growing, a string such as direction (with values "grow" or "shrink"), or a number such growth-rate which is the amount to add to the size from state to state (a positive value grows the star while a negative value shrinks it). The code for next-state-tick will be cleaner if you use the number, but the others make sense before you’ve thought ahead to the code.

🖼Show image Exercise: Light Dimmer — Look at this animation of a slider to control the brightness of a light.

When you chose which frames to draw, did you include the far left position when the light goes out? It can be useful to think about the extreme cases when picking frames to focus on.

In this case, we see two things changing: the y-coordinate of the slider and the brightness of the light. You could have one field for each of these. Or, you could just have a field for the y-coordinate and compute the brightness from that value (you can control the brightness of a shape by putting a number from 0 to 255 in place of "solid" or "outline" in the arguments to the shape-image functions).

Exercise: Pong — For a real challenge of your data structure design skills, figure out the world data structure needed for a single-paddle pong game (a ball bouncing off the walls and a single user-controlled paddle). If you want to build an entire Pong game, see the optional unit on how to do this.

Students are introduced to Pyret’s if-then-else construct.

Sometimes we want our functions to behave one way for a certain input or condition, but a totally different way for a different input or condition. Piecewise functions in mathematics also have this property (think about absolute value!). So how do we write conditionals in Pyret?

An if expression has four parts:

The if clause has a question, followed by a : (a colon), followed by an answer for if the question evaluates to true. Each else if clause also has a question, followed by a colon, followed by an answer for if the question evaluates to true. The else: clause runs if none of the questions in the other clauses evaluated to true. It catches all the cases that aren’t covered by a specific question in one of the if or else if clauses.

The else: clause at the end of an if expression is optional. Typically, it is important to make sure your code will account for all possible conditions, and ending with else: is a useful catchall condition if all of the other conditions return false. However, this is optional in the case that every single possible condition is covered by else if statements.

At this point, we need to introduce an extension to the Design Recipe, to allow it to handle conditionals. If we look at the examples for wear, and circle everything that changes, both the input (the temperature) and the output (the image) change. However, wear only has a single variable according to the domain in its contract. Also, the image is completely dependent on the temperature — it isn’t a separate independent variable, so it wouldn’t make sense for it to be another element in the domain of wear. The fact that we have more changing things than elements in the domain tells us that wear must be a piecewise function. This is the same rule as in Bootstrap:Algebra, and just as we could in Racket, we can tell that a function must be piecewise just by looking at its contract and the examples. This helps us identify when a function we are writing in our games needs to use if, as long as we follow the Design Recipe when building it. Another way to recognize a piecewise function when looking at your examples is to note whether or not there are elements which completely depend on another. In wear, the image depends on the temperature, and does not change independently, or in response to any other changes in the function. Keep an eye out for these dependent variables in your examples as you write them to help identify piecewise functions.

This is an important point to review. Conditionals, or Piecewise functions, are a big moment in Bootstrap:Algebra, and the extension of the Design Recipe is key for students to design their own piecewise functions later on. In the next exercise, make sure they use the Recipe steps to remind them of the mechanics of this type of function.

Students connect conditional functions with behaviors in games, and write one from scratch.

Let’s revisit the package delivery drone from earlier. We’re going to write a function that tells us where the package is for a given DeliveryState. This is the kind of function you might need to write later on in your game. For example, you may need to know whether a character has reached a portal at a certain part of the screen to advance to the next level, or if they’ve fallen into dangerous lava!

In addition to writing your examples, you can also check that the location function’s behavior matches what a drawing of a DeliveryState instance shows. For example, if location returns "road" on some input, when we draw that same input, it ought to look like the package has landed in the road!

These experiments show an important connection between functions that work with instances of a data structure, and the way we draw those instances. In our design for the animation, we have an understanding of what different regions of the screen mean. Here, we see that the draw-state and location functions both share this understanding to give consistent information about the animation.

Students flex their conditional-function muscles, by looking at buggy conditions and figuring out what went wrong.

Open your workbook to Syntax and Style Bug Hunting: Piecewise Edition (Page 50). In the left column, we’ve given you broken or buggy Pyret code. On the right, we’ve given you space to either write out the correct code, or write an explanation of the problems with the provided code. Work through this workbook page, then check with your partner to confirm you’ve found all the bugs!

Students return to an animation they’ve created before, and enhance it by using conditionals.

Let’s return to your sunset animation from the previous unit. Currently, the sun’s x and y-coordinate change to make it move across the screen and disappear behind the horizon. In this unit, we’ll make the animation a bit more realistic, by changing the color of the sun as it gets lower in the sky. At the top of the screen, the sun should be yellow, then change to orange as it gets to the middle of the screen, and then become red as it reaches the bottom, close to the horizon.

In programming, it is fairly common that you will change a program that you’ve already written to do something new or different. Modifying existing code is a valuable skill, and one that we want to practice with this exercise. It is so useful, in fact, that we’ve created a worksheet to help you map out what needs to change in an existing animation to support new behavior.

Once you know what new behavior you want, the next task is to build it into your code. The next two tables in the worksheet ask you to think about the NEW features that are changing in your game and how you might capture them.

There are a number of ways students can solve this problem. Once students have brainstormed with their partners, have a classroom discussion to have pairs share their ideas.

Since the color of the sun will be changing, we could add a field to the SunsetState data structure, such as a String with the current color name. However, the color will not change independently: we want the color to change based on the position of the sun in the sky, and get darker as it gets lower. Let’s figure out how to make the sun color change based only on the fields we already have.

If we have decided not to add fields, you should have marked that the draw-state method changes, but nothing else needs to. We only change next-state-tick and next-state-key if there has been a change to the data structure.

You may need to guide students to realizing that a change in the appearance of the animation can be done entirely through draw-state. This is another point for emphasizing the separation between maintaining instances and drawing instances.

How do we change draw-state? Our first instinct may be to turn it into a piecewise function, and draw something different when the SunsetState’s y-coordinate gets below 225 or below 150. This would yield code along the lines of:

Notice that this version contains three very similar calls to put-image. The only thing that is different about these three calls is the color we use to draw the sun. Whenever you find yourself writing nearly-identical expressions multiple times, you should create another function that computes the piece that is different. You can then write the overall expression just once, calling the new function to handle the different part. Functions that handle one part of an overall computation are called helper functions.

Assume for the moment that we had written a helper function called draw-sun that takes a SunsetState and returns the image to use for the sun. If we had such a function, then our draw-state function would look as follows:

The word problem assumes a background scene size of 400x300 pixels. Once students use their draw-sun function in their animation, they may need to change the specific conditions if they have a much larger or smaller scene.

Once you’ve completed and typed the draw-sun function into your sunset animation program, modify draw-state to use it as we showed just above.

Now let’s think about having the sunset animation "`start again`"after the sun sets, with the sun reappearing in the upper-left corner.

To figure this out, think about what controls the color of the sun in your current code.

This question about the color of the sun is an especially good question-and it likely to come up-from students who may have experience programming with variables and updates in other languages, such as Scratch (where the color would have changed to red). In our approach, where we simply determine the sun color from the y-coordinate, the sun should naturally restart as yellow. Of course, if students had maintained the sun color as a separate field in their data structure, they would have to consider this issue, and manually reset the sun color as well as the y-coordinate when restarting the animation.

Optional: In addition to changing the color of the sun, have the background color change as well: it should be light blue when the sun is high in the sky, and get darker as the sun sets.

Like changing the color of the sun, there are multiple valid ways of completing this optional activity. If you have students solving the same problem with different code, have them share their code with the class and have a discussion about the merits of each version.

Students learn about events, and add key-event handling to their games.

We’ve already seen one kind of interactivity in our programs: getting the next state from the current state on a tick-event. This is perfect for animations that happen on their own, without any user intervention. In a game, that might be clouds moving across the sky or a ball bouncing on its own. An important kind of behavior in interactive programs is to respond user input, such as keypresses. A keypress, like the tick of a clock, is a kind of event, and we’ll re-use the idea of an event handler like on-tick and a function like next-state-tick. For key-events, the event handler is called on-key, and our function next-state-key will compute the next state from the current one after a key event. We’re going to use this idea to build up a reactor with a character moving in two dimensions, where the movement is triggered by keypresses.

It contains a data block for representing a character’s position (CharState) that has an x and y position.

This is a reminder that it’s often useful, when working on programs that use data to represent positions in an image, to make sure we understand what values in the data structure correspond to which drawing behavior.

There is also a contract for a function next-state-key, which looks like:

It is different from the contract for next-state-tick (which handles tick events) in an important way. When a key event happens, the next state may differ depending on which key was pressed. That means the next-state-key function needs both the current state and which key was pressed as parts of its domain. That’s why next-state-key has an additional String input, which represents the key pressed by the user.

This gives us a good input and output test for the examples block when working on next-state-key. What call to next-state-key should connect these two example instances?

It’s an important point that next-state-key takes in an extra piece of information: the pressed key. This makes it much richer in terms of its purpose statement, which should describe what different keys ought to do to the state of the reactor. Students will create something like this completed file by adding a next-state-key function

As with tick-events, we can manually pass keypress strings into this function, see what the next state would be, and even draw that state to see what it looks like. That’s great, but we still want to hook this function up to a reactor, so that it actually handles keypresses from a user playing the game. To do this, we need to create a reactor use on-key to specify that our next-state-key function should be called when the user presses a key (we don’t need to specify an on-tick handler, since for now the only movement in our program comes from keypresses). Our reactor with a to-draw and on-key handler looks like this:

With this working, you can see the behind-the-scenes work that was going on in Sam the Butterfly from Bootstrap:Algebra. To get to the same point as in Bootstrap:Algebra, we’d next implement is-onscreen to check if Sam has left the board, and use it in next-state-tick.

Act out a reactor with key-events. You will need four students: one who acts as the next-state-key function, one who acts as the keyboard (you could also have the class act as a keyboard by having students shout out keys), one who acts as the reactor, and one who acts as the draw-state function. Give each student a few sheets of paper and something to write with.

When a key is "pressed" by the keyboard, the reactor write the current state and the key that was pressed, then shows their paper to next-state-key. next-state-key produces a new state based on the current state and the key, writes it down, and then hands the new state back to the reactor. The reactor discards their old state, replacing it with the new one, and shows the new one to draw-state. draw-state produces an image for the reactor to post, and draws it on paper. They hand the image to the reactor, who holds it up as the new frame in the animation. We recommend not having a next-state-tick function for this activity, to keep the focus on key events. You can add a on-tick handler in a separate stage when talking through games which have both time- and key-based events.

Optional: implement boundaries to keep character onscreen, using the same ideas as safe-left and safe-right from before. You can also write safe-top and safe-bottom, and use all of them to keep the character fully on the screen.

Optional: use num-to-string and text to display the position at the top of the window.

This activity introduces students to Reactor programs that use key-events and tick events. Students create a "digital pet", which responds to key commands but also changes state on its own.

Now, you’ve seen how to use functions to compute the next state in a game or animation for both tick and key events. We can combine these to make an interactive “digital-pet” from scratch!

Notice that not much is happening! To make this game more interesting, we want to add three behaviors to it:

In this lesson, you will extend the animation three times, once for each of these behaviors, by adding or changing the functions that make up an animation. To do this, you will use the Animation Extension Worksheet three times. Note that none of these should require adding any new fields to the data definition, just adding and editing functions like next-state-tick, next-state-key, and draw-state. We will walk you through the first use of the animation extension worksheet, then let you try the other two on your own.

For this extension, we want to decrease the hunger by 2 and the sleep by 1 each time the animation ticks to a new frame.

In this filled-in worksheet, the description from the problem is written down into the "goal" part of the worksheet. This is like the “purpose statement” for the feature.

Next, we consider the tables that summarize what now changes in the animation.

The worksheet identifies that both hunger and sleep are changing in new ways. Since they aren’t new fields, this feature is completely dependent on existing data, and we don’t need to add any new fields. We therefore leave the second table empty (since we aren’t adding new fields).

Next, we identify the components that we need to write or update. We don’t need to change the data definition at all, because no new fields were added. We may need to update draw-state function, since the size of the bars changes. We definitely need to write the next-state-tick function, which doesn’t yet exist. We do not need to address anything about keypresses with this feature, so next-state-key is untouched. Since next-state-tick has been added for this feature, we need to add a on-tick handler to the reactor.

Now that we’ve planned what work needs to be done (on paper), we can start thinking about the code. As always, we write examples before we write functions, so we are clear on what we are trying to do.

In our samples, we estimate a bit from looking at the pictures, but note that we pick numbers that would work with the desired behavior — MIDPET represents the state after 25 ticks, because hunger is 50 less (decreased by 2 each tick), and sleep is 25 less (decreased by 1 on each tick). The LOSEPET sample instance corresponds to the state when both hunger and sleep values are 0.

Now we need to use this information to edit the current code, checking off the boxes we identified as we go.

The draw-state function already does this, so we can check the draw-state changes off as being done (without doing additional work).

Once we’ve finished using the design recipe to implement next-state-tick, we can check off its box. Finally, we need to add the handler to the reactor so the reactor calls the function we just wrote on tick events.

You should have ended up with something like this:

Make sure you get a working animation with bars that decrease before moving on, like this:

🖼Show image

Next, we’ll add key events to the game so the player can increase them so they don’t reach zero!

As you fill in the worksheet, think about useful sketches that capture this new feature, whether you need new fields, and which functions are effected.

You now know everything you need to build interactive games that react to the keyboard, draw an image, and change over time! These are the fundamentals of building up an interactive program, and there are a lot of games, simulations, or activities you can build already. For example, you could build Pong, or the extended Ninja Cat, a more involved Pet Simulator, a game with levels, and much, much more.

Some of these ideas are more straightforward than others with what you know. The rest of the workbook and units are designed to show you different features that you can add to interactive programs. You can work through them all if you like, or come up with an idea for your own program, and try the ones that will help you build your very own program!

Student are introduced to the programming concept of refactoring, which closely models the Mathematical Practice 7: Identify and make use of structure. Students create an emoji generator, and then refactor it to make the code cleaner.

One of the most common tasks software developers find themselves performing is refactoring code. This means taking code that is already working and complete, and cleaning it up: adding comments, removing unnecessary expressions, and generally making their code more readable and useable by others. Refactoring does not change the behavior of the program, only the appearance of the code. For instance, a messy expression like:

could be refactored into:

Both expressions return the same value, but the second is much more readable. Refactoring can involve using existing functions (such as num-sqr in the example above) or writing new functions to perform small tasks.

Open the Robot Emoji file and press "Run". In this file, there are two versions of the same program written by different students.

Discuss with students the differences in documentation, formatting, and organization of the two versions of the emoji code.

Next, we’re going to practice refactoring an existing program that draws an image.

This code draws an image of a simple face emoji. Without changing the final image produced, can you see any opportunities to edit the code to make it more readable?

This activity can be done individually or as a class, with students giving suggestions for refactoring code projected at the front of the room. Once the refactoring is completed, students can practice using image functions to create an emoji of their own.

Students practice writing a simple function to draw the state of a Reactor, when that state consists of only a single number.

The majority of reactive programs you’ll write in this course will use data structures consisting of multiple pieces of data, whether that be Numbers, Strings, Images, or Booleans. However, it’s not required to have a full data structure in order to use a reactor. In fact, we can create an animation based on just a single number!

Notice how there is no data block in this file. Both the next-state-tick and the draw-state function consume a single number, and the initial value given to the reactor is also a single number (in this case, 1.)

According to the next-state-tick function, on every clock tick the state (a single number) will increase by one, which is exactly what happens. Since we didn’t tell the reactor how to draw the state (the to-draw part of the reactor is commented out), when the reactor runs we see the state of the reactor (a single number) increasing, instead of an animation.

Reinforce the fact that, although the draw-state and next-state-tick functions work together within a reactor to produce an animation, each function can work without the other. In this example, next-state-tick will update the state even without a function to draw the state.

There are much more interesting things we can display using a number as the state of the reactor, however!

Encourage students to brainstorm and share ideas for the draw-state function before beginning. Some possible options include:

This activity turns up the cognitive load: students practice writing a function to draw the state of a Reactor, when that state consists of a structure containing two numbers.

You’ve practiced writing a draw-state function using a single number as a state, now let’s look at something a bit more familiar.

This code includes a data structure (called AnimationState) containing two numbers as its fields, a and b. As before, the draw-state function is incomplete, and commented out from the reactor.

With only the next-state-tick function, we can see the state updating, increasing the first number by 1 and decreasing the second number by 1 each tick.

Some possible ideas for this activity:

Have students share back what they brainstormed before beginning, then share the completed draw-state functions they wrote, and the animations they created!

Students apply the Animation Design worksheet to their own, creative animations.

You’ve now learned the core tasks that go into building an animation:

In this lesson, we show you how to use our Animation Design Worksheet to keep track of these steps as you build your own animation.

As we saw in the previous unit, we can always go back and add more elements or details to an existing animation. So keep it simple to get a basic game running, then you can add more later.

Turn the Animation Design Worksheet on Page 41 in your workbook.

The tables below the animation sketches ask you to identify the elements in your game.

Have your partner or a classmate check your work — make sure you both agree that you’ve identified everything that is changing.

The table at the bottom of the worksheet asks you to make a to-do list of which functions and components you will need to write to build your animation.

Students should have ended up checking "sample instances", draw-state, and "reactor", plus one or both of next-state-tick and next-state-key. Sample instances get created anytime you have to create a data structure, and every animation or game has an underlying data structure.

Go to the top of the second page of the worksheet.

Is your data structure defined?

At this point, you could open a new Pyret file and type in your data structure and your sample instances. This would help you check whether your instances and data block are consistent with each other. If you don’t have access to the computer right now, you can come back and do this step later.

Sanity-checking each bit of code and examples as you go helps students catch errors early. So typing their work so far in now makes sense, if your class set up allows it.

Now you have to develop whichever functions you marked off on the todo-list on the bottom of page 1 of the worksheet.

There are extra design-recipe worksheets in the back of the workbook if you need them to help you remember the steps (domain and range, examples, function, and typing and testing your function).

You need to decide how much scaffolding and help your students need at this point. You can feel free to let them work on their own, or you can encourage them to work through design-recipe worksheets if they still need the structure that those provide. The main goal is to have students tackle only one function at a time, and to make sure it is working before they go on to the other functions.

Finally, we can build and run the animation by defining a reactor.

Remember that a reactor looks like:

where you replace the ??? with names and instances that correspond to your game.

Students implement the distance formula, to prepare for collision detection in their games.

So far, none of the animations we’ve created included any distance or collision-detection functions. However, if you want to make a game where the player has to hit a target, avoid an enemy, jump onto platforms, or reach a specific part of the screen, we’ll need to account for collisions. This is going to require a little math, but luckily it’s exactly the same as it was in Bootstrap:Algebra.

🖼Show image

image

Finding the distance in one dimesion is pretty easy: if the characters are on the same number line, we subtract the smaller coordinate from the larger one, and we have our distance.

Unfortunately, most distances aren’t only measured in one dimension. We’ll need some code to calculate the distance between two points in two dimensions.

🖼Show image

Let’s start with what we do know: if we treat the x- and y-intercepts of C as lines A and B, we have a right triangle.

Ancient civilizations had the same problem: they also struggled to find the distance between points in two dimensions. Let’s work through a way to think about this problem: what expression computes the length of the hypotenuse of a right triangle?

🖼Show image

For any right triangle, it is possible to draw a picture where the hypotenuse is used for all four sides of a square. In the diagram shown here, the white square is surrounded by four gray, identical right-triangles, each with sides A$\displaystyle A$ and B$\displaystyle B$. The square itself has four identical sides of length C$\displaystyle C$, which are the hypotenuses for the triangles. If the area of a square is expressed by side ∗ side, then the area of the white space is C^2$\displaystyle C^2$.

By moving the gray triangles, it is possible to create two rectangles that fit inside the original square. While the space taken up by the triangles has shifted, it hasn’t gotten any bigger or smaller. Likewise, the white space has been broken into two smaller squares, but in total it remains the same size. By using the side-lengths A$\displaystyle A$ and B$\displaystyle B$, one can calculate the area of the two squares.

image

The smaller square has an area of A^2$\displaystyle A^2$, and the larger square has an area of B^2$\displaystyle B^2$. Since these squares are just the original square broken up into two pieces, we know that the sum of these areas must be equal to the area of the original square:

A^2 + B^2 = C^2$\displaystyle A^2 + B^2 = C^2$

To get C by itself, we take the square-root of the sum of the areas:

√( A^2 + B^2 ) = C$\displaystyle \sqrt{A^2 + B^2} = C$

Pythagoras proved that you can get the square of the hypotenuse by adding the squares of the other two sides. In your games, you’re going to use the horizontal and vertical distance between two characters as the two sides of your triangle, and use the Pythagorean theorem to find the length of that third side.

Remind students that A$\displaystyle A$ and B$\displaystyle B$ are the horizontal and vertical lengths, which are calculated by line-length.

Now you’ve got code that tells you the distance between the points (4, 2) and (0, 5). But we want to have it work for any two points. It would be great if we had a function that would just take the x’s and y’s as input, and do the math for us.

You still need a function to check whether or not two things are colliding.

Students implement a simple Boolean-producing function, which composes with the distance function they implemented.

So what do we want to do with this distance?

At the top of Page 47 you’ll find the Word Problem for is-collision.

Now that you have a function which will check whether two things are colliding, you can use it in your game! For extra practice, You can also implement collision detection into this Pyret Ninja Cat game. This is the program we’ll be altering for this lesson, as an example. In Ninja Cat, when the cat collides with the dog, we want to put the dog offscreen so that he can come back to attack again.

We’ll need to make some more if branches for next-state-tick.

Remember that next-state-tick produces a GameState, so what function should come first in our result?

Collision detection must be part of the next-state-tick function because the game should be checking for a collision each time the GameState is updated, on every tick. Students may assume that draw-state should handle collision detection, but point out that the Range of draw-state is an Image, and their function must return a new GameState in order to set the locations of the characters after a collision.

Students add a score to their game.

The score is something that will be changing in the game, so you can be sure that it has to be added to the ____State data structure. In our example Ninja Cat program, we’ve called our structure GameState, which currently contains the x and y-coordinates for our player, danger, and target, plus the speed of the danger, and speed of the target. Your game(s) will likely have different structures.

Remember: Since your structure is changing, you now have to go through your game code — every time you call the constructor function for your structure (ours is game()), the score must be included. It may be helpful to add the score as the very first or last field of the structure, to make this easier.

The GameState structure for our Ninja Cat game now looks like this:

Now that the game has a score, that score needs to actually increase or decrease depending on what happens in the game. For our Ninja Cat game, we’ll say that the score should go up by 30 points when Ninja Cat collides with the ruby (target), and down by 20 points when she collides with the dog (danger).