In our last lesson, we learned how to create our own custom blocks in Scratch, called “My Blocks.” Now, let’s dive deeper and see how these custom blocks compare to using “Broadcast” blocks. Both are useful for organizing code, but they work a bit differently. We’ll also share some cool tips for using “My Blocks” effectively, like the “run without screen refresh” option.
Imagine you have a long list of instructions for your Scratch project. Creating a custom block helps you keep all those steps together, making it easier to find and change them later. If you’ve used a broadcast block before, you know it lets you run code outside the main program. When a sprite or backdrop gets a broadcast message, it follows the instructions under the “when I receive” block.
So, what’s the difference between custom blocks and broadcasts? One big difference is how they handle the code. When you use a custom block, the program stops and runs all the steps in that block before moving on. For example, if your custom block plays a sound, the program will wait until the sound finishes before doing anything else. This means if you put a “forever” block under it, the program might get stuck there.
On the other hand, broadcasts send a message and then keep going with the next steps. This allows different parts of your code to run at the same time. For instance, if you use a broadcast, you might see a sprite spinning while a sound plays because the program doesn’t wait for one to finish before starting the other.
When deciding which to use, think about whether you want each step to finish before moving on or if you want things to happen at the same time. Also, remember that custom blocks are only available to the sprite you created them on. If you want to use the same block with another sprite, you’ll need to copy it. Broadcasts, however, can send messages to all sprites and backdrops.
You might have noticed the “Run without screen refresh” option in Scratch. Normally, Scratch redraws the screen many times per second, so you see smooth motion. If your code runs too fast, you might only see the final result. Sometimes, you want to see each step, like when building a wall of bricks. If you don’t check “Run without screen refresh,” you can watch each brick being placed. But if you do check it, all the bricks appear at once because the program runs the code as fast as possible in one go.
This is similar to Scratch’s turbo mode, but turbo mode affects the whole program, while “Run without screen refresh” only affects your custom block. Be careful, though! If your custom block has timing blocks, don’t use “Run without screen refresh,” or it might cause problems like lag or crashes.
In our next lesson, we’ll learn how to make even more advanced custom blocks using inputs. Stay tuned!
Try creating a custom block in Scratch! Think of a simple task, like making a sprite dance. Break down the steps and group them into a custom block. This will help you understand how custom blocks can organize your code.
Experiment with broadcast blocks by sending a message to another sprite. Create a scenario where one sprite sends a message to another, and the second sprite performs an action when it receives the message. This will show you how broadcasts can make different parts of your project work together.
Set up a simple project using both a custom block and a broadcast. Observe how each method affects the flow of your program. Write down your observations about when the program pauses and when it continues, and discuss which method you prefer and why.
Create a custom block that builds a simple structure, like a wall of bricks. Try running it with and without the “Run without screen refresh” option checked. Notice the difference in how the bricks appear and discuss why this might be useful in different situations.
Design a small project where multiple sprites interact using broadcasts. For example, one sprite could start a dance party by broadcasting a message, and other sprites could respond by dancing. This will help you see how broadcasts can coordinate actions across different sprites.
Here’s a sanitized version of the provided YouTube transcript:
—
In a previous video, we explored the concept of procedures and created our own custom “My Block.” Now, let’s examine the difference between creating a “My Block” custom block and using a “Broadcast” block. Both can store sequences of code as separate procedures, but one may be more suitable in certain contexts than the other. We’ll also share some additional tips and tricks for using “My Blocks” effectively, including the option to “run without screen refresh.”
If you have a long, complex sequence that performs a specific action, defining it as a custom block can help you easily identify all the steps involved and edit it later. If you’ve used a broadcast block before, you’ve practiced writing a procedure outside the main program. When a sprite or backdrop receives a broadcast, it can execute a series of code defined under the “when I receive” hat block.
So, what’s the difference between using a broadcast and writing your own custom block? There are a few differences, but a key one is how the program handles the code. When you use a custom block, the program pauses and executes all the steps under that block before proceeding. For example, notice how the program plays the entire sound before moving on to the spin. Since the program pauses to execute all the code in a custom block, if you place a forever block under it, the program will never reach the next code blocks in the main program.
In contrast, when you use broadcasts, the program sends the message and then continues with the next steps, allowing code sequences to run simultaneously. For instance, when I use a broadcast, you’ll see the spin happening while the sound is playing because the program sent the message and moved on.
When deciding whether to use a custom “My Blocks” block or a broadcast, consider whether you want to execute each step in the procedure before moving on or if you prefer the code to run simultaneously as the program progresses. It’s also important to note that custom blocks are specific to the sprite where they were defined. If I switch to a different sprite, my custom block won’t be available in the blocks palette. To use the same code for additional sprites, I would need to copy the definition to each one. Unlike a broadcast block, which can send messages globally between all sprites and backdrops, a custom “My Blocks” block is local and can only be used by the sprite it was defined on. The call for the custom block isn’t received by other sprites, even if their custom blocks share the same name.
You might be curious about the “Run without screen refresh” option. When viewing a Scratch program running on the stage, you may not notice that the screen is constantly refreshing, redrawing the scene at a specific frame rate. If the refresh rate is appropriate, your eyes perceive continuous motion, allowing you to see all the intermediate steps as the program progresses. However, if the sequence runs quickly between refreshes, you may only see the final result.
Sometimes, we want to observe the action, while other times, we may only want to see the outcome. For example, consider a code that draws a wall of bricks on the stage. If I set up this custom block without checking “Run without screen refresh,” I can see each brick being placed individually. Now, if I edit this custom block and check “Run without screen refresh,” it will attempt to execute the script as quickly as possible in one frame, refreshing the screen only after completing all the steps. When I run the custom block now, all the bricks appear at once.
If you’ve used turbo mode in Scratch, this concept is similar. However, turbo mode applies to the entire program, while “Run without screen refresh” only applies to the procedure in your custom block. One important note is that if any blocks in your custom block involve timing, you should avoid using “Run without screen refresh.” The program needs to respect the timing, and attempting to run the code without refreshing could lead to lag, screen freezes, or even crashes.
In another video, we’ll explore creating more complex custom blocks using inputs.
—
This version maintains the original content’s meaning while removing any informal language or unnecessary details.
Scratch – A visual programming language used to create games and animations. – In Scratch, you can drag and drop blocks to make your own interactive stories.
Blocks – Pieces of code that you can connect together to create a program in Scratch. – By connecting different blocks, you can make a sprite move across the screen.
Code – Instructions written in a programming language that a computer can understand. – When you write code, you tell the computer what actions to perform.
Custom – Something that is made or modified to fit a specific need or purpose. – You can create a custom sprite to make your project unique.
Broadcast – A command in Scratch that sends a message to trigger actions in other parts of the program. – When the sprite receives the broadcast, it starts a new animation.
Sprite – A character or object in Scratch that can be programmed to move and interact. – You can change the costume of a sprite to make it look different.
Program – A set of instructions that a computer follows to perform a task. – We wrote a program to make the sprite dance when we press the space bar.
Message – Information sent from one part of a program to another to trigger an action. – The sprite changes color when it receives a message from another sprite.
Sound – Audio effects or music that can be added to a Scratch project. – You can add a sound to play when the sprite jumps.
Refresh – To update or reload the content on a computer screen. – If the game doesn’t start, try to refresh the page and see if it works.
Cookie | Duration | Description |
---|---|---|
cookielawinfo-checkbox-analytics | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics". |
cookielawinfo-checkbox-functional | 11 months | The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional". |
cookielawinfo-checkbox-necessary | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary". |
cookielawinfo-checkbox-others | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other. |
cookielawinfo-checkbox-performance | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance". |
viewed_cookie_policy | 11 months | The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data. |