Scratch

Twinheart · 2011-06-23 21:59:06

Greeting to all who read,
This is Twinheart, and I would like to propose the idea of having ScrollX and ScrollY Preset in Scratch Ver. 2.0, that way, we can build side-scrollers more easily. I am just curious as to what others believe. Thank you for your time.

Jonathanpb · 2011-06-24 02:24:14

Shouldn't people have to program scrolling themselves instead of having it done for them? hmm Scrolling wouldn't be as special if the variables were pre-programmed.

Anyway, having them pre-programmed would make it very hard to 'edit' the scroll to get it just how you want tongue

Last edited by Jonathanpb (2011-06-24 02:24:20)

LS97 · 2011-06-24 03:37:53

I agree with Jon.

That's a downer for Stencyl, too. It's all there for you and there's little customizability to the code. I think you're better off with programming it yourself the (questionably) harder way.

UltimateE-HeroNeos · 2011-06-24 05:12:15

No Velocity Scrolling! D:

Harakou · 2011-06-24 11:26:57

I have to agree with Jon and LS97 here. Having pre-crafted scripts to do things takes away what makes them so great in the first place, and makes them very hard to customize. Even worse is that people that use them will never understand how it actually works and never progress on to better ways of doing it.

archmage · 2011-06-24 14:00:38

Most lanagages made for these kinds of visual programs let you change the viewable area, usually camX and camY. I think Scratch should have this and give an option to get rid of the stupid restrictions on where a sprite can move to as well as these kinds of scrolling variables.

beeboo777 · 2011-06-24 18:33:01

It wouldn't be as versitaile then. It would have too many limits.

hmnwilson · 2011-06-24 18:57:00

I don't get how it would work. Isn't it basically the same as just making a variable? How would it know which sprites "scroll" and which don't, if they're not programmed to do so?

Trekkie210 · 2011-06-24 20:27:29

Man... c'mon! People should have to program themselves. If you do that you might as well just have it make the game for you. sad

archmage · 2011-06-25 15:18:51

hmnwilson wrote:
I don't get how it would work. Isn't it basically the same as just making a variable? How would it know which sprites "scroll" and which don't, if they're not programmed to do so?

No, in this case you would be changing a property of the stage, change the x of a stage and everything in the stage moves. This is more efficient and far easier than setting each sprite to move individually. I do think that the stage itself should have a full set of alterable properties like sprites do, so you could rotate, change colour, ghost, ect of everything on stage.

I really don't see any disadvantages.

Trekkie210 · 2011-06-25 15:55:14

archmage wrote:
hmnwilson wrote:
I don't get how it would work. Isn't it basically the same as just making a variable? How would it know which sprites "scroll" and which don't, if they're not programmed to do so?
No, in this case you would be changing a property of the stage, change the x of a stage and everything in the stage moves. This is more efficient and far easier than setting each sprite to move individually. I do think that the stage itself should have a full set of alterable properties like sprites do, so you could rotate, change colour, ghost, ect of everything on stage.

Aw, that would be SWEET! You could do transitions and make the screen shake; it would be awesome. BUT, I still don't like the idea of it being so simple. Hmmm. hmm

archmage · 2011-06-25 23:34:25

Simple is the only thing Scratch has going for it so why shouldn't it be simple? Things like scrolling that some people pride themselves on for being "advanced" should be simpler.

Twinheart · 2011-07-17 21:41:02

Jonathanpb wrote:
Shouldn't people have to program scrolling themselves instead of having it done for them? Scrolling wouldn't be as special if the variables were pre-programmed.

Anyway, having them pre-programmed would make it very hard to 'edit' the scroll to get it just how you want

Too True. I didn't think of it in that light. You're right.

jji7skyline · 2011-07-17 21:42:30

That would make it inflexible... lots of games don't need scrolling anyways.

Twinheart · 2011-07-17 21:45:03

"Things are heating up in this intense match!" - Announcer from Pokemon Stadium.

Anywho, I like the multiple opinions here. Many have good ideas, and others merely wish to show what they have to say. Kudos to all. You're all valid.

cpumaster930 · 2011-07-17 22:34:49

archmage wrote:
hmnwilson wrote:
I don't get how it would work. Isn't it basically the same as just making a variable? How would it know which sprites "scroll" and which don't, if they're not programmed to do so?
No, in this case you would be changing a property of the stage, change the x of a stage and everything in the stage moves. This is more efficient and far easier than setting each sprite to move individually. I do think that the stage itself should have a full set of alterable properties like sprites do, so you could rotate, change colour, ghost, ect of everything on stage.

I really don't see any disadvantages.

+1

