Scratch

hope this is the appropriate place to ask.  In the byob 3 reference manual, mention is made of a 'clone' functionality that hasn't been implemented yet.  Is this on the table for 3.1?  I see that panther has a 'clone' block in the block repository -- I confess I don't really have a sense yet of how different panther and byob are, so I can't tell if it would be plausible to modify the panther block for use in byob.  I'm using scratch in a primary school where I would estimate something like 70% of the boys want to write first-person shooter games that involve multiple identical enemies; it would be nice to be able to clone them.   

Thanks -- just starting to explore byob and very impressed at the new features it adds.  Thanks,
Matt

clintonhackers wrote:

In the byob 3 reference manual, mention is made of a 'clone' functionality that hasn't been implemented yet.  Is this on the table for 3.1?

Oh, absolutely!  It'll be somewhat different from the Panther version; they decided to make clones temporary, so they no longer exist once all their scripts stop running.  We're hoping not to need that restriction.  (If you want clones to go away in a particular project, you can keep a list of them and delete them explicitly.)

Let us know how your kids take to BYOB, and also if you have any good curriculum at that age level.  Thanks!

I have a suggestion: make an [when ⬣ clicked delete if clone] block, so that you can optionally make clones temporary. Also, how about a 'When (var) changed' hat block, so you can have 'active' variables without having a huge collection of variable names.

By the way, when I make a block in BYOB, the variable names look brown. Is that supposed to happen?

Last edited by floppy_gunk (2011-01-08 03:37:22)

@14God

"Then you would have to type in the name for all your sprites which may be practical for 5 sprites but what about 20 or 100?"

I fully agree and share your concern. Be confident that barvey/jens will bring a brillant answer to this. In the meantime :

1 - we don't make new applications with hundred of sprites everyday
2 - it takes 30 sec per sprite to set the name variable. It's a boring moment but programming is made of plenty of boring moments.
3 - I wonder if Byob is able correctly handle many hundred of sprites. It seems that he time to load/save applications considerably increase with the number of sprites involved.

There are some really great ideas flying around! I'd just like to add my voice in among them.

Other than first class everything, one key element I want to see in BYOB is a streamlined interface. I have no problem with Scratch/BYOB's current GUI; it's incredible how much power can be packed into such a simple layout. However, I'd love to see it refined. I know Jens and bharvey intend to keep the BYOB 4 interface as simple as possible, but I've recently learned through the program Blender3D that hot keys can make-or-break a GUI. Though I love coding in blocks, one of its limitations is speed. I can often picture a script very clearly in my mind, but when it comes to construction it takes minutes to assemble.

Just thought I'd throw that out there. If we can devise a powerful user-oriented interface, it will attract a wider variety of users...

Last edited by shadow_7283 (2011-01-08 10:49:51)

floppy_gunk wrote:

I have a suggestion: make an [when ⬣ clicked delete if clone] block, so that you can optionally make clones temporary.

Please don't feel dissed if I use this as an example of what I meant before about small footprint.  Your underlying idea, that there should be a way to kill clones, is sound.  But you've chosen only one of several conditions the user might pick as the way to delete clones.  I think s/he's more likely to want to delete all the children of a partuclar sprite at once, so in addition to your block we'd also need IF PARENT CLCKED DELETE ME or alternatively IF I'M CLICKED DELETE ALL MY CHILDREN BUT NOT ME.  Or maybe it'll be a screen button to delete all the clones: IF I'M CLICKED DELETE ALL CLONES.  Or maybe each clone disappears when hit by a laser: IF TOUCHING <red> DELETE ME.

Instead of all that, all we need is a DELETE ME block.  Then the user can use existing tools to make a script that does what you said:

WHEN CLICKED
DELETE ME

and we can also (using some of the blocks in the tools project) say

WHEN CLICKED
FOR EACH ITEM OF <CHILDREN>
    RUN [[DELETE ME] OF < >]

and so on for the others.

Also, how about a 'When (var) changed' hat block, so you can have 'active' variables without having a huge collection of variable names.

