I think that we should be able to assign classes to sprites. This would be especially helpful in plat-former games. For instance, the ground sprites. Here is what someone would normally use for their scripts (this is my personal style. idk about anyone else);
when gf clicked forever if <(touching? [sprite 1 v]) or <(touching? [sprite 2 v]) or <(touching? [sprite 3 v]) or (touching? [etc! ;b v])>>> //execute actions here endThat script always becomes a pest, and fairly large if you're making some huge plat-former/scroller
when gf clicked forever if (touching? [class: ground v]) //execute actions here
torcado194 wrote:
It also makes it easier to sort sprites and scripts. Like if you have 50 different types of enemies but you want them all to have the same affect on the player, but do different things on their own. And maybe you could make a class a sprite on it's own as like a folder for all the different types of enemies you have so youre not shearching through thousands of sprites if you have a big game.
Would that not be one of the greatest ideas of all time?
------------------
SUPPORTERS
-------------------
* Zparx
*torcado194
*efisher82
*imaginelt
*joefarebrother
*harrypotter7890
*LS97
*muppetds
*NeilWest
*Mokat
Last edited by Zparx (2012-02-13 14:51:10)
Offline
Yeah, but then Scratch would become a full OOP, and more confusing for beginners.
Offline
LS97 wrote:
Yeah, but then Scratch would become a full OOP, and more confusing for beginners.
What do you mean? I don't think that adding classes is that confusing. I just explained it to where a 3-year old would understand it. I mean if they don't add it in scratch, then byob or panther should give it a shot at least
Offline
I agree with this idea completely. It also makes it easier to sort sprites and scripts. Like if you have 50 different types of enemies but you want them all to have the same affect on the player, but do different things on their own. And maybe you could make a class a sprite on it's own as like a folder for all the different types of enemies you have so youre not shearching through thousands of sprites if you have a big game.
Offline
Yes exactly. And I made that thread btw XD
Offline
i agree but i don't think they should be called classes. I think they should be called tags, and maybe there can be blocks like
|tag [sprite 1 v] with ()|
that would assign a tag to a sprite,
|remove tag for [sprite 1 v]|
and
(my tag)
and the ([] of [sprite 1]) block will have another category: tag. Also there will be blocks like
<touching sprite with tag () >
and maybe even a c block like
|make every sprite with tag () do|
Also if there is a clone block it will make the clone automatically have the same tag ( and costume and position and local variables) as the 'parent' sprite.
Offline
joefarebrother wrote:
i agree but i don't think they should be called classes. I think they should be called tags, and maybe there can be blocks like
|tag [sprite 1 v] with ()|
that would assign a tag to a sprite,
|remove tag for [sprite 1 v]|
and
(my tag)
and the ([] of [sprite 1]) block will have another category: tag. Also there will be blocks like
<touching sprite with tag () >
and maybe even a c block like
|make every sprite with tag () do|
Also if there is a clone block it will make the clone automatically have the same tag ( and costume and position and local variables) as the 'parent' sprite.
Umm... That might make it confusing, because tags are also search terms on the Scratch website.
Offline
That Is also a very good idea
Offline
Offline
efisher82 wrote:
joefarebrother wrote:
i agree but i don't think they should be called classes. I think they should be called tags, and maybe there can be blocks like
|tag [sprite 1 v] with ()|
that would assign a tag to a sprite,
|remove tag for [sprite 1 v]|
and
(my tag)
and the ([] of [sprite 1]) block will have another category: tag. Also there will be blocks like
<touching sprite with tag () >
and maybe even a c block like
|make every sprite with tag () do|
Also if there is a clone block it will make the clone automatically have the same tag ( and costume and position and local variables) as the 'parent' sprite.Umm... That might make it confusing, because tags are also search terms on the Scratch website.
Or maybe it could be called "labels" then.
Offline
joefarebrother wrote:
efisher82 wrote:
joefarebrother wrote:
i agree but i don't think they should be called classes. I think they should be called tags, and maybe there can be blocks like
|tag [sprite 1 v] with ()|
that would assign a tag to a sprite,
|remove tag for [sprite 1 v]|
and
(my tag)
and the ([] of [sprite 1]) block will have another category: tag. Also there will be blocks like
<touching sprite with tag () >
and maybe even a c block like
|make every sprite with tag () do|
Also if there is a clone block it will make the clone automatically have the same tag ( and costume and position and local variables) as the 'parent' sprite.Umm... That might make it confusing, because tags are also search terms on the Scratch website.
Or maybe it could be called "labels" then.
Yes... That would be better.
Offline
I am currently making a mod that will support this, (OOP Blocks), which will support this. I agree that OOP is not for beginners. It would probably be best to leave it out of Scratch, to avoid confusing beginners.
Offline
Maybe instead of having to right-click on it, there would be two more blocks (probably in control), saying 'add me to class' and 'delete me from class'. That way, you could only have it in the class for some the game. Other than that, I support!
Offline
Zparx wrote:
LS97 wrote:
Yeah, but then Scratch would become a full OOP, and more confusing for beginners.
What do you mean? I don't think that adding classes is that confusing. I just explained it to where a 3-year old would understand it. I mean if they don't add it in scratch, then byob or panther should give it a shot at least
![]()
Sorry, I misunderstood your topic. I thought you meant the kind of classes you get in OOP (object-oriented programming): where you can make new versions of the classes during run time, etc.
This is actually a pretty good idea. Faced with this problem, I found myself having to use colors for sensing instead. Stencyl, an advanced block language inspired by Scratch, has this feature and they call them groups (if I'm not mistaken).
Maybe we could adopt that name? Classes does sound confusing for people used to OOP.
Offline
LS97 wrote:
Stencyl, an advanced block language inspired by Scratch, has this feature and they call them groups (if I'm not mistaken).
where could I find this "Stencyl" language?
that would be awesome. do you support my idea? (:
Offline
Zparx wrote:
LS97 wrote:
Stencyl, an advanced block language inspired by Scratch, has this feature and they call them groups (if I'm not mistaken).
where could I find this "Stencyl" language?
that would be awesome. do you support my idea? (:
http://www.stencyl.com/
Offline