Now comes the main script. The script system is in fact a multi-threaded system. It allows for up to MaxPaths (10) threads at once. This allows for 1 MasterPath and 9 baddies. The master path is invisible and controls the whole flow of the level. It starts sprites, waits for level points and controls everything.

The MasterPath then spawns off new sprites as the level progresses, each of these sprites becomes its own thread and has exactly the same commands as the master path which means it too can then spawn sprites and control things.

Some sprite commands are free while some cost a cycle. When the total cost of a command is 1, the thread pauses until the next game frame. Sprite movement usually costs 1 while things like animation and state setting are usually free.

Example: create a very simple chain of sprites for the user to shoot.

First we set the BoomPath (death explosion):

We then wait for the 4th character to scroll on. This is like doing a Pause 4*4:

After the level has started scrolling, and we’ve waited for a bit, we now want to bring on some baddies. We do this by starting a new sprite just off screen. We use Hires cords for the sprite but the system will only display the sprite on MCM coordinates.

So to start a new alien, we use the Start script command.

This will start alien Baddie1 at 330,70 and sets the flag KillClip on this alien. The flag KillClip means that once the alien is on screen, it will be automatically killed off (freed) when it leaves the screen. This avoids us having to keep to close a watch on the alien, and allows us to go fairly complex paths and worrying about the sprite slot being hogged.

What this actually does is start a new thread running starting at the first command in the DemoPath1 script. Because the Start command costs 1 cycle, the MasterPath would now pause here until the next frame and then carry on. Which means we now need the master path to pause a while.

Now this will wait for 10 game cycles and then start another sprite off at the same location as the last. Of course The first sprite will have moved from there and progressed on through the DemoPath1. What this makes is a chain of sprites, one following after another. Adding more of these would create a larger chain of sprites (up to 9).

We could carry on like this adding a Pause then a Start over and over, but this wastes memory and isn’t very nice to edit. Instead, we can use loops. Lets do these first few lines again, this time using loops.

Now that we’ve managed to start 6 sprite, we need a script for each of them to follow. Lets start with a simple one, we’ll use LOOP’s to pack it down a bit better.

As you can see from this very simple path, the sprites move into the screen, move down, and then move back off the screen. Kind of like a U on its side. We could remove the loops and add lots of Move commands, but that’s just a waste of space.

Move moves from the current coordinate by this amount, regardless of where it is. This makes it a great command use for relocatable paths, that is you can use the same path at any location on the screen and it’ll work as normal. Other commands such as MoveTo are fixed to the screen and are useful for a Boss or other such baddie that is unique since you can plan it out better and don’t care if its not used again.
Because of the KillClip flag, we could do this….

This would move the sprite to the left until it had moved off the left hand edge of the screen. The script system would then kill the sprite itself and free up the thread.

The BoomPath (needed for when the aliens are shot by the player) looks like this:

This is a simple delay really. It clears any Drift (used in commands like Circle) and then sets the animation to the explosion. It then just waits for the animation to finish, and kills the sprite when it’s done.