We have seen various uses of Scratch (story telling, drawing block letters, & games with score keeping) and a variety of Scratch blocks and features. Familiar topics are broadcasts (especially for "Places Everyone" & "Action"), movement for drawing, repetition, and creating our own blocks/new instructions. Hopefully, your are becoming comfortable with variables. This learning activity will provide additional experience with variables and collections of variables. As usual it should allow for creativity and problem solving, and be interesting for kids.
This assignment builds on the expectations in the previous tasks and adds some new ones. The task is to do something that involves user input and lists (collection of similar variables). The recommended activity is a trivia (quiz) program but you could choose to do a mad lib program. As you can imagine the complexity of a such a program can vary a lot. For this assignment a modest amount of complexity is expected—you are being asked to create a relatively simple program that uses one or more lists of data and user input to respond to questions (or enter items for the mad lib).
The program you plan and implement should: 1) use one or more lists in an appropriate manner; 2) make use of use input (via
ask blocks); and incorporate as many of the items below as is reasonable. I encourage to try to impress me (better yet, impress yourselves).
Additional information about the programs is included below the "process reminders".
Keep the "pair programming" process in mind as you work. One person types and the other person watches and corrects, questions, etc. After a bit (at most 30 minutes) you change roles.
This activity is for you to learn, so it is not graded. The learning will be inferred in the PARR (Programming Activity and Reflection Report) document you (eventually) submit and in one of the in-term exams. Remember to add to your notes for the PARR.
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, seek answers on google, etc. but, do not spend more than 15-30 minutes trying to overcome a particular error or problem.
The syllabus noted a couple ways you might earn extra credit. One is to share some aspect(s) of programming or Snap! you think others might not have experienced. You should annotate your program using the program notes (File icon | Program notes) and/or comments blocks (see p.68 of the Snap! Reference Manual. The annotation should describe or explain the learning/insight(s) you want to share. The partnership could also suggest additions to our how to do it page. You might suggest a revision to clarify (or finish) something that is there already or an entirely new topic. Please indicate how/why you think the would be helpful. Be sure you fully and clearly describe what you are talking about.
Submitting something for either kind of extra credit is as simple as sending an e-mail message. The message should:
Mad libs use specific words that fit into categories. The categories can be quite general (e.g., nouns, pronouns, adjectives, adverbs, counts) or fairly specific (e.g., male names, female names, sports, actions, speed of movement, etc.). Often the user of a mad lib program will supply the words. The goal of this program is not to create one mad lib but to have the capability of multiple mad libs using the same word possibilities. You might also consider having multiple scripts that the mad lib words fit into. Songs, nursery rhymes, poems, etc. can be sources for mad libs. A host of possibilities are available on the web at http://www.eduplace.com/tales. (Were I teaching kids, I would have them make up the script and decide where the blanks went—categories of words needed).
There are multiple ways to use the list capability of Snap! when doing mad libs. Two possibilities are given and discussed below.
Perhaps the most straightforward use of lists in mad libs is to have one list for each category of words used. The lists could be initialized by the program(mer) or the program could ask the user for items. A mixture of the two might be used where the primary words nouns and very were chosen by programmer and the descriptive words (adjectives and adverbs) were entered by the user.
Regardless of how the word lists are chosen, you could also put the phrases into lists. For example:
_____ had a little _____ Its _____ was _____ as _____ And everywhere that _____ went, the _____ was sure to go.
The structure here is 7 pairs of phrase and word. The first pair has an empty phrase and the last pair has an empty word. The lists could have empty slots (shown as ?). Also, we probably would want to allow for punctuation at the end of a phrase & word combination. Thus, we might have the following structure.
PHRASE WORD Punctuation ? _____ ? had a little _____ . Its _____ ? was _____ ? as _____ ? And everywhere that _____ ? went, the _____ ? was sure to go ? .
Of course the alternative script would need to have the identical structure—7 pairs or phrases and words. It might also need to be chosen or created with the possible word choices in mind.
Trivia or quiz programs can take multiple forms and have data that depends on the form. Several examples of ways to interact with users are discussed below.
One example is a state capitals quiz. It would likely need one list for states and a parallel list for capitals. You could question by displaying a state and asking for it capital or by displaying a capital and asking for its state. The lists are parallel in the sense that the items in the 1st positions match as do the items in the last position and any other pair of items in the same positions in each list.
Multiple choice questions also use parallel lists but will need multiple lists—one for the question, one for each of the choices (or a single list for the choices which is more involved), and one for the answers. One sprite might indicate the possible answers and another "ask" the question. The user would type A or B or C or D. This reduces the problem of typing errors. Alternatively, the user could click on a sprite that indicated the choice. The sprite could have costumes that were the letters (A,B,C,D) and each sprite would "say" what its choice was. Or the costumes could indicate the choice, e.g, one student developed a Disney trivia program and used images of Disney characters as the answers.
A third alternative is to have users click an area to indicate their response. For example if you had a map of the US as a background you could ask students to click on particular states. You might determine which answer was chosen by using X- and Y-coordinates of the clicks and doing some sort of test of them to see which state they were in (perhaps using minX, maxX, minY, maxY). Alternatively, you might have to put some sort of sprite in each state so you could tell which state was being clicked on. In this case the parallel lists might be states and coordinates or states and sprites. A similar idea might be to identify the counties in Iowa.
Scratch lists and Snap! lists are a bit different from each other. Thus, far I have not been able to import data directly into a Snap! list (which was relatively straightforward in Scratch). I did manage to do it, however, using the following process which uses states and capitals as an example. Before working in Snap! you must prepare the list data. I used a spreadsheet to produce two
.csv (comma separated values) files with one row per state or capital.
capitalsvariables into empty lists (as shown below)
capitalsInvariables are displayed on the stage
statesInvariable that is on the stage and select the import… option. Then select the
.csvfile of states your created. All the states should appear in the variable.
capitalsInvariable and the
.csvfile of capitals
capitalsInand place them in the lists. The code to do that is shown below.
And magic happens. It's amazing! You will probably want to stretch out the lists to see more of the values. Just click and drag on diagonal lines in the bottom right corner of the list block (on the stage).
If you choose to do a trivia program, it is likely you will want to import data into lists as described above. And, if you choose to do mad libs you might also want to import data into lists. For example, you might do Hey diddle diddle ... Almost the entire thing could be mad libbed. The script might look like,
Hey, rhyme_1X rhyme_1X The animalN and the instrumentX The animalM jumped over the rhyme_2H The typeY animalZ actionB to see such a sight And the utensilG ran away with the utensilH
Relatively careful planning of data is needed for such a mad lib but it is doable. Choosing the values randomly (except that some have to match) can make for many versions of the tale. (See the discussion below for choosing values.)
Randomly picking which trivia question to ask is relatively straightforward. Each list will have a length reporter block (). It can be used with the random reporter block to generate a random location in the list, e.g., . That location can then be used to pick an item out of the list. However, you may need to know that value after using it, e.g., know which answer matches the question. So it is best to save the value into a variable and use the value from the variable instead of using the random reporter directly. If you chose state 12, you would need to know capital 12. The pick random block chooses a new random each time it appears. Similarly in the Hey diddle diddle rhyme mentioned above you'd want to use some items twice and you want to make sure you picked words that matched (rhymed) with other picks.