Why does Scratch have sprite dropdowns?

Computer Science
1

In Scratch 0.1, sprites could essentially "run each other's scripts" - so Sprite1 could run "Sprite2, twirl around", and Sprite2 would do exactly that. This was eventually removed and replaced with the idea of broadcasts for the express purpose of modularity. You could not take a sprite from one project and put it in another, because its scripts would depend on the existence of another sprite's scripts; while with broadcasts, you can (at least if you both agreed on broadcast names beforehand; it's better than agreeing on sprite names!).

What puzzles me, then, are the existence of blocks like OF and TOUCHING?, blocks that include dropdowns where you can choose other sprites by name. A sprite that checks if another sprite is touching it cannot work as-is in a completely different project, because the other sprite just doesn't exist there! To me, this runs counter to the design principle that justified the creation of broadcasts in the first place.

2

yes, I agree, and at the time argued against this design decision (when I was still working on and contributing to Scratch), as it defeats modularity and because accessing another object's local variables breaks the idea of encapsulation. John and Mitch agreed in principle, but the consensus among the Scratch team was that reading another sprite's variables was an okay compromise for all the benefits kids would get out of it.

3

Jens you worked at scratch?

4

yep, for a short time, about a year or so, I was a part-time Scratch dev in 2008/2009.

5

Nice, so you already had some experience making blocks before BYOB.

6

You made me spend half an hour reading that paper! ;~( It's very interesting.

I hadn't realized it was that late! By 2008 you were already working on BYOB.

So, how would you do those things? I guess there could be a TOUCHING block that would report a list of sprites I'm touching. Then you could send messages to those sprites.

One of our perennial fights is that Jens thinks OF is the right way to query another object. but I'm more a fan of ASK. Either way, though, there has to be a way to say which sprite you're asking. I guess there could be an ASK EVERYBODY block that would report a dictionary with sprites as the keys and reported values as the values. That would be a way to broadcast an expression. If some other sprite didn't know how to respond to that expression, because of a missing local reporter, it just wouldn't be in the dictionary. You could then traverse the dictionary with FOR EACH ITEM, or select subsets with KEEP.

But that seems really roundabout if what you want is a response from one particular sprite. Guaranteeing that every sprite's code can be extracted from its containing project seems like too much trouble and complexity. I'm fine with those users who want to export sprites taking the responsibility to make sure their code is portable. Or alternatively, maybe this is another use case for transitive closures.

7

I was active in Scratch since a year before, but Mitch hired me right at the first Scratch conference where I also met you for the first time. BYOB was my first project as an official Scratch dev, because Mitch wanted me to think about how we could visualize passing arguments to custom blocks. So I designed what I then called "header blocks" that had variable templates inside them which you could drag out. And that, basically was BYOB. At first it was just a mockup, because Scratch's evaluator couldn't do recursion because Scratch's variable scope was confined to 2 levels of globals, and there wasn't any notion of variable frames, so each variable block was statically bound to an individual value. Once I had the "header block" mockup I wanted to actually play with it and draw a dragon curve, so I had to work around those variable limitations in Scratch, and that was by far the hardest part. Of course, once that was done, BYOB just ... worked, and I must've spent several weeks drawing fractals afterwards, haha!.

When I sent my BYOB prototype to John and Mitch I never heard back from Mitch for ... months, even. Not a single word of feedback about it. John loved it, so did Andrès. So when one of your students, Brian, send us an email offering his help in implementing "procedures", John pointed him and you to BYOB. But even then I didn't hear anything from anybody for a long time anymore, and I embarked on a new side project - which was Smalltalk elements -. Next thing I got was an email from Dan in I think early summer of 2009 inquiring whether it would be okay if UCB used BYOB for a new course. And Dan also said they'd need me to update my BYOB version with the new things we'd added to Scratch in the meantime, mainly text functions. And then, in the fall of 2009 this other person from UCB began sending me emails about yet another thing they needed for their course which I'd never heard of before. Some cult of a Greek letter :smiley: ...

8

Wow. I didn't know BYOB started as a Scratch-funded project! My impression was that you'd worked for them in the distant past and you started BYOB just because of me complaining at that Scratch conference. Given that history, I'm surprised it took so long for them to get around to custom blocks in official Scratch. And surprised that when they did get around to it, I had to talk them into blocks with inputs. ("How does this differ from broadcast and wait?" Coming back full circle to that thesis, even though I didn't know about it then.)

