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 vx and vy as the bases.The vc 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!