Discuss Scratch
- Discussion Forums
- » Suggestions
- » Suggestions for 3.0
![[RSS Feed]](//cdn.scratch.mit.edu/scratchr2/static/__5b3e40ec58a840b41702360e9891321b__//djangobb_forum/img/feed-icon-small.png "[RSS Feed]")
![[RSS Feed]](http://cdn.scratch.mit.edu/scratchr2/static/__5b3e40ec58a840b41702360e9891321b__//djangobb_forum/img/feed-icon-small.png "[RSS Feed]"){kind=icon}
- Blaze349
-
Scratcher
1000+ posts
Suggestions for 3.0
With scratch 3.0 coming up, I hope that scratch can redesign it's architecture to promote better programming practices.
Suggestion #1: Sprite Agnostic Code
Currently all code in scratch is tied a specific sprite. This is not good because it teaches new programmers to code in a bottom-up fashion. It isn't dry.
The current system is similar to this:
I would like for it to be more like this:
Rather than creating code that is dependent on sprites, I would like to have code that is standalone and reusable.
But it's difficult to make sprites through code?
We could have templates that contained costumes then we could just use it to create a sprite on the stage.
Suggestion #2: Project-agnostic code - Modules and Includes
Imagine if our code wasn't tied to our project. Imagine if we could export/publish it and then include the code in any project we had. This would improve collaboration and make it easier to create new projects.
I'll add more later
Suggestion #1: Sprite Agnostic Code
Currently all code in scratch is tied a specific sprite. This is not good because it teaches new programmers to code in a bottom-up fashion. It isn't dry.
The current system is similar to this:
# sprite 1
define move(x, y):
go to (x) and (y)
I would like for it to be more like this:
# move.whateverscratchextension
define move(x, y, sprite):
sprite.go to (x) and (y)
Rather than creating code that is dependent on sprites, I would like to have code that is standalone and reusable.
But it's difficult to make sprites through code?
We could have templates that contained costumes then we could just use it to create a sprite on the stage.
Suggestion #2: Project-agnostic code - Modules and Includes
Imagine if our code wasn't tied to our project. Imagine if we could export/publish it and then include the code in any project we had. This would improve collaboration and make it easier to create new projects.
I'll add more later
- _nix
-
Scratcher
1000+ posts
Suggestions for 3.0
These are definitely both nice features I've thought about before.
So, let's look at that first suggestion. You're suggesting something like this:
I think the first thing you should do is think about this in terms of Scratch blocks, not (pseudo-)code. Let's pick apart each line..
Okay, how should we maintain a reference to the sprite? That is, what is the actual value of the “sprite” variable? In the current Scratch system, it could be the name of a sprite, but that wouldn't work with clones.
The most correct response is that it's actually a sprite. If you've used Snap! before, you'll probably already be familiar with the idea that sprites are values, just like strings, numbers, and such. The thing is, if you have sprites as values, you'll need to be able to store them in variables, lists, etc. In theory that wouldn't take too much extra work, but it is something to be aware of.
Okay, so, now that we've got that out of the way, let's figure out what this script would actually look like. Would it look like this?
Then, when we run this custom block, will it look like this?
But that's a bit inconvenient. I wouldn't want to have to stick “myself” as an input into all of my custom blocks that use sprites. Perhaps instead the “sprite” input should be implied:
See, the actual stack block “move (x) (y)” doesn't have that “— caller:” part. That's automatically given to the custom block by Scratch.
Moving on..
Okay, so, I want to make clear a couple of things here. Your code will start to get very repetitive if you have to use “sprite.(do something)” at the start of all your sprite-based commands. See, imagine this:
This looks even worse in Scratch blocks:
Plus, it means having a ton of new blocks – all the normal sprite-related blocks, except with a sprite as an input – which would make code non-portable. (What happens if you copy the script “set x to 50” into one of those “sprite agnostic” custom blocks? Would an input with the block “(sprite)” be added automatically?)
As a solution, you might consider having a “tell sprite to” block. Here's how that would work instead:
And do you know what the best thing about this is? The “tell” block doesn't need to be used inside one of those “sprite agnostic” custom blocks. You could use it anywhere. I won't go over many examples; this is already a suggestion other people have discussed. But note this – it would be even more powerful if all sprites and clones were stored as data, because then you could do something like this:
That script would always render things in the order background, tiles, characters, UI. Draw order is very important when you're dealing with pen, and this would make dealing with draw order much easier, and would get rid of the need for using broadcasts, which are slow (“broadcast and wait” is needed if you want to maintain a draw order, and “broadcast and wait” always takes at least one Scratch tick – if you use “broadcast and wait” multiple times in a single “render” script, your Scratch project will run very slowly, as it waits for each of those “broadcast and wait”s to finish!).
Here are some more interesting and relevant discussion topics:
(If I get around to responding to your second idea – which I've definitely also thought about, even recently – I'll definitely put it in a separate post. This one's too long already! :P)
So, let's look at that first suggestion. You're suggesting something like this:
# move.whateverscratchextension
define move(x, y, sprite):
sprite.go to (x) and (y)
I think the first thing you should do is think about this in terms of Scratch blocks, not (pseudo-)code. Let's pick apart each line..
define move(x, y, sprite)
Okay, how should we maintain a reference to the sprite? That is, what is the actual value of the “sprite” variable? In the current Scratch system, it could be the name of a sprite, but that wouldn't work with clones.
The most correct response is that it's actually a sprite. If you've used Snap! before, you'll probably already be familiar with the idea that sprites are values, just like strings, numbers, and such. The thing is, if you have sprites as values, you'll need to be able to store them in variables, lists, etc. In theory that wouldn't take too much extra work, but it is something to be aware of.
Okay, so, now that we've got that out of the way, let's figure out what this script would actually look like. Would it look like this?
define move (x) (y) (sprite)
...
Then, when we run this custom block, will it look like this?
move (40) (70) (myself :: sensing) :: custom
But that's a bit inconvenient. I wouldn't want to have to stick “myself” as an input into all of my custom blocks that use sprites. Perhaps instead the “sprite” input should be implied:
define move (x) (y) — caller: (sprite)
...
move (40) (70) :: custom
See, the actual stack block “move (x) (y)” doesn't have that “— caller:” part. That's automatically given to the custom block by Scratch.
Moving on..
sprite.go to (x) and (y)
Okay, so, I want to make clear a couple of things here. Your code will start to get very repetitive if you have to use “sprite.(do something)” at the start of all your sprite-based commands. See, imagine this:
set n to 0
repeat (100) {
change n by 1
sprite.change x by n
sprite.change y by 2 * n
sprite.turn 15 degrees clockwise
sprite.change ghost effect by 1
}
This looks even worse in Scratch blocks:
set [n v] to [0]
repeat (100)
change [n v] by (1)
(sprite :: custom-arg) change x by (n) :: motion
(sprite :: custom-arg) change x by ((2) * (n)) :: motion
(sprite :: custom-arg) turn @turnRight (15) degrees :: motion
(sprite :: custom-arg) change [ghost v] effect by (1) :: looks
end
Plus, it means having a ton of new blocks – all the normal sprite-related blocks, except with a sprite as an input – which would make code non-portable. (What happens if you copy the script “set x to 50” into one of those “sprite agnostic” custom blocks? Would an input with the block “(sprite)” be added automatically?)
As a solution, you might consider having a “tell sprite to” block. Here's how that would work instead:
set [n v] to [0]
repeat (100)
change [n v] by (1)
tell (sprite :: custom-arg) to {
change x by (n)
change x by ((2) * (n))
turn cw (15) degrees
change [ghost v] effect by (1)
} :: control
end
And do you know what the best thing about this is? The “tell” block doesn't need to be used inside one of those “sprite agnostic” custom blocks. You could use it anywhere. I won't go over many examples; this is already a suggestion other people have discussed. But note this – it would be even more powerful if all sprites and clones were stored as data, because then you could do something like this:
when I start as a clone // in the "tile" sprite
add (myself :: sensing) to [tiles v] // this is a global list
// in the "render" sprite
clear
..draw background.. :: grey
set [i v] to (0)
repeat (length of [tiles v])
tell (item (i) of [tiles v]) {
stamp
} :: control
end
..draw characters.. :: grey
..draw user interface.. :: grey
That script would always render things in the order background, tiles, characters, UI. Draw order is very important when you're dealing with pen, and this would make dealing with draw order much easier, and would get rid of the need for using broadcasts, which are slow (“broadcast and wait” is needed if you want to maintain a draw order, and “broadcast and wait” always takes at least one Scratch tick – if you use “broadcast and wait” multiple times in a single “render” script, your Scratch project will run very slowly, as it waits for each of those “broadcast and wait”s to finish!).
Here are some more interesting and relevant discussion topics:
- “As” block, which discusses a block that is essentially the same as “tell (sprite) to”
- Global Procedures, which discusses, well, custom blocks that you can use from any sprite (this is relevant because you could define the global custom block “move (x) (y) (sprite)” and use it from any sprite with “move (..) (..) (myself)”)
- Looking for suggestions how to do global custom blocks better, which was a somewhat short-lived but in-depth discussion on global custom blocks
(If I get around to responding to your second idea – which I've definitely also thought about, even recently – I'll definitely put it in a separate post. This one's too long already! :P)
- Blaze349
-
Scratcher
1000+ posts
Suggestions for 3.0
Thank you for taking a look at the suggestion.
My idea is to simplify the ‘sprite’ into a graphical object with an x and y coordinate. This means that sprites can be created in real time and assigned to variables (clones can not be assigned to variables). The value of the sprite could be a random hash that would point to the sprite object. Or it could be the actual sprite object (This seems like a better idea)
There wouldn't be ‘myself’ because the code will not be part of the sprite. My idea is like this:
There are templates which are predesigned sprites (costumes and sounds).
Within the code, which has nothing to do with the sprite, one can create a sprite and assign it to a variable.
It would look like this:
I agree that it isn't the best option but it is definitely better than the current option.
For example, Let's say I have two sprites and I want them to perform the script that you've written. Using method 1
Using method 2:
Though it isn't the best option, the reduction in repetition justifies it.
I really like the tell-block idea but I don't think that it should be restricted to sprites.
Rather than a tell-block we should have ‘within’ block that allows us to call any method within an object (sprite, struct, whatever) as a global method (it would override them in a similar fashion to local variables). It is basically the same thing but I don't want it to be restricted to sprites.
Thanks for the links. Global Procedures are especially important.
Okay, how should we maintain a reference to the sprite? That is, what is the actual value of the “sprite” variable? In the current Scratch system, it could be the name of a sprite, but that wouldn't work with clones.
My idea is to simplify the ‘sprite’ into a graphical object with an x and y coordinate. This means that sprites can be created in real time and assigned to variables (clones can not be assigned to variables). The value of the sprite could be a random hash that would point to the sprite object. Or it could be the actual sprite object (This seems like a better idea)
But that's a bit inconvenient. I wouldn't want to have to stick “myself” as an input into all of my custom blocks that use sprites. Perhaps instead the “sprite” input should be implied:
There wouldn't be ‘myself’ because the code will not be part of the sprite. My idea is like this:
There are templates which are predesigned sprites (costumes and sounds).
Within the code, which has nothing to do with the sprite, one can create a sprite and assign it to a variable.
It would look like this:
set [sprite v] to (new [sprite v] from template[scratch cat v])
Okay, so, I want to make clear a couple of things here. Your code will start to get very repetitive if you have to use “sprite.(do something)” at the start of all your sprite-based commands. See, imagine this:.
I agree that it isn't the best option but it is definitely better than the current option.
For example, Let's say I have two sprites and I want them to perform the script that you've written. Using method 1
set [n v] to [0]
repeat (100)
change [n v] by (1)
(sprite :: custom-arg) change x by (n) :: motion
(sprite :: custom-arg) change x by ((2) * (n)) :: motion
(sprite :: custom-arg) turn @turnRight (15) degrees :: motion
(sprite :: custom-arg) change [ghost v] effect by (1) :: looks
end
Using method 2:
set [n v] to [0]
repeat (100)
change [n v] by (1)
change x by (n) :: motion
change x by ((2) * (n)) :: motion
turn @turnRight (15) degrees :: motion
change [ghost v] effect by (1) :: looks
end
set [n v] to [0]
repeat (100)
change [n v] by (1)
change x by (n) :: motion
change x by ((2) * (n)) :: motion
turn @turnRight (15) degrees :: motion
change [ghost v] effect by (1) :: looks
end
Though it isn't the best option, the reduction in repetition justifies it.
I really like the tell-block idea but I don't think that it should be restricted to sprites.
Rather than a tell-block we should have ‘within’ block that allows us to call any method within an object (sprite, struct, whatever) as a global method (it would override them in a similar fashion to local variables). It is basically the same thing but I don't want it to be restricted to sprites.
Thanks for the links. Global Procedures are especially important.
- _nix
-
Scratcher
1000+ posts
Suggestions for 3.0
(clones can not be assigned to variables).
Why?
Rather than a tell-block we should have ‘within’ block that allows us to call any method within an object (sprite, struct, whatever) as a global method (it would override them in a similar fashion to local variables). It is basically the same thing but I don't want it to be restricted to sprites.
Er, what kind of other things would you put in there, besides sprites? I'm not sure what you mean by “struct” (I've never dealt with any languages that use that term for anything)
––––
Okay, so – are you suggesting individual-sprite-specific code to not exist at all, in favour of a different way of programming projects?
I'm thinking that idea would be best for, well, a whole new language – I think a full redesign of how Scratch projects work, entirely, would be.. well, at the very least, incompatible with 2.0; and more importantly, very confusing to anybody who would have used Scratch before this.
I just want to make sure – I don't think redesigning all of Scratch for a new (even major) reason is a good idea, but it'll be easier to be a bit more open if we discuss this somewhat separately from Scratch.
Keep in mind, sprites are actors. Scripts are literally scripts. Each sprite has its own code, as each actor has their own scripts; although being able to make two sprites behave similarly, I think it's still important that sprites get their own scripts. Remember that Scratch is something made for all kinds of projects; we don't want to make it way-complex to make a simple animation or dress-up game! I just want to make sure that we don't get rid of these core ideas, since they're so important to Scratch. In a new programming language it would be easier to have all new core ideas.
But I still don't feel like I'm judging this fairly, since I don't entirely understand the suggestion!
- Blaze349
-
Scratcher
1000+ posts
Suggestions for 3.0
A struct is a type of data structure. It's found in languages such as C. https://en.wikipedia.org/wiki/Struct_(C_programming_language).
Yes, that is my main suggestion. It is bad to tie your code and your views together. Scratch should focus on programming first and animation second. That being said, the suggestion wouldn't really make it difficult to animate using Scratch. I think that it would make it easier.
Okay, so – are you suggesting individual-sprite-specific code to not exist at all, in favour of a different way of programming projects?
Yes, that is my main suggestion. It is bad to tie your code and your views together. Scratch should focus on programming first and animation second. That being said, the suggestion wouldn't really make it difficult to animate using Scratch. I think that it would make it easier.
- _nix
-
Scratcher
1000+ posts
Suggestions for 3.0
First – again, I want to make this super clear – your idea is really good. I think it would only work for a new programming language, though. A new site. Not Scratch. I'm going to explain why in the following part of this post. I just want to make it clear that your idea is still good, even though I don't think it would work for Scratch, specifically.Okay, so – are you suggesting individual-sprite-specific code to not exist at all, in favour of a different way of programming projects?Yes, that is my main suggestion. It is bad to tie your code and your views together. Scratch should focus on programming first and animation second.
––––––
I'm not going to argue about this all day because I've already done so plenty enough in an old discussion place on Scratch and it's tiring, but I'd like to state that you can't make radical changes like this, anymore. Scratch is popular. It has books. It's taught at schools. You can't just change the entire language so fundamentally everything made in previous versions of it become deprecated or obsolete.
The biggest problem is that you can't expect kids, or schools, or anyone, to be alright with their favorite simple programming language changing entirely overnight. Even if, as you say, it would make making animations easier – you can't do that, nobody should have to deal with a programming language changing so hugely and suddenly. People will worry that the only thing that's easy for them to program with will change to something entirely new again. How can a school, or a kid, trust it not to?
The only solution to implementing your idea without worrying all of Scratch's users is to do it gradually. You, as the Scratch Team, would have to make it very clear that the entire programming language will be changing a lot. You'd have to show people the new Scratch, and make sure that people are comfortable with moving to a drastically different language..
And before you can even think about transitioning from Scratch as we know it to your idea of Scratch, you need to make sure your idea works. Scratch is designed for kids. I'll repeat that – Scratch is designed for kids. Just making your new idea very clear and understandable enough – you actually need to make sure your idea works with kids by showing it to kids, and by letting them use your version of Scratch for themselves. And you'd still be running a somewhat colossal risk – the kids you worked with might find your new idea of Scratch to be cool and work really well, but what about all the kids who already have experience with old Scratch? You'd be effecting millions of users.
(Have I mentioned teachers, yet? They probably won't be too fond about the language changing so much, even if it's done over a slow transition! After all, once the transition is completed and your idea of Scratch is in place – well, all the old Scratch books won't be relevant anymore, so they'd have a hard time gathering all the resources for the new version of Scratch.)
That being said, the suggestion wouldn't really make it difficult to animate using Scratch. I think that it would make it easier.
I'm not initially convinced, but I am curious – I'd love to see a complete animation written in your language (even if your language has no interpreter/runtime yet; I just want to see the code). I dunno, program this in your language and show the code. You won't convince anybody without showing a real-world usage of your idea
- -stache-
-
Scratcher
500+ posts
Suggestions for 3.0
And before you can even think about transitioning from Scratch as we know it to your idea of Scratch, you need to make sure your idea works. Scratch is designed for kids. I'll repeat that – Scratch is designed for kids. Just making your new idea very clear and understandable enough – you actually need to make sure your idea works with kids by showing it to kids, and by letting them use your version of Scratch for themselves. And you'd still be running a somewhat colossal risk – the kids you worked with might find your new idea of Scratch to be cool and work really well, but what about all the kids who already have experience with old Scratch? You'd be effecting millions of users.*cough* We are “kids” *cough*
- _nix
-
Scratcher
1000+ posts
Suggestions for 3.0
Sure, I'm a kid, but I'm a kid with a relatively huge amount of experience with programming, as compared to kids who are new to programming. I'm also not seven, which is definitely a target age of Scratch.And before you can even think about transitioning from Scratch as we know it to your idea of Scratch, you need to make sure your idea works. Scratch is designed for kids. I'll repeat that – Scratch is designed for kids. Just making your new idea very clear and understandable enough – you actually need to make sure your idea works with kids by showing it to kids, and by letting them use your version of Scratch for themselves. And you'd still be running a somewhat colossal risk – the kids you worked with might find your new idea of Scratch to be cool and work really well, but what about all the kids who already have experience with old Scratch? You'd be effecting millions of users.*cough* We are “kids” *cough*
- XenoCoding
-
Scratcher
100+ posts
Suggestions for 3.0
*average Scratchers are 11-12.Sure, I'm a kid, but I'm a kid with a relatively huge amount of experience with programming, as compared to kids who are new to programming. I'm also not seven, which is definitely a target age of Scratch.And before you can even think about transitioning from Scratch as we know it to your idea of Scratch, you need to make sure your idea works. Scratch is designed for kids. I'll repeat that – Scratch is designed for kids. Just making your new idea very clear and understandable enough – you actually need to make sure your idea works with kids by showing it to kids, and by letting them use your version of Scratch for themselves. And you'd still be running a somewhat colossal risk – the kids you worked with might find your new idea of Scratch to be cool and work really well, but what about all the kids who already have experience with old Scratch? You'd be effecting millions of users.*cough* We are “kids” *cough*
- XenoCoding
-
Scratcher
100+ posts
Suggestions for 3.0
From a programmer's perspective, I really love the idea of templates on Scratch, and not having to program directly inside every sprite. However, there is the concern of it being too complicated for new Scratchers. I would really like to see some new features like this in 3.0. I sort of wish there were like to separate Scratch languages, one for more advanced users.
Regardless, I love the idea and it has my support.
Regardless, I love the idea and it has my support.
- -stache-
-
Scratcher
500+ posts
Suggestions for 3.0
*average Scratchers are 11-12.That's not too far off from me
- Discussion Forums
- » Suggestions
-
» Suggestions for 3.0