Scratch

There are no easy ways to do arrays in scratch, but there are some really ugly hacks you can do to use the screen itself as an array.  See, for example, my Simon game:
http://scratch.mit.edu/projects/kevin_karplus/2158

Last edited by kevin_karplus (2007-05-19 00:47:44)

Hi, Kevin.

You are too modest! I would not call your Simon game a hack--it's incredibly elegant! You even hide the sequence in a random dot stream so the user can't cheat.

Actually, it might be nice to make a simplified version of the Simon game that doesn't hide the sequence so people can more easily see how it works. Kevin's technique is analogous to a Turning machine, a mathematical model of computation that uses a virtual "tape" with a fixed set of symbols (or colors!) as its memory. (Kevin, I know you already know about Turing machines but others may not have heard of them.) Given an infinite tape, a Turing machine can compute anything that a real computer can compute. Of course, Turning machines are not easy to program and not terribly efficient, but it's astonishing that such a simple machine is a complete general computer.

Scratch doesn't have an infinite tape, so it's not quite a Turing machine.

  -- John

Last edited by johnm (2007-05-19 09:48:45)

It would be pretty easy to take out the hash function and just have the dots for the array march across the bottom of the screen.  I don't know if I'll have time for that any time soon.  Maybe the next time I have insomnia.

I don't see this as a good Turing machine analogy----I think that perfect hashing is the right way to view the code.

The Simon game will run out of space for lengthening the sequence eventually---I've not had the patience (or skill) to play it that far.

I decided to try and simplify the Simon code to something more basic, and to remove the hash code:

http://scratch.mit.edu/projects/Roberth/5184

In the process of writing this little tidbit, I think I can understand some of the design decisions that Kevin put into his Simon game including the hash function, the odd color scheme, and the distorter that sprinkles random junk on the bottom of the screen.  This example is a much more pure array, and allows you to put in up to 160 elements in the array before you run out of room on the screen.  With a little bit of modest work, you could add additional "rows" to expand this array to an even larger number, but this is a good place to start if you want to experiment with arrays in Scratch.

I tried to use a single pixel instead of using a two pixel wide brush.  Perhaps this is an area of improvement to hack at this example, but I had resolution problems with trying to set and retrieve an individual pixel.  That was my original goal, but it seems to be futile.

One other huge limitation I've seen is the color tester block only allows you to use the eyedrop for selecting the color that is to be tested.  If instead there was some way to "retrieve" the color under the sprite directly (aka a special "pixel color" variable similar to the "timer" variable), you could completely remove all of the nested if statements.  A corresponding block with the pen already exists where you can "set pen color to <value>".  You just can't easily retrieve that color once it is set.

To help select some primary colors, I created a really ugly sprite with a bunch of broad vertical bands of color, and left that in this project.  That, to me, seems to be the only realistic way to select colors to be tested as trying to use the color selector directly is far too imprecise to get specific colors for such an exact requirement.

I also tried to see if I could "hide" the visual part of the array elements by moving another sprite over the stage area being modified, but unfortunately the colors of the second sprite are instead picked up by the array retrieval code.  The colors are recorded just fine underneath the second sprite, however.  You might be able to come up with some sort of method on the data fetch to quick "hide" the 2nd sprite and then "show" the sprite immediately after the data fetch, but this seems to me as something distracting.  And it gets back to the problems that Kevin faced with trying to hide the data from the user so they couldn't "read" the array, as flashing the array contents (even briefly) wouldn't really work to hide the data from an observant user.