Yes, that's probably how we'd do it.  But it doesn't solve the huge collection of names problem!  On the Variables palette there's an orange blob for every variable, and that won't be changed by making them active -- nor should it; the active variables users create need to be visible so you can put them in scripts.  The right category for invisibility is system-created variables as opposed to user-created.  I guess there might be a "Make a variable"-shaped block saying "Show system variables" (or Hide if they're shown), or maybe a check box in the Edit menu.

By the way, when I make a block in BYOB, the variable names look brown. Is that supposed to happen?

Yes, Jens wanted to make a visible distinction between script variables and toplevel variables.  If you don't like it (just between us, I don't either    ), you can uncheck the "Scope contrast" item in the Edit menu.

xly wrote:

I wonder if Byob is able correctly handle many hundred of sprites. It seems that the time to load/save applications considerably increase with the number of sprites involved.

Yeah, we wonder that too.  We won't know until we get the first alpha version written!

But I'm quite sure that we can speed up saving.  The current Scratch save mechanism replaces each object with a different representation for saving, then has to go through all the objects again undoing that.  I expect this decision was made in the dark ages when it was actually possible to run out of memory.

Jens and I haven't even started talking about this issue, but it'll make me happiest if we can have a save format consisting of just a straight dump of data memory.  That would make for lightning-fast saving.  Loading will be a little trickier because the data memory might be somewhere else when the project is loaded on a different computer or with a different past history of loading and saving projects in this session.  But it's no harder than writing a compressing garbage collector, a well-understood task.  And in any case the save format has to be identity-preserving because we're going to have real linked lists, so loading will have that level of complexity no matter what.

Of course we'll make sure to be able to load BYOB3 projects, Scratch1.4 projects, and (when we know what they look like) Scratch2.0 projects!

shadow_7283 wrote:

There are some really great ideas flying around!

Yes, we're very excited to see all this interest that Jens's Morphic.js has generated!

hot keys can make-or-break a GUI. Though I love coding in blocks, one of its limitations is speed. I can often picture a script very clearly in my mind, but when it comes to construction it takes minutes to assemble.

That's a good idea, and it has the virtue of not adding to the visual complexity of the interface. 

So, what, built-in hotkeys for the most popular primitive blocks?  User-definable hotkeys?  Cursor keys in the editor, I should think.

And while we're on the subject, I want my scroll wheel to work in BYOB!  (When I say that to Jens he explains that it does work, but just does something other than what I want.  But I'm not backing down!)

bharvey wrote:

So, what, built-in hotkeys for the most popular primitive blocks?  User-definable hotkeys?  Cursor keys in the editor, I should think.

Well those are all good ideas to consider... I would start with the basics. A user should be able to switch between tabs and other such options quickly. I'm not a huge fan of "alt" shortcuts either. They aren't easily accessible. For example, switching between the "Scripts", "Costumes", and "Sound" tabs should be as easy as pressing the "a" and "d" keys (or something similar). Of course, these keys would only act as shortcuts whenever input is not being entered.

Another important idea is user-definable hotkeys. It would help me tremendously if I could insert a custom block with something as simple as the "q" key!

Another feature I'm rather fond of is an easily-accessible search menu. With a key like "space" I could bring up a small menu consisting of nothing more than a textbox and list. Then I could type the keys "ch" and blocks and actions that fit my description would be displayed. In this case it might come up with the "change x and y" blocks which I could choose between with the arrow keys.
A menu like this allows for "keys-only" coding. That means I could potentially navigate BYOB with the keyboard alone. If I wanted to insert a block into a script, I would just move into the proper position and insert a block with my search menu.

This would obviously require quite a bit of work to implement, but I think it would be well worth it.

bharvey wrote:

And while we're on the subject, I want my scroll wheel to work in BYOB!  (When I say that to Jens he explains that it does work, but just does something other than what I want.  But I'm not backing down!)

Agreed. 

Those are good thoughts... I wish I could show you the Blender 3D interface to show you where my inspiration comes from. Of all the (many) programs I've used, it's GUI is BY FAR the best. JTxt knows what I'm talking about.

I agree that the hotkeys should avoid "modes". Blender does a brilliant job of keeping a consistent interface. However, this concept also has to be sacrificed for input's sake. If I were typing in a textbox, I probably wouldn't want a hotkey to activate. HOWEVER, the use of the alt key for all shortcuts would slow down my work flow considerably. That's why keys' uses have to change upon context, but in a way that does not confuse the user. If a project was running, I wouldn't be able to use hotkeys because it could potentially interrupt input in my scripts. However, if I were to hold down "shift" in addition to pressing my typical hotkey (ex. shift+A), I could use shortcuts while a project is running. It doesn't really qualify as a "mode" since the hotkey itself isn't changing.

These are just examples of how I would use hotkeys. You really have to experience an interface that uses them correctly in order to appreciate how important they are.

As for the menu shortcut, I think it should be "Shift-F" if not "Space", IMHO.

Last edited by shadow_7283 (2011-01-08 16:47:11)

Ok. I get your points (even if I don't agree with them).   

Shift is much more accessible than control or alt. I can hold my pinky on shift while typing without a problem. Reaching back for the control and alt keys messes up the positions of my hands.

Admittedly, I don't type the "standard" way, but my method is faster so I don't really care. 

EDIT: On second (deeper) thought, I don't think you would need hotkeys while a project is running. It occurred to me that if you want to edit a script while your project is in progress, all you would need to do is pause or debug! If either were in use, the hotkeys shouldn't affect the project.

Now the only conflict with our "letter only" hotkeys is text input. I really don't see how this should be a problem as there's a pretty clear distinction between text being typed and the usage of hotkeys.

Last edited by shadow_7283 (2011-01-08 19:29:55)

While poking around 'underneath' BYOB in Squeak to add some file handling blocks I found most of the clone code already written, so added a Clones category with the following blocks:

[clone me]
[clone me () times]
[delete my clones]

When the clones of a sprite are created they are sent the message CloneCreation, so they can do something different to their 'parent' (all the code was already there).

After working with these a bit I added

[clone me and send ()]
[clone me () times and send ()]

so that you could send different messages to different clone 'families'. These aren't strictly needed since the clone broadcasts are directed towards the clones, not generally, but it's nicer for documentation purposes.

I've done the following sorts of projects:

'explode': the thing being exploded clones itself 16 times, hides itself, then each clone shrinks itself and start moving in a random direction subject to gravity.

'infection': uses 100 or so clones of a 'microbe', a number of which are immune, a number infected, and the rest healthy. The clones then move around, infected ones infecting any microbes they touch, but having a recovery period. You can use a slider to change the recovery period and see how reducing it decreases the spread of the disease.

Monte-Carlo estimate of PI: the clones position themselves randomly within a square and see how far they are away from the centre, colouring red or black depending on whether they are inside the inscribed circle. The ratio of the counts gives you PI/4. I seem to remember I ran this with up to 1000 clones but I may be imagining it: I know it was slow! BYOB certainly coped with far more clones than I could ever see myself using.

When the project is saved, or the project stopped, the clones vanish, and they aren't visible in the clone list at all (I didn't code this, it's just the way the existing code works). I've not found the need for any other features so far and you don't need to know the name of the cloned sprites since they only exist while the project is running. The only way you can communicate with them is via messages (and global variables). If you wanted to distinguish the clones in some way I suppose you could give each sprite its own number but I haven't really found a need so far.

Incidentally, the UK's Computing at School organisation is giving a talk on visual block programming (Scratch, BYOB, StarLogoTNG, and AppInventor at next week's BETT conference in London ('BETT is the largest education technology exhibition in the world...' but I don't know what it stands for: British Education Teaching Technology?).

John

Last edited by jstout (2011-01-08 19:57:40)

Robot_Maniac wrote:

I don't get how to make blocks, I meam, whenever  create a block and test it, it doesn't do anything!

Umm, I think this is way too vague for us to address your specific problem, apart from recommending the reference manual and the online tutorials.

Could you post pictures of a block you wrote (control-click or right-click the grey background of the Block Editor and you'll get a menu that includes the option of saving a picture) and a script in which you try to use it?  That would help a lot!