Sometimes people want to use two, three or even more clones of a sprite (for example: a fruit, a balloon, or anything else), which have exactly the same function in the project.
The problem with copying a sprite is that you have to change all of the copies if you want to change something in their scripts.
I think, a CLONE tool would be practical besides the COPY (and not instead of that).
If you used the CLONE tool to clone a fruit (named Fruit), the original would be given the new name: Fruit #1, and the CLONE's name would be Fruit #2. After that, you could make Fruit #3, and so on.
If you changed anything in a script belonging a Fruit, all of the Fruits would be changed.
However, they could wear different costumes and could be in different places (and so on) at a particular time, because a script would instruct only the owner of it, of course.
All of the clones (#1, #2, ...) AND the clone without an ordinal number would be found in the drop list of 'point towards...', 'touching...?' etc. Point towards Fruit (without an ordinal number) would mean to point towards one of them randomly, meanwhile touching Fruit? would mean touching anyone of the Fruits.
(By the way, Scratch lets the user give the same name to sprites, which is illogical, I think.)
I hope this idea is worth improving somehow.
Last edited by bernatp (2007-03-20 07:07:07)
Thank you for the detailed and well-thought-out suggestion. What you are are suggesting is a step towards making Scratch a prototype-based language (such Self, a language I worked on). Such a facility would make it easier to change the behavior of a collection of sprites. That would be a help for larger projects and useful for experienced programmers, but it could make Scratch harder for beginners to understand. I think we'd like to err on the side of keeping things easy for beginners. When people outgrow Scratch, I think Greenfoot might be a nice next step. It's sort of like the Scratch stage + sprites idea but programmed in Java with a nice interface. And, of course, their equivalent of sprites are instances of real classes.
Last edited by johnm (2007-03-19 20:39:24)
On second thoughts I absolutely agree with you.
Another idea: what if you could grab a sprite's 'Scripts', 'Costumes' and 'Sounds' tab (actually one of these labels) and drag to another sprite in the Sprite list. This question (or something similar) would pop up: "Replace all the Scripts/Costumes/Sounds?".
How about it? (To my mind, it wouldn't be disturbing at all, wouldn't confuse beginners, and would be useful.)
Last edited by bernatp (2007-03-20 07:08:39)
Nice idea! You probably know that you can already drag and drop individual scripts (or blocks), sounds, and costumes from one sprite to another to copy that item to the other sprite. Dragging the entire tab would be a nice extension of that.
There are some questions about the UI. For example, it could be alarming it was too easy to drag a tab when that was not your intention. So maybe you'd need to hold down shift while you started the drag. And then there is the question of whether this operation *replaces* the contents of the dragged tab in the target sprite or adds to it. I suspect replacing would be more useful, at least for scripts.
But this would definitely be a way to give multiple sprites the same scripts in a way that's consistent with the way Scratch already works. Other than the special UI gesture to drag the tab, there's no magic. It's just copying (or replacing) the "stuff" in the target sprite.
Here's a technique for making multipe sprites with the same behavior you can use in the current version of Scratch. Make one sprite that does what you want and then use the stamp tool to make a bunch of copies. If you hold down shift while stamping, the stamp tool will be "sticky" (i.e. the cursor will remain the stamp tool instead of reverting to the drag tool). So you can click a bunch of times really fast to generate a bunch of copies of the sprite. If you later realize you need to change the code, you can delete all but one copy of that sprite (the scissors tool is also sticky if you hold down shift), change the code in that one copy, and then re-copy it. This sounds tedious, but it's actually pretty quick to do in practice (once you know the shift trick to make the tools sticky).
I hope this helps!
Last edited by johnm (2007-03-20 18:10:33)
Thanks for your detailed reply.
The shift trick, that you described, is undoubtedly a really good solution, indeed.
Maybe, this technique (using shift) should be mentioned at the Toolbar section in the Reference Guide (Some other functions (eg. clean up) are also "hidden" which means not mentioned anywhere.)
Last edited by bernatp (2007-03-22 17:04:02)
A by-reference model would be workable as well though. You could just have one "hat" which says "Use same scripts as ----v", where you can select any other sprite. This would allow you to create a master sprite/scipt and then have as many as you like which use the same scripts (methods). This would not be alarming, since it would be an option to use or not, and makes sense to non-programmers as well. Along those lines, the touching sprite conditional could include "<any>", so that one could easily test for touching anything other than onself. I think this is basically what the original request was speaking about.