Scratch

natalie · 2007-07-24 22:01:38

As we are looking over all the suggestions, one that is high on the list is giving the ability to define your own blocks in Scratch.

An earlier version of Scratch had the ability to create procedures, but they got confused with broadcast/when-I-receive, so were removed. The hope is that by conceptualizing them as making a new block, the difference will be more concrete.

Kevin Karplus put forward a proposal for how they could work in a previous thread. I want to highlight it here, and invite additional thoughts and suggestions.

natalie · 2007-07-24 22:05:19

Here's what Kevin proposed:

kevin_karplus wrote:
For creating new blocks, there could be a "create-a-new-block" option on the sprite selector panel, and new blocks could be treated a lot like sprites.

Initially, I would recommend that new blocks be given a choice of only 2 flavors:
straight-through block
control block (which surrounds a chunk of code)
but later additions may make more choices available.

and be given a choice of 1 or 2 parameters, with the following types:
boolean (better call it true/false)
number
message
sprite-name

when the parameter types are chosen, then the parameters appear as blocks (or in the pulldown list for messages or sprites) . Perhaps they could all be colored pink, to represent their special status as parameters.

For loop blocks, a special block would be needed to represent the body of the loop.

A defined block would be allowed only one script, and a control block should use the special <body of code> block (possibly more than once).

One useful feature would be to be able to define variables "for this sprite only" in the defined blocks.

toontownmiser · 2007-07-24 22:11:11

As a parameter, something that would be remarkably helpful is a color output.

kevin_karplus · 2007-07-24 23:59:42

Yes, the option of a color (as in touching color) would be useful. This might mean needing color variables though, which would be useful, but would be large extension to scratch, which doesn't currently handle data types. Of course, if colors are encoded in single numbers, then they *can* be used in existing variables. If 24-bit colors are used,
then (red*256 + green)*256 + blue would be a simple encoding that would allow more sophisticated programmers to manipulate the colors, and not just have color=color tests.

(Natalie, by "the sprite selector panel" I did mean the lower-right pane.)

Mick · 2007-07-29 14:42:57

I think a yellow bock would look good. It wud be cool if there could be an 'upload block' button. There could be a thing at the top of the screen (e.g. projects, galleries, forums)
called blocks. You could download them onto scratch. Which would be a better place to keep the blocks? In a file or folder, like sounds and costumes or in a block section, like motion or pen? I think the block section is a bad idea cuz it wud get really big after a while. Maybe there could be a block section & your able to import blocks from a file or folder. Maybe the block section cud be called 'Miscellaneous'.

kevin_karplus · 2007-07-29 17:25:13

There are three places for custom blocks:
files
custom pane for using blocks
pane for defining and editing blocks

I think that a custom pane (like the movement, looks, ... panes) would be fine for using the new blocks.

I think that defining and editing blocks should be like editing scripts for the stage.

Custom blocks should be savable as parts of projects, exported by themselves (like sprites), exported with sprites that use them, and exportable as libraries (a set of custom blocks). The biggest problem comes when importing custom blocks, if the blocks are already defined in the project---do the imports replace the old blocks? get new names? i would lean towards replacing the old blocks, so that importing an improved library would update the project.

Mick · 2007-07-30 10:43:08

Hmm... Maybe you could make blocks in a thing called 'Block Maker' or something. There could be a programming place at the bottom & if what your writing in there means anything then there would be a screen at the top that makes an image of what the block would look like. Then you could save it in a folder then open the block in a section for blocks that have been made. & every time you start a new project that section is cleared & you have to import the block(s) again. & who cares if a block does something that another block already does. You could make all the blocks again except make them green, or bigger. & if you like a block then you could upload it onto the website. & if it does something that the Scratch Team find useful, the block could be added to the next version of Scratch!

kevin_karplus · 2007-07-30 15:10:08

I don't like the idea of having auxiliary programs. Block making (procedures) is a fundamental programming concept that should be integral to the program, not an "add-on" feature.

Mick · 2007-07-31 10:28:19

wat?

mdusoe · 2007-07-31 16:38:41

I think that this is a great idea. Code reuse to the max! For example, in my SwapIt game (http://scratch.media.mit.edu/projects/mdusoe/21506), I could have each of the 36 balls use "DoInit" block. DoInit is defined as a series of steps to take before the game is played (clear counters, set positions, etc.). Then, if I ever need to add to the list of things for each ball to do, I could just make the change in one spot, and all balls would react correctly.

Some things to think about though:

Parameters - are they by reference or by value? I don't think that your target audience (8-14 yos) should need to make that distinction. I think I would lean toward by reference, so that the block can change the values (and therefore the state) of the current sprite.

Variables - could each block have it's own "private" variables?

Control-Type blocks - Kevin, what do you mean by this? I can't think of an example where this would be useful. Probably me not understanding... Could you give an example?

Interface - Couldn't these just be defined as scripts? Instead of a hat that says "When I receive xyz", maybe a different picture (rooftop?) that says "when xyz in executed with arguments abc and def". Just a thought to keep the interface similar and not throw too many "new" things at the user for this new concept...

Whatcha think?
Mike.

Last edited by mdusoe (2007-07-31 16:39:24)

kevin_karplus · 2007-07-31 16:55:28

I agree that pass by reference is easier to understand than pass by value.

Blocks should be able to have local variables. A more difficult question is whether the variables are really local (newly allocated each time the block is entered) or locally-scoped global variables (like C and C++ static variables) which retain state from one entry of the block to the next. In either case, each instance of the block should have its own variables, not shared with other copies of the block.

Many of the control constructs in scratch could be implemented in a library using just a few basic blocks. For example, if all we had for looping was "repeat until <cond> (<body>)", we could define others:

repeat <n> (<body>) =
local var i
set i to round(<n>)
repeat until i < 1
<body>
change i by -1

forever (<body>) =
repeat untl 0=1
<body>

forever if (<cond>) (<body>) =
repeat until 0=1
wait until <cond>
<body>

There are several other looping constructs one might want---some generic, some specific to a particular program (such as forall loops over specific sets of items).

For straight-line code, one could use a generic procedure-call box, but this would not work for defining new control constructs. The definition of a block could be done with a "procedure" hat, as you suggest, but where does the script go? In a sprite? on the stage?
I suggest that such scripts should have a procedure definition page of their own, accessible below the stage icon.

xenos · 2007-08-01 05:59:50

I appreciate CustomBlocks.
An idea I have is to hand down to the block aucomatically the sprite where it is used at the time of execution. So you Motion, looks and all other stuff would be applied to this sprite.

Geetings
Xenos

Mick · 2007-08-01 08:46:18

Am i the only 1 here that doent know wat u guys r talking about? hmm

mdusoe · 2007-08-01 09:14:43

Funny kevin, thhat's exactly what I was thinking - A separate section for them, under the stage. Although I could also see putting them on the stage, since that is where I put "global code" anyway (when I receive ScoreChanged <check for level change>), I don't think this would make it easy to grasp the code-reuse, because the initial thought would be that these blocks "belong" to the stage. That thought could be difficult to dispell.

I think that the local variables should not be static. They should be re-initialized every time the block is executed. This, I think, will be the easiest to understand. If you have a need for persisted values, define a variable, and pass it in (assuming they are by reference smile )

I can see your looping constructs now. Thank you for the explanation. In addition, if the ability to create multiple instances of a sprite is granted, then a "for each" construct will be become possible...

Mick · 2007-08-10 17:02:57

can u plz explain wat u mean? i dont understand u...

relyt12101 · 2007-08-19 20:22:40

It would be tough, but could work.

I still think http://scratch.mit.edu/forums/viewtopic.php?id=717 would be nice.

AngelEyra · 2007-08-19 23:13:44

I think I'm getting confused...

eyra

Mick · 2007-08-22 15:22:19

ye me too.

Last edited by Mick (2007-08-22 15:23:05)

Ned · 2007-11-27 19:16:49

I strongly suggest adopting this suggestion. Without the ability to create named procedures ("Custom Blocks"), Scratch seems destined to teach a development anti-pattern - excessive copy/paste reuse without factoring out common code.

Creating a Custom Block could be accomplished via a Control Hat Block with a specifiable name and variable number of input parameters. I disagree with the idea of a sidebar tool for Custom Block defining - Custom Blocks could be defined in a new Custom Block category (a peer to Motion, Looks, Sound, etc) comparable to the Variable tool. Editing the Custom Block (whether at initial creation, later modification, or inspection) could occur in a new peer to the Scripts, Costumes, and Sounds tabs called "Custom Block".

Each Custom Block would define a new Stack Block, accessible from the Custom Blocks tool. One would just add the appropriate Custom Block to their script like any other Stack Block, and then specify the necessary arguments.

Custom Reporters could be defined in a similar manner, but with a single output parameter being specified.

I agree that pass-by-reference would be most intuitive in this environment, and would reduce the urgency of Custom Reporters.

It would be nice if Variables could be scoped locally to a Custom Block/Custom Reporter.

beckerb4 · 2007-12-23 15:22:54

I strongly agree with Ned's comments. Scratch is great, but we don't want to reinforce any bad practices (like cut and paste of code) in our budding programmers.
If blocks/procedures are added, I don't think they need a new color. Two new orange colored "control" nodes should do:
1) [ when -v- block called with + ]
2) [ call block -v- ]
Note I'm using the term "node" instead of block so it does not get confused with the concept of a block/procedure which we are trying to introduce.

