We have seen some "programming" (via the
code.org course), discussed what programming is, and created a story telling program and an initials-drawing program in Snap!. There are still things you (or your students) can do with Snap!—more involved animation, trivia/quizzing, etc. Another is gaming. As you can imagine the complexity of the a game program can vary a lot. For this assignment a modest amount of complexity is expected—you are being asked to create a relatively simple game that uses variables (perhaps for score, level, games played, etc. You will also probably want to make use of cloning which will also probably make use of random values.
The first step in this assignment is to decide on your game. Some ideas you might draw from are:
I suspect you can think of a other possibilities if these don't catch your fancy.
The program you plan and implement should: 1) use one or more variables in an appropriate manner; 2) make use of cloning; and incorporate as many of the items below as is reasonable. I encourage to try to impress me (better yet, impress yourselves).
Variables allow us to save and access data values while a program is running. Using them typically requires at least two actions: 1) initializing them and 2) updating or changing their values. In this program you will be using a variable to count something, e.g., "score" or "attempts". Computer programs count by adding 1 to a variable. Thus the variable must have a value assigned to it before you can add to its current value. The code for updating the value is simple but deciding who (which actor) will update the value and when is a little more involved.
I recommend you have the stage handle both tasks. If you are using the "places everyone" technique you merely place a
set [score▼] to (0) block in the when-green-flag-clicked script (I would put it before the broadcast blocks). Changing the score is more complicated.
I suggest that when any actor (sprite) recognizes the need to change the score that it (the actor/sprite) broadcast a message such as "add point". The stage would need a
when I receive [add point▼] block under which would be a
change [score▼] by (1) block. That should do it.
As you might expect cloning creates a copy of a sprite. There are two main things to worry about: 1) when to clone and 2) what the clone should do, particularly when it should go away. Ofen in a game scenario, the clone is something that (may move about but) will occasionally have a copy of itself move from its current location in some path (often just dropping from near the top of the screen). The copy/clone then moves in the indicated direction until it touches something—another sprite or an edge— or until its y- or x-coordinate reaches some extreme value. Then the copy/clone will disappear (via a
delete this clone block).
Creating a clone is relatively simple. Assuming you are using the "places everyone" technique, you use code such as
when I receive [action▼] forever | wait (pick random (3) to (10)) | create a clone of [myself▼] |_______________________________________
This script is added to those of the sprite you wish to clone itself. Using the forever block means that you need some sprite to recognize when the program should stop and include a
stop [all▼] block in one of its scripts. (An alternative is described in the the how-to guide.)
You also need to determine how the clone is to behave—what actions it should carry out. The outline of a script shown below is one way to do this.
when I start as a clone repeat until < (y position) < (-170) > | if < touching [??▼] ? > | | broadcast [add point▼] | | delete this clone | |___________________________ | change y by (-10) |_______________________________________ delete this clone
The above code will be a script in the scripts of the sprite that is being cloned. The two question marks would be replaced by whichever sprite you wanted to check for touching the clone. Note there are two conditions under which the clone will be deleted—when it touches the indicated sprite or when it gets to the bottom of the screen. This allows us to know the clone will be deleted rather than hanging around when it gets to the bottom of the screen. Also, deleting the clone automatically stops its script. Note that there are several places you can place code for additional actions, i.e.,
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: