I'm looking for more information about broadcasting -- exactly what it is, what situations to use it for, and how to use it. I've searched for hours, and looked at the scripts of some projects that use it, but I still don't quite get it. I understand that there's no user guide for Scratch, which is a shame. Can anyone point me in the right direction for finding out more about this feature? Or to a comprehensive user guide, and not just lists of topics posted on a forum?
On a related note, I'd like to teach scratch to kids (I'm a parent and I'm active in my son's school). I wondered if there were any materials for educators to help put together a curriculum.
Thanks.
Offline
Try the http://scratch.mit.edu/howto materials, including the short reference guide.
The basic notion of a broadcast is simple---a message is sent out and any number of scripts can be started with a "when I receive <message>"
I think that there ought to be a wait for <message> block as well, but there isn't.
Offline
kevin_karplus wrote:
The basic notion of a broadcast is simple---a message is sent out and any number of scripts can be started with a "when I receive <message>"
I think that there ought to be a wait for <message> block as well, but there isn't.
I'm afraid I don't understand what the difference would be between your proposal and the existing command. Would you give an example?
Offline
A "wait for message" block would come after other blocks. That is, flow from it requires two things: reaching the block, then receiving the message. The current "when I receive" blocks are always active.
A wait-for-message block would be useful in synchronizing the actions of different sprites (or different scripts in the same sprite) while retaining state information. For example, one could have a long script
...initialization stuff...
wait for next level
.... set up level 1 stuff...
wait for next level
... set up level 2 stuff ....
wait for next level
....
Offline
You could make it so that the script works like this:
Script 1
when flag clicked
beginning stuff
forever
if level = 1
level 1 stuff
change blah by .5 (so it won't keep happening)
if level = 2...
close forever
Script 2
when I receive blah
change level by .5
EDIT: Better way!
When I receive blah
change level by 1
if level = 1
do stuff
if level = 2
do stuff
...
Last edited by Bloing_Gloing (2007-05-30 17:43:44)
Offline
You have put in forever loops to handle straight-line code.
This is both ugly and inefficient.
There are often workarounds for missing features---the goal is to have simple, useful constructs that make code easier to read and write.
Offline
At least it works, though. I admit it's not very good. Oooh! I just thought of a way!
Offline
You could use a "wait until variable=x" command in place of a "wait until I recieve broadcast x" command, but that requires setting up a variable - which is slightly more complex than just sticking in a "wait until I recieve broadcast" block.
Offline
I hope to put this simply z-man99
use a broadcast to initiate two or more sprites or code blocks into action for example a sprite1 and a sprite2
for example:
in the background code area you might have the command:
broadcast [startnow]
in sprite1 code block you have:
when I receive [startnow]
{dancing sprite code}
in sprite2 code block you have:
When I receive [startnow]
{dancing sprite code}
when you click start the broadcast in the background code block will initiate sprites1 and sprite2 operating both dancing codes at the same time.
generally what this allows you to do is initiate other sprites and codeblocks without having to use variables to track values for intiation. However in a complex program you might want to keep a close eye on the broadcasts as well.
It just makes things a little more visible when conveying operational actions for example when presenting how a piece of coding actions might be working to a bunch of youngsters, rather then sending them to sleep with numbers.
Offline