Chapter 7: Real-Time Programming: Shoot Em Up


We have a lot to talk about in this chapter. We're going to cover several related topics and then develop our most advanced game yet. We'll begin by talking about realtime programming, a subject that involves getting Flash to do things at specific times and to do things repeatedly at specific intervals. Then we'll talk about some programming theory called finite state machines, which will help us build more sophisticated logic in a visual and easy-to-understand way.

Timing

Timing in Flash is not a simple matter. We have an existing timing system in Flash: the timeline. The timeline works with the playhead moving over the timeline and executing scripts that occur on specific frames. A frame rate property of our movie allows us to set the frame rate. This affects how many frames are processed in a second ( frames per second). By changing this frame rate, we can speed up or slow down our movie. The problem comes because the frame rate property you set is a maximum frame rate. It guarantees you that your movie will not play more quickly than the setting you use. It can, however, end up playing more slowly.

On slower computers, Flash movies play at slower rates than on faster computers. That can cause you all kinds of problems. If you have a game in which several movie clips are moving about the stage, you can feel confident that the game will play more slowly on older computers. If you set the frame rate at high and the computer you are developing on is fast, you'll create games that will be slow on most of the computers on the Internet. That's not good. For arcade games , a slowed game is an easier game. Although I normally feel that people with slower computers should get some breaks in life, as game developers, we should aim for a consistent game experience across all computers.

Not only does a slow game ruin the experience for the player who is using a slow computer, but it also often gives the player an advantage when playing your game. The game will appear to play in slow motion, giving the player a reflex advantage that can be quite large.

The fix for this problem is not simple. It involves freeing your game's behavior from the frame rate that your game is playing at. And oddly enough, we're not going to get into exactly how that is done in this chapter. The explanation of timing will begin in this chapter, but we won't be finished talking about it until after Chapter 8, "Advanced Timing and Trigonometry: Blow 'Em Up . In this chapter, we're going to look at the basics of timing with ActionScript. There is plenty we can do with that alone. Then in Chapter 8, we'll take it one step further and completely free our game from the current frame rate.

You saw the getTimer function in Chapter 5, "Arrays: Match 'Em Up and Sliders ." We used getTimer to obtain the number of milliseconds since the movie was started. By recording the time on one frame and then on the next frame subtracting the current time from the recorded time, we can obtain the number of milliseconds since the last frame. We can use that number in a calculation to find the current frame rate.

The getTimer method is slow and requires performing several steps of algebra every frame. As you will find out soon, anything you do every frame in a game must be ultra efficient. You don't want to do calculations for timing every frame because Flash MX gives you a built-in way to execute some script every x milliseconds.

The setInterval Function

This function is used to create a new interval event. After the interval event is created, it calls a given piece of code once every so many milliseconds. You choose the delay between calls when you create the setup. The interval setInterval has the following general form:

 number setInterval(  functionName  ,  interval  [,  param1  ,  param2  ...]); 

Notice that the function is global and is not called on a reference. The function requires two parameters: a function name and an interval. The function name can be the name of a built-in function or method, a user -defined function or method, or an anonymous function. The interval is the number of milliseconds between calls to the function.

Notice that the return type is a number. That number is an ID for the interval you just created. You'll typically want to store that number somewhere because if you ever want to stop the interval from calling its code, you'll need it. We'll talk about removing interval events in the next section.

Consider the following script, which sets up an interval using a predefined function:

 c=0 function count(){     trace("count#" + c++); } setInterval(count, 500); 

This script first defines the function count , which does nothing more than increment a counter, c , and then output it with trace . After the definition, we call setInterval with the name of our new function as the first argument. The second argument, 500 , gives us a 500-millisecond delay between calls to the function.

The result is that the output panel displays a newly incremented number twice a second, regardless of the frame rate that you set for your movie. Even if you set your movie to one frame per second, you'll still see two outputs per second, or two outputs per frame.

Note  

Even though setInterval can be used to trigger events more than once a frame, these events always happen before or after the code runs for a frame. Therefore, you don't have to worry about being in the middle of a script in a timeline and having an event disrupt your work.

The third argument to setInterval is a list of arguments to send to the function. Consider the following script, which makes use of these optional arguments:

 setInterval(traceMsg, 1000, "once a second"); setInterval(traceMsg, 2000, "once every two seconds"); setInterval(traceMsg, 3000, "once every three seconds"); function traceMsg(myString){     trace(myString); } 

You can see by the output in Figure 7.1 that the messages are being output with a 1-, 2-, and 3-second delay respectively. The third argument to the setInterval calls is the message the argument given to the traceMsg function when the interval executes.

click to expand
Figure 7.1: The optional arguments at the end of a setInterval call are used to give arguments to the function that the internal event is calling.

The clearInterval Function

Now that we can set up a function to execute at a given time interval, we should talk about how to get rid of one. If you create an interval with setInterval and you later want to remove it so that it does not call its function anymore, you can do so in one of two ways:

The first option is to call the clearInterval function, which has the following general form:

 void clearInterval(  intervalID  ); 

This function returns nothing, is called globally (no reference), and requires one argument. That argument is the ID number of the interval you want to clear. Remember that when we talked about setInterval , I said it returns a number. That number is the ID for the newly created interval. If you store that number, you can later use it with the clearInterval call to remove it, as in the following script:

 msgInterval = setInterval(function(){trace("hi");}, 500); clearInterval(msgInterval); 

In this script, nothing would be executed. The setInterval call would set up a function that traces the string "hi", but the following line clears that same interval. Because the set and clear calls are in the same frame, there wouldn't be a chance for Flash to execute the interval before it was removed in the second line. That's only because this is a simple example. Normally. the clearInterval would come in some other piece of script from the setInterval .

That's all we're going to say about timing for now. In the next chapter, we'll expand our timing abilities .




Macromedia Flash MX 2004 Game Programming
Macromedia Flash MX 2004 Game Programming (Premier Press Game Development)
ISBN: 1592000363
EAN: 2147483647
Year: 2004
Pages: 161

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net