Chapter 8: Advanced Timing and Trigonometry: Blow Em Up

We've come a long way in our pursuit of games in Flash. We've covered the bulk of the ActionScript language and seen the implementation of increasingly complex games . Most of our focus from this point on will be on topics that are not directly related to Flash, but to game programming in general.

This chapter takes on two important subjects. First, we will be going back to the subject of timing and finishing what we began in Chapter 7, "Real-Time Programming: Shoot 'Em Up ." We'll investigate the ways we can free our game's behavior from the given frame rate. From there, we'll look at the subject of trigonometry. Although we won't have a chance to cover the topic completely, we'll look at enough theory to be able to handle angles in our games.

Advanced Timing

I've been talking about it for quite a while now, and it's finally time to delve into some advanced timing concepts. It mainly boils down to creating a game engine that functions independently of the movie's set frame rate. Changes to the actual frame rate of the game should have little or no effect on the speed at which things move in our games.

In the past, our games have relied on an onEnterFrame handler to do the work each frame. Inside that handler, we call functions to update the player, update the opponents, handle collisions, and so on. To free the game from the frame rate, we must get rid of onEnterFrame . By moving beyond onEnterFrame, we are able to have elements of our game process at different rates based on the priority of the game element. With onEnterFrame , you are tied to the frame rate of the movie.

The technique we've used to run code constantly has been to attach a function such as playGame to the _root 's onEnterFrame handler. We're going to change this by setting an interval to call playGame instead.

Doing this has a major impact on how things work for Flash. Flash renders to the screen (refreshes the screen with updated information) between each frame. If we update the position of a clip based on an interval, the position is updated every x milliseconds . The screen is then drawn based on the fps, but the movement of objects is based on a fixed timer.

It's important to understand that one of the things that causes Flash to bog down is moving lots of clips on the screen. The rendering takes a long time. The updating of the player and the bad guys is relatively fast compared to the time it takes Flash to compute what the screen is going to look like after the update.

When we use a timer to update the game's data, we free it from the frame rate of the system it's playing on. This makes the graphics choppy on a slow system, but things still move at close to the same speed that they would on a fast computer. The difference is that the graphics on the fast computer are smoother because Flash has more spare time to spend rendering more scenes (higher fps). This is a huge improvement over our old games, which caused the entire game to slow down when they were run on a slow computer.

That's basically all there is to it. We use an interval to update our game data instead of updating it every frame with onEnterFrame .

Tip  

You could go even one step further, although we won't do it in this book. You could have a function that monitors the current frame rate and reduces the update timers for less important game objects. This would allow you to give optimum performance on fast systems while degrading only as much as necessary on slower systems, all computed at runtime with ActionScript.

We can take it one step further, though. Consider this: You have one function to update the player; one function to update his opponents; one function to update bullets, missiles, and other projectiles ; and so on. Each of those functions can be given to its own interval, with its own millisecond trigger. That means you can customize the frequency of updates between different objects in the game. The user is always most focused on his own object, so you should update that the most often. Some of the lesser objects can update less frequently, saving precious CPU. And changing these millisecond triggers is as easy as changing a constant. We'll see this technique used in this chapter's game, of course.

Now that I've explained how intervals work, let's cook up a bit of code. I prefer to look at code when I'm learning a new language, so I won't leave this topic without some:

 playerTick = 30; opponentTick = 60; missileTick = 75; function updatePlayer(){/*update the player's object*/} function updateOpponent(){/*update the player's object*/} function updateMissiles(){/*update the missile object's*/} setInterval(updatePlayer, playerTick); setInterval(updateOpponent, opponentTick); setInterval(updateMissiles, missileTick); 

As you can see, we're declaring three constants, each with the suffix Tick . These constants indicate the number of milliseconds between updates to their respective objects, player, opponent , and missiles. Then we declare three update functions ”one for each object type. Finally, we set intervals for each, using the update function and millisecond constant for each.

You might be thinking, "Hey, the opponent would update half as often, so wouldn't it move half as fast?" And the answer would be "Yes, it would." To counterbalance this, we use a speed variable. We set the speed of the opponent to be twice as much as the speed of the player. Then when the update function moves the opponent, the opponent is moved twice as far. The opponent will, of course, be moved only half as often. The net result is identical movement between the player and his opponent.

Tip  

Instead of doubling the speed of the opponent when you cut its interval, you could always set up a rate that is based on the interval. Let's say that the opponent should move 10 pixels every second no matter how often the interval runs. You could set speed to be a function of the interval. In this case, speed would be 10 times the interval (in milliseconds) divided by 1000 milliseconds (one second). By setting up speed in relationship to the interval, you can set all the speeds for all the characters based on a common system, which allows for much better code readability and less headache later.

That basically concludes our discussion of timing. It does leave us at an interesting intersection, though. We're talking about moving things around the stage in time, free of the frame rate. While we're on the subject of freeing things, we should talk about how to move objects freely about the stage.