Toni Westbrook dot Com

The Joy of Computer Science and Engineering

Acceleration for Better Goomba Stomping

So now we understand positioning an object on a screen, moving the object around using the principles of velocity, and how to handle collisions with walls and other simple objects. While we can do quite a lot with these simple fundamentals, there is one more that is key to modeling realistic movement. We can understand a little how it works by watching how Mario jumps in the Super Mario Bros series.

Mario jumps in an arc movement

For those who haven’t played Super Mario Bros, Mario jumps in an arc. When he begins to jump, the sprite on the screen moves up very quickly, then slows at the top of the arc, then slowly starts moving back down, until he’s going the same speed as when he started the jump when hitting the ground. The reason for this movement is due to acceleration. Specifically, the game is modeling the affects of gravity, gravity being a force that causes acceleration in the downward direction.

Just as velocity is the rate of change of an object’s position (e.g. meters per second), acceleration is the rate of change of an object’s velocity (e.g. meters per second per second). Gravity is a force that causes constant acceleration in the downward direction. Because of this, though Mario starts with a velocity that causes him to move in an upward direction, acceleration downward causes this velocity to slowly decrease, then reverse, getting faster in the opposite direction.

Programatically, we can handle this the same way we do velocity. In addition to updating position with velocity, we’ll want to update velocity with acceleration - so we’ll need two more variables, AccX and AccY. During our redraw, we’ll want to update both velocity and position: (VelX = VelX + AccX) (VelY = VelY + AccY) (X = X + VelX) (Y = Y + VelY). Acceleration can be used to model many realistic scenarios besides jumping in platform adventures, such engines firing in a spaceship simulator, or shells being fired from a cannon in a tank war game.

Onto More Advanced Topics

We’ve covered position, velocity, acceleration, and basic collisions - with these basic techniques, a wide range of realistic motions can be accomplished when making your next game. There are, however, hundreds of more topics, including friction, complex collisions, fluid dynamics, light oriented (shading, diffraction, reflection), etc. However, before getting too crazy, try some of these techniques in simple games to get familiar with Newtonian Mechanics. After that, more advanced topics will be easier to handle. Have fun with you physics!

Thinking Inside the Box

However, now that we have movement, we run into an issue. When we think of a classic video game, we think of boundaries, such as the edge of the screen, or floors/walls/ceilings, or other objects. In many games, such as platformers, these boundaries will stop the object from moving. In games such as Pong and Breakout/Arkanoid, the boundaries cause the object to bounce.

In the classic game Breakout, the ball bounces off the walls, paddle, and bricks.

The idea of bouncing is the boundary only reverses one dimension of the ball’s direction, while the other dimensions remain unaffected. This is expected behavior that reflects real life, as remember that vectors are treated independently in each dimension. E.g. if the ball is traveling right and up, and hits the right wall, it should continue to travel up, but it should start traveling left. The right wall only affects the left-right dimension, it never affects the up-down direction. If the ball then hits the ceiling traveling left and up, the ceiling will only affect the up-down direction, and now the ball starts traveling left and down.

Each wall only affects the direction in one dimension.

Looking back, our program currently has 4 variables. X (x position), Y (y position), VelX (x velocity), and VelY (y velocity). When redrawing our screen, in the case of boundaries, we would check to see if the ball has “hit” any boundaries - that is, if the coordinates of the ball (X and Y) reside in the same space as the coordinates of any of the boundaries. If so, we adjust the velocity accordingly. E.g. if the ball has an x velocity of 4 (traveling 4 pixels per redraw to the right) and a y velocity of -2 (traveling 2 pixels per redraw downwards), and hits the right wall, the x velocity will be reversed - that is, multiplied by -1 (VelX = VelX * -1). So now the x velocity is -4 (traveling 4 pixels per redraw to the left), and we’ve achieved our bounce. If we apply this boundary check to a movable paddle, we now have pong. If we apply this boundary check to bricks at the top of the screen, we now have breakout as well!

Onto Part 4

Velocity

Velocity is a fancy word for speed with a particular direction. Going 88 MPH would be speed. Going north at 88MPH would be velocity. But forgetting the direction component for a moment, speed is measured in distanced traveled over time. For example, when we say 88 Miles per Hour, we’re saying the object is moving a distance of 88 miles over a period of an hour - i.e. the object is changing its position by that much in an hour.

Remember, our video game object has position too - it has its coordinates. If we introduce velocity into our game, we now give our object the ability to move by the laws of physics. If we redraw our object once a second, and the object is going 5 pixels right per second, we would be adding 5 to our X coordinate (the value stored in our X variable) every second, then redrawing the object. If we want it to move faster, we increase the speed, 6 pixels per second, 7 pixels per second.

Don’t Forget the Vector!

Vector is another mathematical term for a quantity with a direction involved. Remember, velocity is speed with a direction, so it is a vector. There is a helpful property of vectors that allows us to split them up by dimensions - that is, if something is moving in two dimensions at once (north and west, up and north, south and east and down), we can handle each direction separately. If something is moving north and west, we can talk about how much it’s moving in the north direction and how much it’s moving in the east directly independently. In our video game case, we can say “okay, the pong ball is traveling -3 pixels per second in the X direction, and 2 pixels per second in the Y direction). That means every second we’re going to subtract 3 from our X variable, and add 2 to our Y variable, then redraw the ball. The movement of the ball would appear to be going diagonally up and left, as seen here:

We handled each dimension separately, but the end result was the diagonal movement.

Now we can store our X velocity and Y velocity into variables too (for example, velX and velY). So, every time we redraw the screen, we are going to add velX to X (x = x + velX), and velY to Y (y = y + velY). So if we have a very large velX, the ball will be moved across the screen very fast from left to right. If we have a very large negative velY, the ball will be moved down the screen very fast. And we don’t need to press the key each time, our velocity will do the work for us through simple addition (or subtraction if we are adding a negative number).

If we wanted to design a fun experiment, we could assign our arrow keys to change velocity. Pressing left would subtract one from velocity in the X direction, pressing up would add one to velocity in the y direction, etc. This would have the effect of making the ball move in a direction more quickly the more you press the arrow in the same direction, or slow down and start moving backwards if you press the arrow in the opposite direction. Not pressing the arrows would simply keep the ball doing whatever it was doing - e.g. traveling in whatever direction it was before.

Onto Part 3