Skip to main content
GameDev.net gamedev.net

PRO Tired of ads? Read GameDev.net ad-free and help keep the community independent with GameDev Pro — $3/month.

A Quick Lesson in Velocity and Speed
Article Featured

A Quick Lesson in Velocity and Speed

The following is one of my lessons/labs in a class that I used to teach on programming animations.  I hope that it will be useful, especially if you are becoming interested in adding some physics to your models.  The code is a little old but the rest should be fine.

hagerprof
hagerprof
March 29, 2025 15.2k views

Velocity and Speed

Many a student has asked me how to make something move on screen through coding. I think that they are really asking me for the answer, but sadly (for them) I give them the lecture … and now you get it, too!

It’s not hard. In fact, I could give you simple code to get you started. The problem is how to move something correctly. It should start and end in the proper place. For proper motion, it is then important to know position. If that is the case, let’s start off with a point particle (☺) and a specific place.

A point particle is used to represent an entire body. This is based on a supposition 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. That is fortuitous, because 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? I’m glad that you did. Well, they are the lines created when we have zero distances in all direction except one. Simply put, in our system the y-axis, forces the x to be 0, but 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 our virtual reality, even though you are a smiley face, you are still a point particle with no volume (or in this case area.) We can always give you dimensions later. To make it easier, you can take the center of the smiley face as the actual point that is being represented.

Before we get to deep in the weeds, let’s get to business and put you in a room. If you go and sit on the couch, you move to another place in that room. This can actually be drawn as follows:

(Notice how we strategically placed the left and bottom edges of the room against the axes.)

Now, your virtual “you” is roaming xy-space. Whee! 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. Let’s keep it simple and just start you with two objects.

Although, guess what? We technically still aren’t moving. To do that, we have to go back to positioning: where do you start from and where do you go? So, let’s refine the room with some simple distances:

Hmm, do you want to just estimate at this point? Sure. We can start (60, 40) and end at the couch on (100, 90). The couch, even though being represented as a rectangle, is a point particle as well (in its center.) Graphically, it looks like this:

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. However, since many of you may not have taken that subject yet, and more importantly may never want to, (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 merely moving a point/smiley face across a flat surface.

So, we are going to break out a (hopefully) familiar formula and break things into components. Let’s 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 both 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 it marks 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. The Pythagorean equation uses the hypotenuse as the distance moved. You can set it up such that the “legs” of the triangles are the displacements in the x- and y-directions parallel to the axes. A circle has the same difference from the edge to its center no matter where you are on the edge. Then the distance/displacement formula is the same along the circle’s edge to the center, unconditionally. Graphically the two equations look like this in our nice picture:

Note that we can use our already found displacements in the formulas. The terms a and b become the x- and y-displacements, respectively. They also fit nicely into circle equations with the same value.

After that brief digression, we need to determine what we still need. We still have yet to move anything! We just have positions and distances. The good news is that to move something at a certain speed, we only need the very simple 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:

We conveniently use “units” (units/s or units per second). That’s good. It will reduce confusion now, while later we can switch those units with anything we would like.

Unfortunately, we still have to figure out velocity. How does that differ from speed? Excellent question. 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, apply the Pythagorean equation using vx and vy as the bases. The previous v(speed) should look pretty familiar.

Now, why do we solve for components? Ultimately, this needs to be in a code, and like I stated before, it’s easier to break things into simpler components. Let’s say we are going to do this in a 2D engine or animation. We take our smiley face (which we call a sprite) across the room just a little at a time per each picture projection to the screen. You can’t see the individual, still pictures 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 merely need to figure out a rate at which we show each picture. Why? Well, we can’t put velocity directly into our computers. Computers, along with software, can’t formally understand what motion is. Computers draw a certain amount of pictures to the screen per second. These pictures are often called frames, and the number per second is called a frame rate.

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 as both are “something” per second. We just need to establish how many frames each second will take.

If we go the route of classic 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 classic film and TV, respectively.

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:

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 employ 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 some code. There is one problem. Most display software 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 origin (0,0) being at the top left of our room. Everything in the y-direction then has to 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 J). So it becomes, 200x100 px. We have substituted pixels in for our units. How convenient, hmm?

If you are running this on a stage with a consistent frame rate, 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; //change of sign due y being negative going up

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) at once and separate the dials from the mechanics*/

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;

}

}

The greater and less than symbols are used to stop the movement when they reach the desired spot.

Have you tried it? Two seconds goes slower than you think in games, doesn’t it? If your animation is a little off, check the registration points of the moving object with where it is placed on the stage. For me, I put my registration point in the middle of my sprite. I placed my sprite on (60, 60), of course! Run again as needed.

If you like to try out one of my free apps (for copying and moving bulk files,) please go here:

https://apps.microsoft.com/store/detail/filesnatch-free/9NTT08T64GLF

If you’d like to pay me $2.79 for roughly the same app without ads, please go here:

https://apps.microsoft.com/store/detail/filesnatch/9P6WGSGHCN67

If you like to see me post silly things from my company, try this:

https://www.facebook.com/people/Digital-Tumult/100057555664875/

If you’d like to see me in action:

https://www.youtube.com/@digitaltumult

Related Tutorials

Discussion

Discussion

Loading comments...