Scratch

What do you mean by velocity?
This?

Think of it this way.. the screen has 2 dimensions. Either left and right (or X) or up and down (or Y). So to move something in any direction, you just move it in one or usually both of those directions at once.

For example...
Changing a sprite's X by 1 will move something straight right (aka directionally as 90)
So changing the same sprite's X by -1 does the opposite and moves it straight left (-90)

The same thing works for changing Y except a positive change moves the sprite up (0) while a negative value moves the sprite down (180)

So that covers straight movement in all four directions. If we want to move in a diagonal path as we often do, we simply adjust both the X and Y values.

So...
change X by -1 change Y by 1 moves the sprite Northwest
change X by 1 change Y by -1 moves the sprite Southeast
change X by -1 change Y by -1 moves the sprite Southwest
change X by 1 change Y by 1 moves the sprite Northeast

Now we've done movement both straight, and on perfect 45º angles. What if we want a diagonal but not on a perfect 45º? No problem!

We know X +1 and Y+1 together go Northeast. To change the slope of the line, use different values for X and Y. For example X+1 and Y+3 creates a line that will angle up more while still going Northeast.
Likewise x+3 and Y+1 together still yield a Northeast diagonal but now the line will slope downward.

In scratch, almost any kind of ArtificialIntelligence or movement control, whether for the player, moving objects, or monsters, not only needs to know when and how to act but usually these instructions must be copied and altered slightly depending on which of 4 directions a sprite is moving in. A classic example is Pong on Scratch where Scratch's unique system of X,Y coordinate numbering makes ball reflections off of side walls figure angles completely different than reflections off of top and bottom walls.

a project to demo just the bounce
the actual game player vs cpu

Anyway, the only thing left besides oscillating or programed moves is doing curves. Which in sense, brings us right back to where we started all this. But first, the explanation of how.
To move on a curve, you need to think of at least 3 or more changes in a sprites X and Y values. Here is an example...
X+1 Y+0 = move once straight right
X+1 Y+1 = move Northeast
x+0 Y+1 = move up

Now this may not seem like much of a curve but really it is as simple of a curve as you can make. If you did it in 2 changes, it would just be a turn. Like wise if you did it in 50 changes, it would be a beautifully smooth curve. Hence the concept that all curves are simply a succession of straight lines.

This is what makes velocity awesome. The entire system is simply a construct that once made, handles doing all that crazy, cool, smooth motion for you. The things that actually change the X and Y values (aka scrollX and scrollY) are things like the player jumping, or applying thrust, or gravity pulling any object downward that is not on a floor.

Gravity- a simple, short script that says If not on ground, change Y by some usually small amount. Look at Harakou's script, "change velocity by -.3" The reason we use small amounts is because every change to X or Y is cumulative. So if "velocity" in Harakou's script was being used for gravity, every time the script looped and the sprite wasn't on the floor, it would fall as fast as the last loop plus an additional -.3 X

It doesn't take long to see where this is going. Often times when using velocity type variables, you must include a short script block that says something like If right arrow key pressed AND scrollY < (whatever your maximum speed needs to be) change scrollY by.3 This sets a maximum speed for your sprite, very important.

You will also often find that your velocity scripts will interact. For example, once you have a working Gravity script, all your jump script needs to do is just get the sprite to the jump. After that, the Gravity script will take over and handle falling, with style! Your jump script might say change Y by +30 if sprite touching ground. So as soon as the player hits the key, the sprite rockets upward. After it jumps Y+30, it doesn't just lose it's momentum because scrollY never gets reset to 0, it only increases or decreases forever. Same for scrollY of course. Anyway, just like I mentioned, after the jump Y+30 the sprite does still have all that momentum to go up but now that it is not touching the floor, gravity kicks in. Of course, our gravity was a constant -.3 Y which is only 1% as strong as the mighty jump Y+30 BUT our jump Y+30 only got applied once. Gravity is going to accumulate every game cycle. Visually, this creates the much more natural jumping effect where a sprite shoots upwards, slows at it reaches the top of its jump, then slowly begins to fall in a speed that increases the longer it falls.

Thrust is pretty simple, when key pressed change X (or Y) by whatever amount. It is like a Jump script except that it doesn't check to see if the sprite was touching the ground first. So you can see why a jump scrip doesn't need to check to make sure the player hasn't exceeded some "maximum jumping speed" whereas a thrust script obviously must always have some upper speed limit and lower limit as well if negative movement or backing up is allowed.

Here is my asteroids type project (top down scrolling space shooter) that uses this thrust/velocity concept in a 2 directional scrollX environment. This project also contains my solution for creating thrust in any given direction depending on which way the player's ship is pointing.

my Asteroids movement demo

Ok, I've rambled enough. Anyway, that is what I have been doing is learning how Scratch handles all this stuff thanks to a lot of spare time and the awesomely brilliant peeps around these forums. All my little mini projects are paying off because now I can work on a big project involving weird, complex scripts without getting completely lost. Plus, stuff like scrollX and velocity can be tricky to explain or read from text. It is so much cooler to go "Ok, when I changed that and that I saw it do that... which is wrong but now I see what will make it work!" And I still have those moments when I just start flipping operator signs while praying that it fixes some complex motion control script instead of just breaking it more 

Last edited by Locomule (2010-07-14 12:33:42)

melikecheese wrote:

What do you mean by velocity?
This?

Yes and No.
What I mean is that it answered it very well indeed.
But, I need it to fall without jumping.

*******************************************************************************************************************

I'm making an adventure course game.
There will be lots of platforms and when you run to the end of them, you drop realisticly to the next lower platform.

(I know how to jump to the next platform realtistly thanks to your reccomendation, thanks    )

Yeah, I got crazy with the cheeze whiz but that would be in my post under the part about Gravity 

ps.. I make crazy posts like this not just for the op but for years worth of future Scratchers who are just learning this stuff. I also made a cool little demo that uses velocity as well as a sort of gravity (it just slows the skull, doesn't make it fall down) here...
get Skull Toss here

Locomule wrote:

Yeah, I got crazy with the cheeze whiz but that would be in my post under the part about Gravity 

ps.. I make crazy posts like this not just for the op but for years worth of future Scratchers who are just learning this stuff. I also made a cool little demo that uses velocity as well as a sort of gravity (it just slows the skull, doesn't make it fall down) here...
get Skull Toss here

Great game and thanks for just uploading it for me.
If you made it 20mins ago just for me, thanks even more!!