Velocity and Speed

Many a student will ask me how you make something move on screen through coding. I think that they are really asking me for the answer, but sadly I give them the lecture. It’s not hard but it is involved. Start off with your point particle (☺). It will represent an entire body. This is based on the fact that if you walk across the room, everything will come with you, hands arms, etc. So, we’ll merely look at you as a single point. Now, we can put you on a map:

Wow, that map looks oddly familiar … hmm. Okay, we are going to use a simple xy-graph. This type of graph is sometimes referred to as Cartesian. That just means all the axes are based on distance (length as in feet, meters, etc.), and that all the axes are perpendicular to each other (separated by 90 degrees.)

What are axes you ask? Well, they are just the lines created when we have zero distances in all direction except one. It’s actually simpler than that. In our system, you can see that when x is always forced to be 0, y can still be anything. This creates a line vertically. The same can be said for y=0.

Now that I’ve confused you with math philosophy, we’ll ground you with some simple facts. In a virtual reality, you are a point particle (smiley face), with no volume (or area.) We can always create that for you later. But you are in a room at some point. If you go and sit on the couch, you move to another place in the room. This can actually be drawn as follows:

See how we strategically placed the room against the axes. Now, your virtual ”you” is roaming xy-space. Whee! So why didn’t we give you a TV set. Well, you might run into it and then you’d get another lecture on collision detection. We can’t have that … yet. So instead, maybe if you are nice, we’ll draw you with an iPhone when we create your body.

Although, guess what? We technically still aren’t moving. To do that, we have to know a few things. Two important of these are where do you start from, and where do you go? So, let’s refine the map with some simple numbers:

Hmm, do you want to just estimate at this point, the two places that the virtual you will be? Sure, but the rules have to apply, your sprite still has no area or volume such that you start at (60,40) and end at the couch on (100, 90), or graphically:

Now that we have a beginning and end point, we can figure this out through some mathematics. We really should use some linear algebra and matrix theory in this case, but since many of you may not have taken that subject yet, and more importantly never want to (although you don’t know what you are missing,) we’ll simplify. We can do this because we aren’t actually in 3D yet. We are moving a point/smiley face across a flat surface, the page in this case.

So, we are going to break out a hopefully familiar formula and break things into components. We’ll do the latter first. The term component relates to the fact that we will only handle the x- and the y- values one at a time. Why try to play with them all at once? Just think how tough that’d be in three dimensions. So when we look at our smiley, we see that he’s moved 40 units in the x-direction and 50 units in the y-direction., from the following equations:

_{}

Notice that we are using the word displacement here. This just means difference in the two values. It differs from position in that it is a change in position and not the position itself. In this example, I end up on the 100 hash mark in the x direction, so my x-position is 100, but I moved 40 in the x-direction so my x-displacement is equal to 40.

Now we can find an overall distance to movement from an oldie but goodie distance equation:

_{}

I call this an oldie but a goodie because if you haven’t used this form you probably used either the Pythagorean equation,

_{}

Or the equation of a circle, where the radius is the distance from the center to the edge,

_{}

which are essentially the same things. Graphically they look like this in our nice picture:

After that brief digression, we need to determine now what to with what we have. Well, what we have is pretty much everything we need … pretty much. We still have yet to move anything. The good news is that to move something a certain speed, we only need the very simple speed equation:

_{}

So, in our case, we could say that we made it to the couch in 2 seconds. This would result in the following answer:

_{}

Or, as we might say 36 units per second. Now, we nicely put our units down (units/second). That’s good. It will keep confusion later when when we work with the Canadians and they bring in their metric units. Conversions will be much simpler. Maybe if we can convert well enough, we can get them to tell us the difference between ham and Canadian bacon.

Unfortunately, we still have to figure out velocity. How does that differ from speed? I’m glad you asked. Velocity is a speed with a direction. To fix this, we just have to go back to our components. Our x- and y-components have to be evaluated per our time. It is a little more involved but is actually easier to solve:

_{}

See, that’s no too hard.
In fact, if you really want to impress yourself with yourself, apply the
Pythagorean equation using v_{x} and v_{y} as the bases.
The v_{c}
looks pretty familiar, huh?

Now, why do we solve for components? Ultimately, this needs to be in a code, and it’s easier to do it this way. Let’s say we are going to do this in Flash or somewhere we have a set frame rate. We take our smiley face across the room (which we call a sprite) a little at a time per each frame. And, you can’t see the individual, still frames when you watch an animation. It appears to be smooth motion, but we know better. In real life this is no different than a flip book.

We can make our smiley face move in horizontally and vertically in the same way, when all the time, the viewer sees him going diagonally. So we can code this out now. We merely have to figure out a frame rate. Why? Well, we can’t put velocity directly into our computers. They don’t know what time and motion really are. They put out a certain amount of pictures to the screen per second. We call the pictures frames.

So, each frame has to put our smiley in a slightly different place. The good news is that frame rate is in a similar format to velocity both are “something” per second. So, the seconds match. We just need to establish how many frames each second will take.

If we go via the web, we are looking at a standard of 12 frames per second. Many other animations on a PC like a little smoother motion and go for 24 or 30 frames per second. These two numbers also correspond to film and TV, too.

Let’s pick one. How about a good round number like 30 frames per second? Our ultimate goal is to figure out how many units to move per frame so that we can move our smiley face corresponding with our velocity. In this case we can use a simple ratio which will cancel out what we don’t want (seconds) and leave our necessary components. We manipulate the ratio to give us the right form of the answer. Check this out:

_{}

For our example,

_{}

Note, that my time labels are the same (seconds), thus cancelling out. The “units” can be any distance of length – pixels, inches, etc.

We could even have a changing frame rate. The frame rate in our equation would just have to be updated every time step/frame.

Well, I think that we have a working model now. Let’s put the simple equations in Flash.

There is one problem. Flash doesn’t use the famous mathematical xy-axis model. They instead use one based on computer monitors. You’ll probably recognize it, too. Here it is:

Notice that we have to reset the y-values because the y-axis is positive down with the 0 point being at the top left of our room. Everything has get subtracted from 100 in order to get our correct y-downward values. That makes sense since we are going in the opposite (negative) direction of our original y-axis.

We also will set our stage size to our room size to make it easier on our programmer (me.) So it becomes, 200x100 px. We have substituted pixels in for our units. How convenient, hmm?

This would be a sample of the code:

var fr:Number = 30; //frame rate that we hard code or set our stage to

var vx:Number = 0.6667; //set up velocities

var vy:Number = 0.8333;

var couchx:Number = 100; // couch locale

var couchy:Number = 10;

/* All of the above variables can be passed in from another frame. In fact it’s best that they are so that you don’t hand solve all of the parts of your design (game) */

stage.addEventListener(Event.ENTER_FRAME, moveit)

function moveit(event:EVENT){

if (smiley.x < couchx){

smiley.x += vx //smiley is our sprite/instance name

}

if (smiley.y >couchy){

smiley.y-=vy

//negative sign due to the fact that it moves up is negative in flash

}

}

Have you tried it? Two seconds goes slower than you think in games, doesn’t it? If your animation doesn’t work right, check out your registration point and where it is on the stage. I put my registration point in the middle of my sprite. I placed my sprite on (60, 60), of course!