Your familiarity with Scratch and with programming should be allowing you to feel more comfortable as you program. This programming activity should expand your experience and provide an example of an activity your students would enjoy—drawing their initials. We expect that most elementary students in third grade or above should should be able to do something like this activity. This document has two parts—the specifications for the assignment and information that should help you better understand how do to the assignment.
The first step in this assignment is to consider what you want you initials to look like: How big? Where placed? What color? Some additional planning considerations are provided below.
The program you plan and implement should meet the expectations below.
When you are finished with your program you will want to share it with the class by placing it in our studio. That process involves:
I think the following approach works
It should show our class studio (PEEE_fall17) as a link and a checkmark (also as a link)
It should turn green.
You should be able to see that your project has been added to the studio.
That should be all it takes to "submit" the program. Whichever partner submitted the program should have the other partner sign in to Scratch and double check that the project is available in the studio. Don't forget that both partners are to complete the PAC commenting together.
Note that you should always be able to get back to the project page or to the Scratch programming environment from which you can access the project page. If you joined Scratch, your projects should all be available and be saved regularly by the system.
I will be checking the programs to see if they meet the specifications (noted above). A program that minimally meets all the specs is at least "okay" (will get a C or better). Better programs will go beyond the the minimal specs, e.g., use variables/parameters and operators to calculate distances, use curves rather than straight lines for letters (e.g., B, O, etc.), use additional parameters with new blocks, use multiple sprites, use varying pen sizes and colors, have commented & "cleaned up" code, appear well planned rather than the result of guess and check coding, use additional Scratch features in reasonable/appropriate ways, etc.
There are at least two ways to approach this kind of drawing: 1) relative—control movement via point in direction __ and move __ steps blocks (the first script image to the right) and 2) absolute or using coordinates— use go to :__ y:__ and/or the glide __secs to x:__ y:__ blocks for movement and drawing (the second script image). Both scripts illustrate having made use of building of one's own blocks. Both also illustrate controlling the timing of movement so some are instantaneous and others not.
Things happen based on headings and distances. You (the sprite) might initially go to a particular location but the actions thereafter first point in a particular direction and move a particular distance. Drawing a vertical line and moving back to its top could involve something like:
This approach works well for letters the have mostly horizontal and vertical line (perhaps with half circles). The first script at the right will draw a J.
Things happen based on the coordinate system. You (the sprite) goes to a particular location then goes to a different location, then a different location, etc. The pen would need to be raised and lowered depending on whether drawing while moving was desired. (the second script)
The scripts also illustrate other concepts. (For the record, the J block definition does not come from the same program as the green-flag block. Green-flag assumes a J block with upper left starting position but the uses a top-center starting position.)
Two programmer-defined blocks shown have parameters. In this case the parameters indicate how tall the letter should be (
height) and a starting position for drawing the letter (two values indicate the starting coordinate). When the blocks code is called (see the next-to-last script) numbers or formulas can be placed in the instruction (block) that calls the newly defined instruction (block). The parameters in the definition are like variables that can be used inside the defining script. The value used by the calling block is placed in the parameter for use when carrying out the instructions inside the newly defined block.
This is hard to describe. Please ask questions if you have any trouble following what is being said.
Recall that sprites move nearly instantaneously. However, drawing curves or circles requires substantial repetition which slows things down. A nice program does not have slow parts and fast parts; rather the sprite moves around at a relatively constant speed (for the drawing parts at least). Try to control the timing so the sprite's movement is relatively consistent for all parts of the drawing.
One way to control timing is to use the
glide __ secs to x: ___ y: ___ block (see second script). Another is to divide the distance into increments and repeatedly move. When you know how far you need to travel this is relatively simple, just divide the distance by some number (e.g., 10) and repeat moving (and perhaps waiting for a bit) that same number of times (e.g., 10). There is a formula for calculating distances on the coordinate plane.
You can attach a comment to any block. This is useful for identifying which part of the code does which activity or for explaining some tricky bit of code or calculation. To add a comment, right click on the block and choose "add comment".
Note that the bottom script contains code to draw a half-circle. Through empirical research (act & observe or guess & check) I determined a formula that draws a half-circle of given diameter.
If you have questions about the assignment send me an e-mail or drop by my office. If you have a question while working on the assignment do the same. Keep in mind that when you encounter something you can't figure out you can/should think, explore, guess and check, etc. but, do not spend more than 15-30 minutes trying to overcome a particular error or problem.
Also, using pair programming helps to reduce the amount of time spent banging one's head on the wall. Remember, one person types and the other person watches and corrects, questions, etc. After a bit (at most 30 minutes) you change roles.