I'm working on a game where enemies should randomly spawn heading in 1 of 4 directions…there can be up to three onscreen at a time in any one direction…each enemy is its own sprite and not a clone of a master sprite…

my first attempt had broadcasts activating each enemy when the random conditions for spawning were met but it was REALLY laggy. I asked a question about the lag and it was suggested that the use of the broadcasts to start basically everything was less efficient than forever scripts checking for variable values to start motions or what have you…

I'm reworking it to use forever scripts to see, but I'm still experiencing some fearsome lag, so as a general question:

Which uses more resources, a lot of broadcasting to start scripts running or an equivalent amount of forever scripts checking for variable values to start scripts?

the project is here if you'd like to see what I'm specifically talking about Tesseract…the sprites that I'm currently working w/ are the control sprite (yellow ball) and the yellow and red angular ships (#'s 22,26,32-41)

EDIT: think I solved the lag issue, but I'm still curious about the answer.

If you're using broadcasts only possibly several times a second, then it's really not going to cause lag. Maybe if you end up doing lots (dozens? a hundred?) every second it could - not tested that far…

It does also depend on how many sprites (i.e. including clones) there are receiving those broadcasts. If you've (maybe unknowingly) got lots of clones, and all of them act upon receiving a broadcast, then it could cause problems.

That is one thing to watch out for, actually: all clones act independently with the same scripts, so if you have a sprite that receives a broadcast and then possibly spawns a clone, remember that all its clones will also do that when they next receive that broadcast - unless you specifically put in a local var that tells you whether a script is running as the original sprite or as a clone (and better still, has a different value for each clone, so you can identify *which* clone it is). You can then ensure only your original does the clone spawn (or at least make sure it's only the particular chosen clones that do it, not all of them).

I'm curious to know what was the source of your lag problem?

It was ultimately a clone issue. Each clone was receiving a broadcast to hide. I figured (wrongly) that having only the one command shouldn't affect processing speed, but as soon as I added the delete clone block (the clones were all missiles which were effectively disposable anyway once they either hit something or missed something), the lag disappeared.

It was your suggestion in my other topic that led me to investigate that side of things while I was pondering the broadcast vs. forever issue, so thanx for pointing me in the right direction.

As a general rule I prefer the broadcasts to start scripts rather than the forever scripts, so I'm glad to see at least for now either seems to work fine.

Glad to hear that you sorted your lag problem out. As for your original question, I would vote broadcasts as the better option. That's what they're for, after all! Not only is a forever loop rather sloppy, but it's an operation that's carried out as long as your project is executing - that's a rather unnecessary load.

My assumption about broadcasts was the same…a one time message sent to begin a sequence of events would seem to use way fewer resources than dozens of scripts always running even when they don't need to.

I've been thinking about the broadcasts we have in “InterXeptor 3D” - much of the main control loop does its job by sending broadcasts all over the place to get other sprites/clones to do their work. It even uses broadcast-and-wait (because it really can't have certain things going in the wrong order…)

Long version:
The main loop has five (sometimes six) broadcasts, some of which are received by multiple sprites (and in one case by about 10 clones). A couple of those sprites also go on to broadcast a few things to get other work started. This all happens several times per second.

Let's say we get 6fps on a half-decent machine. That works out at about 60 broadcasts per second, and about 150 scripts receiving (in different sprites/clones) and acting upon them per second.

Given that the bulk of the work it does is rather more intensive stuff (3D calculations, changing lots of entries in lists, rendering filled surfaces with changes to the pen to give gradient effects, etc.), I'd say the broadcasts/receives are pretty much insignificant in the overall timing.

So, I'd confidently say you could do at least 100 broadcasts per second (and probably more than one script receiving each) without any significant degradation in performance.

Short version:
Stick with broadcasts.