9

History of Snap in 3 paragraphs. Nice.

10

Definitely. I normally don't have the attention span to read through an 80-page paper (that's YouTube for ya), and even I read through it.

For Snap!, something like that would be a good solution. I like how Snap! extends the broadcasting mechanism, although I still feel uncomfortable about using it due to the lack of message arguments and its thread-restarting/dropping nature.

Scratch, however, is a different story. Sprite references are difficult to deal with, especially without the anonymous lists and higher-order functions implemented by Snap!, and adding those would be yet more features to contend with.

The thesis actually points out the issue with "of" and "touching?", and provides two blocks as a potential solution:

  • A "touching-something-that-listens-for-broadcast" block. The example given is space invaders, where an 'alien' sprite could check for something that listens to 'yellow flag' events rather than specifically for the 'bullet' sprite.
  • A "whisper" block that sends a message only to the nearest sprite that listens for it. The example given for this a jewel collecting game with multiple players; a 'jewel' sprite could check if it's touching something that listens for a 'collect jewel' message, send that message to the nearest sprite that does, and then disappear.

I think both of these blocks have unintuitive behaviour. "Touching-something-that-listens-for-broadcast" is too verbose to explain in a block label. It would be difficult to discover what the "whisper" block actually does unless its block label was similarly verbose, and it would still be unusual.

I don't have much experience with helping kids to learn about programming concepts, but my solution would be a simplified version of the "whisper" block that simply sends messages to all the sprites that are touching the current sprite.

  • In the space invaders game, the 'bullet' sprite could whisper a 'hit' message. If any 'enemy' sprite hears it, it could disappear. For non-piercing bullets, the 'enemy' could whisper a 'hit received' message back, allowing the 'bullet' sprite to respond by disappearing unless a "piercing bullet!" superpower is activated.
  • In the jewel collecting game, the 'player' sprites could whisper 'collect' messages. If a 'jewel' sprite hears it, the 'jewel' can whisper back a 'collected jewel' message before disappearing.

Admittedly, this is less elegant for a few reasons. Reply messages are required for 'bullet's and 'player's to know that something happened. Also, you can't control exactly how many sprites receive the message; a 'jewel' could be collected by several players, or one 'player' can collect several jewels at once and only receive the score for a single one.

Yet, the simplified "whisper" mechanic is far simpler and easier to discover. "Send a message to touching sprites" is the simplest form of local communication between sprites I can think of. The mechanic offers a lot of extra flexibility; for example, you could create a project with interlocking 'gears'. When they receive a 'turn left' message, they turn left and then whisper a 'turn right' message to their neighbouring gears, and vice versa. It only takes 6 blocks to set up that interaction!

11

In the gear thing, don't you have to do extra work to avoid sending TURN RIGHT to the block that sent youo TURN LEFT? Otherwise you get loops.

This all sounds way complicated. Remeber, they went with BROADCAST rather than procedures to simplify things. Once all these bells and whistles are taken into account, I think procedures turn out simpler!

12

I just joined, and I found Snap! from a Wordle Solver I found on GitHub. I'm mainly a Scratch user, and when I first discovered this website, I've seen, a lot of similarities to Scratch. There's Gobo, the pen extension, the same variable counter like in Scratch, and even the big, green goblin that everyone loves! I know this is super off-topic to the actual post, but, what is the story behind Snap! and it's relation with Scratch?

13

I'm interested in what this is, can you send a link?

14

Hi, welcome to Snap!.

Your question is answered in the FAQ:

15

Thanks a lot!

16

Of course!

Link: Snap! Build Your Own Blocks

17

I think this can be avoided by making the broadcasts atomic and the gears keeping track of whether they've already been turned during the current frame. The alternative is a sort of "remote sprite procedure call" which could work, but IMO boils down to the same thing.

Maybe the dream of having granular sprite interactions and appealing to intuition is just too good to be true?

18

Thats not gobo,

also @bh why did u message me and then delete it immediately?

19

I goofed; I then undeleted it.

20

I'm afraid I don't understand this. So, either maybe wait for Jens to answer or else rephrase this for my simple mind.