This is a read-only archive of the old Scratch 1.x Forums.
Try searching the current Scratch discussion forums.
  • Index
  •  » Advanced Topics
  •  » Multiple sprites calling same script - Semiphores or thread blocking?

#1 2007-05-21 02:00:43

Roberth
Scratcher
Registered: 2007-05-15
Posts: 46

Multiple sprites calling same script - Semiphores or thread blocking?

I have a broadcast message that is being used in an "end of game" situation, where multiple sprites each in turn attempt to invoke a "function" that is a single script located elsewhere.  This script is complex enough that merely copying it into each sprite won't work.  I'm using global variables to set parameters and having another variable returning the result of this "function", through the use of the "Broadcast <message> and wait" block.

The behavior (and it should be expected to be this way... no bug on the Scratch development crew here) that every sprite which sets the global variables, and the last spite wins the contest over what values are processed by this "function" script.

What I'm looking for is something that may temporarily block each sprite that would allow them to process the "function" one at a time.  Any ideas, or is this simply something that Scratch isn't quite ready to cope with yet?

I've seen some incredible things written, in spite of some significant limitations.  There might just be a solution to this that I'm overlooking.

Offline

 

#2 2007-05-21 11:37:56

ernestpazera
Scratcher
Registered: 2007-05-16
Posts: 5

Re: Multiple sprites calling same script - Semiphores or thread blocking?

Have you considered making a "Stack Sprite"?

Offline

 

#3 2007-05-21 13:14:00

kevin_karplus
Scratcher
Registered: 2007-04-27
Posts: 1000+

Re: Multiple sprites calling same script - Semiphores or thread blocking?

When you need to have several sprites with scripts, but only one active at time, one way is to use a separate whose-turn? global variable, and have each sprite have

when I receive <message>
     if whose-turn? = 1
         body

with a different whose-turn? value for each sprite.  You can see this in use in my polyphonic-piano with arrows:
http://scratch.mit.edu/projects/kevin_karplus/2160

Offline

 

#4 2007-05-21 17:00:53

Roberth
Scratcher
Registered: 2007-05-15
Posts: 46

Re: Multiple sprites calling same script - Semiphores or thread blocking?

Thanks for the idea, Kevin.  I actualy came up with something a little more unconventional, which was a thread blocker of sorts:

When Green Flag clicked
Set Count to 0
Set Thread Order to 1

When I receive <Thread Block>
  Change Count by 1
  Wait until Count = Thread Order

--------

And then in the body of each script that uses this blocker:

When <event happens>
  Broadcast Thread Block and wait
  <body>
  Change Thread Order by 1

------

This seems to work quite well on some very simple examples, but I think I'm running into some message stack issues on more complex scripts that have multiple broadcast messages inside.  The secondary broadcast messages seem to get hung up and act in weird manners, where the "Wait until" block seems to leak somewhat and doesn't wait in all cases.  Perhaps this is somewhat related to the recursion issue mention in this thread:

http://scratch.mit.edu/forums/viewtopic.php?id=206

I'll try something a bit different, along the lines you are suggesting instead.

The "game" that I'm developing using this idea (not quite ready for prime-time, but it shows the potential) can be found here with my "Minesweeper" game:

http://scratch.mit.edu/projects/Roberth/5721

I'm going to see if I can try something along the line of what you are saying here Kevin and see if I can get this to work.  BTW, this uses a 2-D array modeled after your Simon example, but with a different method of "hiding" the data.

Offline

 

#5 2007-05-22 00:00:06

kevin_karplus
Scratcher
Registered: 2007-04-27
Posts: 1000+

Re: Multiple sprites calling same script - Semiphores or thread blocking?

The problem is that Scratch does not have any sort of "atomic" control structure that prevents another script from being scheduled in the middle.  If it did you could implement semaphores for mutual exclusion as you were trying to do.  Without any sort of atomic test-and-change operator, you will always have the possibility of things happening in the middle of your attempts to change things.

Offline

 

#6 2007-05-23 21:40:08

Roberth
Scratcher
Registered: 2007-05-15
Posts: 46

Re: Multiple sprites calling same script - Semiphores or thread blocking?

I want to thank you for your suggestions here, Kevin.  I got my project to more or less work as I want to, but I will say that all of this back "counting" and broadcasting makes my Minesweeper game incredibly SLOW.  I'm trying to do a little bit of optimizing to try and improve the performance throughput, but the sheer size of this project is pushing the limits of Scratch.

I currently have 93 sprites, 460 scripts, 461 variables, 1084 "costumes" and images, and I can't count how many blocks, but it is many pages on the scripting area.  Saving and loading this script takes quite a bit of time and pushes the limits of Scratch... even though the actual footprint in terms of server space and HD size is comparatively small.  It is only 600 KB.

In terms of a good test for performance issues with scratch, I would have to say this is the program to use.

I'm still not done with this in terms of adding in code for randomly adding "mines", or trying to further obscure the mine location data with a couple of other techniques, but this does give a good feel for how a scratch-based minesweeper game would work.

Offline

 
  • Index
  •  » Advanced Topics
  •  » Multiple sprites calling same script - Semiphores or thread blocking?

Board footer