Scratch

AlveK,
Like Paddle2, I don't know what the inner workings are doing, but from other forum posts I've gathered that statements like "wait until (somevariable > 0)" don't hog resources.  There is some debate about whether a forever loop that is constantly churning along should have a "wait 0.1" in it to free up resources.  I sometimes use these "little waits", but not always.

I've done two player games where both players are active and using the keyboard, their sprites are in motion, and two missiles could be flying; for motion, I don't put the wait statements in.  Scratch doesn't seem to mind, so it must be able to manage giving up some time to handle other tasks.

You can avoid "waiting" by using a broadcast to start a script (which is what you are suggesting with "Start Script 2 in Catsprite").  Broadcasts are "heard" by all sprites/scripts, but only the scripts that begin with "When I Receive" will respond to the broadcast.  I've been using broadcasts more in my projects, and when the script has done its job, putting a "stop script" in.  This way, the script isn't doing anything until it gets another broadcast to start it.
If you have a specific project you'd like ideas with, post a link.  I'd be willing (as I'm sure others would be) to see if I can offer any advice.

-MrEd

Last edited by EdnaC (2008-01-08 10:42:30)

I guess I was thinking of a specific instance for the "Stop Script";  You don't need the "Stop Script" if the script will "run-out" on its own.  Maybe I'm stuck on this "Style" of Scratch programming at the moment.  It seems like my approach to Scratch changes from project to project.  Not sure if my style is evolving (in the getting better sense of the term), or whether I'm just having fun experimenting with different approaches ( I think its the latter).

In fact, I hadn't done anything other than a couple of demos until I learned that the new version lets you "sense" the value of another sprite's variables.  (I'd gotten kind of fed up with keeping track of variables in the "variable pane" of big projects.)   This new feature, and a demo I did, led to a new idea that got me excited about Scratching again:

My latest project is a turn based "3d" projectile game, and I find that I'm using a lot of forever loops that "Broadcast and wait".  The master sprite that will coordinate the game has a forever loop that will broadcast a "Start your Turn" message and wait (a long time) until the chosen player's turn ends. 

The projectile has a forever loop that keeps "broadcasting and waiting" to get updates on where to go and to check for collisions.  The projectile is "driven" by the "elevation view" (side view) and tracked in the "plan view" (top down)  If the projectile is high enough, it sets a variable to let the checking sprite know that collisions aren't possible.  This stops the checking sprite's script before all of the other checks happen (since they aren't needed).

Forever
(do some projectile type stuff)
   If (ElevationView.collisionpossible = 0)
   Stop Script
If <touching building1>
   Set (touchingbuilding = 1)
   Stop Script
If <touching etc.>

Lots more checks have to be made, but the script "bails out" as soon as it can to give control back to the ElevationView.  Back in the ElevationView, a move is made to keep in sync with the PlanView, and then it's time to check for collisions there.

-MrEd

http://scratch.mit.edu/projects/AlveKatt/75081

This is the project that prompted me to make this topic. (There is an offline version I have yet to upload with some bugs fixed, like the one where you get stuck a few seconds  when you start the rescue op. Also, some functions doesn't seem to work in the online version, the island near the victim is supposed to be enlarged during the rescue op.)