I need to build a mini version of the programming blocks that are used in Scratch or later in snap! or openblocks.
The code in all of them is big and hard to follow, especially in Scratch which is written in some kind of subset of SmallTalk, which I don't know.
Where can I find the algorithm they all use to parse the blocks and transform it into a set of instructions that work on something, such as animations or games as in Scratch?
I am really interested in the algorithmic or architecture behind the concept of programming blocks.
Scratch Blocks is a new development project for the next generation of graphical programming blocks, based on a collaboration between Google and MIT's Scratch Team — building on Google's Blockly technology and informed by the Scratch Team's expertise in developing creative learning tools for young people.
Scratch 3.0 is a completely new JavaScript-based codebase made up of multiple components such as "Scratch-GUI," now based on a library from Blockly, "Scratch-VM," which interprets code, and "Scratch-Render," the rendering engine. The Scratch Blocks are made using Blockly.
There are four main elements of Scratch: the stage, the sprites, the script and the programming palette. These elements can be compared to a play.
Scratch is a "block-based" programming language. This means instead of writing lines of code to program, we use "blocks". Each block has a specific category that describes what its purpose is. Sprites are the objects that perform actions in a project and these blocks tell the sprites what to do.
This is going to be just a really general explanation, and it's up to you to work out specifics.
There is a Block
class that all blocks inherit from. They get initialized with their label (name), shape, and a reference to the method. When they are run/called, the associated method is passed the current context (sprite) and the arguments.
Exact implementations differ among versions. For example, In Scratch 1.x, methods took arguments corresponding to the block's arguments, and the context (this
or self
) is the sprite. In 2.0, they are passed a single argument containing all of the block's arguments and context. Snap! seems to follow the 1.x method.
Stack (command) blocks do not return anything; reporter blocks do.
The interpreter works somewhat like this. Each block contains a reference to the next one, and any subroutines (reporter blocks in arguments; command blocks in a C-slot).
First, all arguments are resolved. Reporters are called, and their return value stored. This is done recursively for lots of Reporter blocks inside each other.
Then, the command itself is executed. Ideally this is a simple command (e.g. move). The method is called, the Stage is updated.
Continue with the next block.
C blocks have a slightly different procedure. These are the if <>
style, and the repeat <>
ones. In addition to their ordinary arguments, they reference their "miniscript" subroutine.
For a simple if/else
C block, just execute the subroutine normally if applicable.
When dealing with loops though, you have to make sure to thread properly, and wait for other scripts.
Keypress/click events can be dealt with easily enough. Just execute them on keypress/click.
Something like broadcasts can be done by executing the hat when the broadcast stack is run.
Other events you'll have to work out on your own.
This, along with threading, is the most confusing part of the interpretation to me. Basically, you need to figure out when to continue with the script. Perhaps set a timer to execute after the time, but you still need to thread properly.
I hope this helps!
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With