ICS 10 • David G. Kay • UC Irvine • Summer 2013

Eighth Homework

This assignment is due by 5:00 on Friday, July 26.

As usual, you'll do parts of this assignment with a partner, but this time you may work with someone you've worked with before. The main part of this assignment is open-ended; you might want to pick a partner who has the same level of interest and commitment as you do; see more partner-choosing advice below. This week, again we need you to send a message to ics10@uci.edu with the names and UCInet IDs of both partners.

Part (a)

Read Chapter 2 of Blown to Bits, which talks about privacy. Pay particular attention to these points:

• examples of data collected for one purpose being used for an entirely different purpose
• examples of incorrect inferences being made from data found on line
• the "Fair Information Practices" section.

Part (b)

For this final assignment, we invite you to create your own Snap/BYOB project. It could be a game; it could be a tutorial; it could be a simulation. Use your imagination and creativity to build something that's entertaining, enlightening, surprising or useful. If you're having trouble coming up with a good idea, think of a concept from your major to demonstrate, a story to tell, a genre of game you enjoy.

You'll want to know how much effort and complexity we expect. That's hard to quantify, and of course on the high end the sky's the limit. But on the lower end, (a) your project should not be less involved or less capable than the previous projects this quarter, (b) it should be clear to the user who launches your project what to do—give the rules of the game or a brief explanation of what the project does, (c) try to use loops, if statements, user-built blocks, lists, and messages where appropriate—don't include them just to have them, but try to demonstrate your facility with some of the language tools, and (d) the weight in the course of this assignment is the same as the weight of every other assignment, so we don't expect you to treat this as a term project (though of course you're welcome to go wild).

You should pick a partner (a) who wants to spend about the same amount of time as you want to spend, and (b) with whom you can agree on the general subject of your project, so this isn't a great week to wait 'til the end of Thursday's class and shout, "Who needs a partner?"

Here's some software development advice (which actually is valuable for designing any kind of complex system):

• Decide in advance what you want your project to do. Make sketches or storyboards or outlines or whatever lets you plan its actions conveninently. Think first about the ideas you want to get across; don't start by thinking in terms of Scratch language features. Don't expect to be able to compose your project free-form on the fly in Scratch, without having planned it out first.
• You might also think about a "lite" version of your project, just in case your full version turns out to be too elaborate to complete in time. You'll get more credit for turning in a project that does something sensible and interesting, even if it's not everything you envisioned, than for turning in a project that's ambitious but that doesn't work correctly (or at all).
• Divide the whole task into parts. Now's the time to start thinking in terms of Scratch: What sprites do you need? What does each sprite do? (How does it react to being clicked, hitting the edge, receiving a message, getting the green flag? Does it need to change appearance using different costumes?) Do you need the stage to do something special? What variables or lists do you need?
• Work in small increments. Take it one sprite at a time, and one behavior at a time for each sprite. After you complete each block, save a copy of your work so far. If you end up getting in too deep and losing track of what you're doing, you'll want to be able to "roll back" to the last stable version.
• Don't get carried away too soon with the graphic beauty of your sprites and backgrounds. Graphic beauty is great, but it's not our focus, and you could spend all your time perfecting the look of things and run out of time to make them actually do anything. We'll give much more credit for action than for beauty.

Save your project, naming it in the usual form: hw8-dkay-clustig. Submit the project via Checkmate. Just one partner should submit one copy; the file name and your Email message will let us give both partners credit.