Ok, so i've noticed that a lot of good projects have (in general) a small amount of scripts. IE: Archmage's SSBB Movement project (http://scratch.mit.edu/projects/archmage/331446). Good movement and graphics, and all using only a couple scripts for Mario. My question is: why have one huge script instead of multiple little ones? The reason i ask is because for one sprite in a game i'm making, i have at least 8 scripts(as many as there are in Archmage's whole project) for movement/attacks. Personally, I think the best part of Scratch is it's open-source ish learning style. If you see something you wanna learn to do, you can download the project and see how the user did it. I feel like when there's one huge script (with a jillion if statements and variables) it's WAY harder to learn from. Just wondering if it really makes all that much of a difference, or if there's some things I'm missing?
Offline
When you have a lot of scripts, it really slows the game down online. That's why people aim to use less scripts whenever possible.
Offline
In general, fewer scripts results in a project that runs more smoothly. Not only does processing many scripts at the same time slow Scratch down, but it makes organization very hard. (A lot of people also see making complex projects with as few scripts as possible, especially with just one script, as a challenge and a mark of skill.) So yes, it's better to use fewer scripts when possible.
Offline
Its not about how many scripts its about the quality of scripts.
Programs with a large script or many small scripts run the same.
When I code I use as many scripts as needed and make them as efficient as possible while still being organized.
Each scripts that plays a specific role should be separate and easy to identify. One of the worst things you can make in to a habit is making 1sprite 1 script programs which any professional programmer can tell you makes code much more difficult to work with.
In your case specifically, if you have multiple scripts for 1 main function then you are doing it wrong. In the example you posted, mario's scripts have to main catagories, movement/input and animations.
Also, I know that project is kind of hard to follow, I tried to copy SSB's exact number of different animations which was over 15, for a more simple and straightforward example try my scrolling platformer template.
Offline
archmage wrote:
Each scripts that plays a specific role should be separate and easy to identify. One of the worst things you can make in to a habit is making 1sprite 1 script programs which any professional programmer can tell you makes code much more difficult to work with.
That's why you separate the script into different 'processes', which will each only run after the previous process has completed. I've developed a system which allows you to create 1s1s projects which actually have several scripts, but doesn't have any of the lag normally associated with broadcasts or loops when starting another process.
Example
Offline
Yeah, in the case of that project you could have made the scripts over 50% shorter if you used the appropriate number of scripts and sprites and had enough experience to code properly in general.
Now in most cases for scratch it doesn't make a huge difference what you do with scripts and sprites because the projects are so small scale. In larger professional projects all scripts are split in to separate files and strictly organized. This lack of organization is one of the reasons that people fail when making larger projects.
Offline
Good organized code is better. That often means more scripts, since you should have different things separated. Of course there are workaround to make it into one, but that just increases clumsiness of the code.
You also do not need to care too much about "performance cost" of more scripts - after all, one huge or more little script runs basically the same, and in flash player the projects run really smoothly.
For bigger projects, good structure (even at the "cost" of more scripts) is definitely a plus. Do not mix "more scripts" with "more complex code", well organized code means simple, lean code; this may in turn lead to fewer (but more powerful) code, though reuse is fairly limited in Scratch.
Offline
This is a hard one, as probably mentioned above, the fewer scripts you use the smoother the project runs. It also makes your project run a lot faster, people can also see it a challenge to use as few scripts or sprites as possible. My games usually have an average of about 850 scripts but most of them weren't recuring/repeating so it still ran normally.
Offline
Alrighty, valuable information from everybody. Basically what I'm hearing is that the larger scripts essentially do the same thing as all the smaller scripts together, but you basically just combine all of the smaller ones into the bigger one? Assuming, of course, that the smaller ones are as small as possible so that the larger isn't too horribly massive.
If I'm totally off, (which I probably am) that would be a great thing to know. If not, what are some good ways to combine scripts that involve input from teh keyboard? (IE, when right arrow key pressed, move X steps).
Thanks
Offline
Not exactly. Remember that Scratch "interleaves" parallel scripts so that they run at the same time. Depending on your scripts, stacking them in one script vs breaking them up will yield different results. Usually scripts activated by a given event for one sprite (eg Green flag clicked) are all grouped together under one hat block in that sprite's script, but this isn't always the case, as the others here have described.
Offline