The parameters part of this will be a challenge as it would be really nice if we could all a block with an arbitrary list of parameters.
You can see use cases where you would want to pass multiple parameters of different types (of which there are currently 4):
- boolean
- number
- string
- sprite
Here are some ideas on how this could work.
When you click the +, you declare another parameter by giving it a name and type (in a popup).
Then when you drag out a "call block" node and select the name of the block, the appropriate input shapes/dopdowns will appear in the right side area,
and you just need to fill them in as you do for other nodes.
The difference here is that the parameters will appear dynamically based on what you defined for you named block/procedure.

When actually adding elements to the body of the block/procedure, you can drag and drop the parameters (foo or bar) from the "when block called with (foo) (bar)" node at the top.

Here is an example:
1) I drag and drop a [ when -v- block called with + ] node into the scripts pane.
2) I click the + after the "with". A popup appear that asks you for a name of the parameter and allows you to select the type from a droplist.
My name is "foo" and type is string.
Now the node looks like this:
[ when myProcedure block called with foo + ]
3) I can now keep adding more parameters by clicking the +.
I will add one more "bar" of type boolean. Now I have
[ when myProcedure block called with foo, bar + ]
4) The body of my method may be something like this
if (bar)
say (foo)
5) The bar and foo got placed by dragging and dropping them from the list of parameters in the [ when myProcedure block called with foo, bar +] node.
6) In another script somewhere, I can invoke myProcedure by dragging out a [ call block -v- ] node and selecting "myProcedure" from the -v-. Once I do that, the required parameter input shapes immediately appear in that node. In this case I get a little white circle that requires a string to be entered (for the foo parameter), and I have a little hexagon shape for the bar parameter. If the parameters are not filled in, I suggest some base defaults get used so there is not an error and something will still happen.

kevin_karplus · 2007-12-23 18:43:19

beckerb4,

One important extension to your idea is to have scripts as parameters, so that new control blocks can be created.

midnightleopard · 2008-03-08 19:18:37

You know what would be so much easier? combinning old blocks to make new blocks like turning the scroll script into a scroll block, and stuff.

Sakani · 2008-03-10 17:45:26

A new thing to this block<change[ ]effect by(
Say one that makes it look like the scratch cat or Destorying it or Crushing it together.
Those would be good.

likegames · 2008-04-20 13:37:16

forget block maker, edit it with the source code!

Cyclone103 · 2008-05-05 12:45:20

I think that the current block type needed most is an array. Arrays allow retention of more data than a variable. If that block were to be added, it would probably go under variables, and a good color would be yellow. If an array block was added, everyone could expand their work much easier, since only one "variable style block" would be used for storing massive amounts of data.

Scratch

archived forums

#1 2007-07-24 22:01:38

Build a block (procedures)

#2 2007-07-24 22:05:19

Re: Build a block (procedures)

kevin_karplus wrote:

#3 2007-07-24 22:11:11

Re: Build a block (procedures)

#4 2007-07-24 23:59:42

Re: Build a block (procedures)

#5 2007-07-29 14:42:57

Re: Build a block (procedures)

#6 2007-07-29 17:25:13

Re: Build a block (procedures)

#7 2007-07-30 10:43:08

Re: Build a block (procedures)

#8 2007-07-30 15:10:08

Re: Build a block (procedures)

#9 2007-07-31 10:28:19

Re: Build a block (procedures)

#10 2007-07-31 16:38:41

Re: Build a block (procedures)

#11 2007-07-31 16:55:28

Re: Build a block (procedures)

#12 2007-08-01 05:59:50

Re: Build a block (procedures)

#13 2007-08-01 08:46:18

Re: Build a block (procedures)

#14 2007-08-01 09:14:43

Re: Build a block (procedures)

#15 2007-08-10 17:02:57

Re: Build a block (procedures)

#16 2007-08-19 20:22:40

Re: Build a block (procedures)

#17 2007-08-19 23:13:44

Re: Build a block (procedures)

#18 2007-08-22 15:22:19

Re: Build a block (procedures)

#19 2007-11-27 19:16:49

Re: Build a block (procedures)

#20 2007-12-23 15:22:54

Re: Build a block (procedures)

#21 2007-12-23 18:43:19

Re: Build a block (procedures)

#22 2008-03-08 19:18:37

Re: Build a block (procedures)

#23 2008-03-10 17:45:26

Re: Build a block (procedures)

#24 2008-04-20 13:37:16

Re: Build a block (procedures)

#25 2008-05-05 12:45:20

Re: Build a block (procedures)

Board footer