View source for Richard Heppner's Scratch Journal Entry

First of all, I really enjoyed working with Scratch.  I am by no means a computer programmer and this took me back to the last time I tried to do anything like this which was when, as a kid, I wrote stuff in BASIC and even *gasp* LOGO.  Anyway, the simple syntax and straightforward graphical interface for Scratch made it not very difficult to jump right in and mess around.

I ended up making a bunch of different games, each of which focused on a different element/feature/command.  First, I made a really simple "Frogger"-type game which I never even uploaded.  I was really just gettting my feet wet, and it did not compare to [http://cyber.law.harvard.edu/cyberone/wiki/Image:Danger_Cat_Takes_on_the_World.zip Danger Cat Takes on the World] by [http://cyber.law.harvard.edu/cyberone/wiki/User:David David Ardia].  The next thing I did was make the game [http://cyber.law.harvard.edu/cyberone/wiki/Image:Perspective_Cat.scratch.zip Perspective Cat] where I tried to simulate perspective (by having sprites get smaller as they neared the horizon - though someone better with math could probably approximate the exponential shrinking better than I did); it also included really rudimentary collision detection, so that the sprites would "bounce off" of "walls."  That collision-detection turned out to be really difficult to figure out, and I still think it could be done better by someone who knows better what s/he is doing.  Then I made a game where I focused on the "size" command, called [http://cyber.law.harvard.edu/cyberone/wiki/Image:Puffer.scratch.zip Puffer], where the player is a puffer-fish that gets bigger when it eats smaller fish but pops if it tries to eat larger ones.  I actually thought it worked out really well, although if I were to improve on it now, I would try to scale the difficulty in some manner (well, more than it is naturally scaled by the fact that your character keeps getting larger and is harder to maneuver), maybe by adding a speed-variable or special enemy-fish sprites that showed up as your size got larger.  Finally, I wrote the game called [http://cyber.law.harvard.edu/cyberone/wiki/Image:Space_Rotor.scratch.zip Space Rotor] which probably resembles some forgotten video-game from my past.  The gist is that your character (a space ship) does not move from left to right or up and down but rather clockwise and counter clockwise in a fixed circle, and the idea is to avoid/shoot/catch various other sprites that come flying out from the center of the circle.  I was pretty proud of it because I had to solve the tricky problem of making the player-sprite face the center but move in a circular motion (again, it probably could be solved more elegantly by someone with better math skills).

Overall, I really enjoyed Scratch, though I found myself wishing it were a bit more powerful.  For instance, though I doubt I would have made good use of them, higher mathematical functions (trig functions and exponents) would probably make some of the things I tried to implement easier.  Also, I wish there were an equivalent of the GOTO and GOSUB commands from BASIC - they would have helped me a lot with organizing the programs.  Finally, I wish there were a better way to do collision (both simply stopping the player from moving through obstacles and a simple way to do ricochet-type reactions).

I am still messing around with Scratch, trying to create a puzzle-game where the goal is to create a "network" and where the player does better the less centralized it is.  So far, I can randomly place "nodes" and allow the player to connect them (using the "pen" command).  But, I can't figure out how to get a sprite to move automatically through the network, which is what I would like to do.  (Anybody who wants to help out or work on it together, let me know!)

I'm not entirely sure that I buy the "code as law" analogy.  Obviously, the code does direct, restrict and control the actions of the sprites and the program overall.  But, that strikes me as quite different from law as we understand it in law school.  If law were actually only if-then rules, with no opportunity for interpretation and differentiation, then it wold look a lot more like this code, but of course, it's not.  Perhaps, though, the point is that at a sufficient level of complexity (well beyond the code avaialble for us to work with in Scratch) and with a sufficient level of open-ness (in, say, something like a Wiki), the underlying code can direct people's actions (a different phenomenon from directing the computer's actions), at least in general ways.