In addition, there could be a camZoom function as well as camX and camY...if a game has more going on graphically it usually looks better...
Having a ton of forever loops going on at the same time for every sprite could cause some lag as well hmm

Thescratch3 · 2011-07-17 23:32:54

Having a scrollx and scrolly pre-programmed in version 2.0 would be an advantage:
I can never get scrolling to work out with me. It is like we never get along, he wants peanut butter I want vanilla, he wants Nike I want Addidas. Sorta like that.

Disadvantage: This will take away the brain thinking skills for programming and make you decrease in your ability to work things out, program well, etc. It will be like "Oh I can just use this! Simple!!"

So yea.

Twinheart · 2011-07-28 22:56:52

Thescratch3 wrote:
Having a scrollx and scrolly pre-programmed in version 2.0 would be an advantage:
I can never get scrolling to work out with me. It is like we never get along, he wants peanut butter I want vanilla, he wants Nike I want Addidas. Sorta like that.

Disadvantage: This will take away the brain thinking skills for programming and make you decrease in your ability to work things out, program well, etc. It will be like "Oh I can just use this! Simple!!"

So yea.

Hmm... A Pro and a Con. To give up thought process and that feel good emotion for convinence and assisting those who cannot make it work. It looks 50 / 50 here folks.

EdnaC · 2011-07-29 07:00:13

A big issue with scrolling projects is handling the actions of sprites that aren't on stage; You can't detect colors, collisions etc. for off-stage sprites with the Scratch tool set that exists today. I'm afraid that adding those tools would might make Scratch too much for new programmers. I'd be happy if the limitation of (not) letting sprites leave the stage was lifted.

Perhaps this could be a setting like the lock/unlock sprite dragging is (with the default being "stay on-stage")?

slinger · 2011-07-29 07:15:01

Twinheart wrote:
Greeting to all who read,
This is Twinheart, and I would like to propose the idea of having ScrollX and ScrollY Preset in Scratch Ver. 2.0, that way, we can build side-scrollers more easily. I am just curious as to what others believe. Thank you for your time.

Its a good idea for beginners but i like the fact that you can change the amount you can scroll by. Its more flexible as a variable.

Scratch

archived forums

#1 2011-06-23 21:59:06

ScrollX + ScrollY as "already existing" in ver 2.0

#2 2011-06-24 02:24:14

Re: ScrollX + ScrollY as "already existing" in ver 2.0

#3 2011-06-24 03:37:53

Re: ScrollX + ScrollY as "already existing" in ver 2.0

#4 2011-06-24 05:12:15

Re: ScrollX + ScrollY as "already existing" in ver 2.0

#5 2011-06-24 11:26:57

Re: ScrollX + ScrollY as "already existing" in ver 2.0

#6 2011-06-24 14:00:38

Re: ScrollX + ScrollY as "already existing" in ver 2.0

#7 2011-06-24 18:33:01

Re: ScrollX + ScrollY as "already existing" in ver 2.0

#8 2011-06-24 18:57:00

Re: ScrollX + ScrollY as "already existing" in ver 2.0

#9 2011-06-24 20:27:29

Re: ScrollX + ScrollY as "already existing" in ver 2.0

#10 2011-06-25 15:18:51

Re: ScrollX + ScrollY as "already existing" in ver 2.0

hmnwilson wrote:

#11 2011-06-25 15:55:14

Re: ScrollX + ScrollY as "already existing" in ver 2.0

archmage wrote:

hmnwilson wrote:

#12 2011-06-25 23:34:25

Re: ScrollX + ScrollY as "already existing" in ver 2.0

#13 2011-07-17 21:41:02

Re: ScrollX + ScrollY as "already existing" in ver 2.0

Jonathanpb wrote:

#14 2011-07-17 21:42:30

Re: ScrollX + ScrollY as "already existing" in ver 2.0

#15 2011-07-17 21:45:03

Re: ScrollX + ScrollY as "already existing" in ver 2.0

#16 2011-07-17 22:34:49

Re: ScrollX + ScrollY as "already existing" in ver 2.0

archmage wrote:

hmnwilson wrote:

#17 2011-07-17 23:32:54

Re: ScrollX + ScrollY as "already existing" in ver 2.0

#18 2011-07-28 22:56:52

Re: ScrollX + ScrollY as "already existing" in ver 2.0

Thescratch3 wrote:

#19 2011-07-29 07:00:13

Re: ScrollX + ScrollY as "already existing" in ver 2.0

#20 2011-07-29 07:15:01

Re: ScrollX + ScrollY as "already existing" in ver 2.0

Twinheart wrote:

Board footer