Animation and Movement

IMPORTANT: Make sure you have no scripts in the scriptorium for the object 2 1 10000. If you have you should either change all references to 2 1 10000 in the tutorial to some other classifier that is free, or remove the scripts. Viewing and removing scripts can be achieved using the CyberLife CAOS Tool or any other tool that allows DDE communication and script injection. Refer to the author of that tool for instructions.

With the CAOS tool you can check the scriptorium by opening the scriptorium viewer from the 'view' menu. Wait for it to load and then open up the tree structure and go down the path for family 2, genus 1. If you can see an entry for species 10000 then you need to remove the scripts for it - if not you are clear to proceed!

In the previous tutorials I sneaked some movement commands in and hoped you wouldn't notice - namely mvto, velx and vely.

mvto is fairly straightforward and MoVes the object TO a certain co-ordinate location. The world of Albia is 8352 pixels wide by 2400 pixels high, and 0,0 is the position in the top left corner (it's just above the Desert Island and the palm tree). This command will be mainly used when newly created objects need to be put into the world somewhere.

velx and vely are how you give an object some velocity - velocity is a constant movement that will take place even when the object is not running an event script. In the case of the ball in tutorial 2 the velocity was given in an event script, but the ball carried on moving even when the script had finished running. Velocity is given as a pixels per tick value - with negative X values being towards the left and negative Y values being towards the top of the screen.

Lets start by recreating our friend pitz again, use the chunk below to create him:

inst

new: simp pitz 200 0 9000 0

setv cls2 2 1 10000

setv attr 4

bhvr 3 0

mvto 4856 432

sys: camt

Have a look at this chunk, you should be in a position where you know what this all means. Notice that this Time pitz does not respond to gravity or boundaries - only activations, and is set up with toggle behaviour.

Now we'll add some event scripts:

scrp 2 1 10000 1

setv velx -2

endm

 

scrp 2 1 10000 0

setv velx 0

endm

Inject these and click once on pitz - he should start to slowly move to the left. Click him again and he'll stop moving. Because pitz was created to ignore gravity and boundaries he can actually pass through any wall he comes to - but more importantly the velocity given to him will not degrade due to air resistance or gravity.

Try changing his attributes so that he now responds to gravity and boundaries (attr +192) - and click on him again. He'll fall out of the sky and stop moving. Click him a few more times and you'll see that for each click that corresponds to an activate 1 he only moves very slightly and not in the manner he moved when he had different attributes. The reasons for this are two fold; now that gravity is affecting pitz his velocity is atrophied due to air resistance (aero) and also because he is on the floor and has gravity he will need a Y velocity to break free from the surface.

You can counter this by changing the activate script to give some Y velocity, but also more X velocity to counter the drag.

scrp 2 1 10000 1

setv velx -20

setv vely -20

endm

Now whenever an activate 1 click is detected pitz will hop along the floor.

The other form of movement an object can use is mvby which is a relative movement for a certain number of pixels. This kind of movement is not affected by gravity or boundaries so care must be taken when using it.

Try changing the activate 1 script to the following:

scrp 2 1 10000 1

reps 5

mvby -5 0

repe

endm

Now when you click on pitz he will move a set distance (5 pixels x 5 repetitions = 25 total) and possibly go through the ground - click him again to run the deactivate script and if he was partially through the ground he will spring to the surface. If you put pitz in edit mode and place him in the sky you should notice that an activate will not cause him to fall - it just causes movement. The deactivate though will make him fall - this is because using velocity for movement (in this case velx 0) will cause gravity bound objects to obey gravity ... mvby does not.

That's really it for movement, but be aware that the amount of velocity an object will need to move it around will obviously vary depending on it's accg and aero attributes ... something that loses a lot of sideways velocity due to wind resistance will need a lot velocity to move any significant distance.

Now we can move onto animation and you've already been introduced to the pose command which causes an object to change it's appearance. This is probably a good time to remind yourself that two of the numbers you used in creating the object specified some of the set up parameters for the images owned by the object. In the case of pitz the line new: simp pitz 200 0 9000 0 says that the images should come from the sprite file named 'pitz', and that 200 images should be used starting at image number 0 in that sprite file. If you open up the pitz sprite file you should see that there are only 200 images ranging from image 0 to image 199, but in other case you might only want a subset of the images within a file and these 2 numbers will enable you to specify which.

The pose command is not referring to the image number within the sprite file but rather the image number of the images specified for this agent, and this is an important distinction. For example, if we were to give the pitz we've got in the world at the moment the command pose 130 he would roll onto his back. Now create a different pitz using the chunk below:

inst

new: simp pitz 170 30 9000 0

setv cls2 2 1 10000

setv attr 4

bhvr 1 0

mvto 4856 432

... and then give this one a pose 130 command. You should find that it sits and begs - a totally different pose than the other pitz's pose 130. This is because when created it we said it had 170 images starting at number 30 in the file.

So now you know about how to change the static image something displays, we can move onto animation. We'll use the pitz just generated in the example above for this part - delete any others that exist and get this pitz back into pose 0. The main command for performing animation is the anim command.

anim takes a series of integers after it to specify the images to use, for example - create a new activate 1 script for pitz that reads:

scrp 2 1 10000 1

anim [0123456789]

setv actv 0

endm

Inject it and click on pitz.

You should see pitz flick his head and turn around. This command has effectively said 'play pose 0, then pose 1, then pose 2, ......, then pose 9'. And if you look at the sprite file you will see that the movements pitz takes corresponds to sprite file image numbers 30-39.

anim only works with single digit pose commands which at first sight looks like we'll never be able to get pitz to roll on his back - these images are numbers 126-133 within the sprite file and numbers 96-103 within pitz's personal image gallery (remember this pitz's images start at 30 in the sprite file). There is a way to do this and it involves the base command.

base is a way of moving the start point of animations so that you can animate frames higher than 10, and you use base by giving it a frame number which it will then refer to as frame 0. For example, if we now change the activate 1 script to read:

scrp 2 1 10000 1

base 96

anim [01234567]

setv actv 0

endm

You should find that pitz now rolls onto his back and waggles his legs around.

Great care must be taken when using base because now all references to pose 0 are actually referring to the new pose 0, which corresponds to base 0 pose 96. If you use the base command in your scripts it is a very good practice to always use them in front of a pose or anim command - and in that way you will never make the mistake of forgetting where your base pointer is positioned. Trying to access an image that is beyond the size of your objects image gallery is a bad thing to do!! You have been warned. For example, if we kept the current activate 1 script for pitz and added a deactivate that said pose 130 - when the deactivation was run it is possible that that will cause a serious error because base has been changed to 96, so pose 130 from base 96 is actually absolute image number 226 ... which doesn't exist. The proper thing to do would be to change the deactivate script to read base 0 pose 130.

So you now know how to static pose, animate once and shift the base image pointer around - lets move onto continuous animation and uninterrupted animation. We'll keep our current pitz but change the activate script to:

scrp 2 1 10000 1

base 10

anim [01234567R]

setv actv 0

endm

Notice the 'R' at the end of the anim string - this means that the animation will keep on looping until told otherwise. Inject it, click on pitz and watch him animate. If you click on him again you'll notice that the animation will flip to the first pose and start to cycle again. In this way you can trigger an animation that you want to keep looping until you change it to something else.

Now lets change the activate again to:

scrp 2 1 10000 1

base 10

anim [01234567R]

base 18

anim [01234567R]

setv actv 0

endm

and watch what happens when pitz is clicked on. He very briefly faces left but then turns right and runs in that direction. This is because the first anim command was superseded by the one following, it doesn't mean that it will do one anim and then the other. The way to achieve this is to use the over command.

Change the script to read:

scrp 2 1 10000 1

base 10

anim [01234567]

over

base 18

anim [01234567R]

setv actv 0

endm

NOTE: the first anim strings does not end in 'R' this time. I'll explain why in a moment.

Click on pitz and watch how he performs now - he'll do one run loop to the left and then switch to the right and repeatedly run. This is because the over command causes the script execution to pause until any animation specified has finished ... in this case the base 10 anim [01234567] ... before carrying on with any other commands in the script.

The warning for making sure that you did not include the 'R' in the anim this time should be obvious now you know what over does - over waits for the animation to finish and anim [01234567R] will carry on for ever, not a good combination to include together! This would result in the script never getting past the over and quite possibly locking up creatures2.