The Time Interval


Our current physics model has one big hole in it that could potentially cause us some major problems. Consider this, for example: In our marble example, if we had increased the amount of force given to the marble when the user clicked, we could have increased the speed at which the marbles moved. If we had increased it even more, we could have had marbles that were moving extremely fast, even being updated at 20 millisecond intervals. If we then compounded our problem by using many small (small radius) marbles that traveled quickly, we could be in danger of what is called skipping.

Skipping is caused by our velocity being so large that the marble's updated position actually hops over a collision into a collision-free position. Figure 11.13 shows this graphically.

click to expand
Figure 11.13: Our marble is moving quickly and has skipped over another marble, missing the collision that should have happened .

Skipping can be a real problem and can in some cases cause a major change to the way you are modeling your physics. Generally though, your game will have some level of tolerance to skipping, and as long as you watch what you are doing, you can reduce it to the point where the user won't notice it.

What can we do to reduce skipping? Well, the first thing to do is identify when you have the potential for it. For example, if you set a maximum velocity, you can try to keep the maximum change to position in one interval smaller than the radius of your marble. In other words, if your marbles are at least 20 pixels wide you could set the maximum velocity to be 20 pixels per iteration (20 milliseconds in my marbles example, but it could be anything). If the velocity is capped at the minimum marble diameter allowed, you will greatly reduce ”but not eliminate ”your potential for skipping.

To illustrate how you can set up the maximum velocity and still skip, look at Figure 11.14. Notice that if the point were directly in the ball's path , the skip would not occur. However, because the circle is round, the point can lie outside the circle both before and after the update but still be in a position that should trigger a collision.

click to expand
Figure 11.14: The point is outside the circle before the update and after the update; there should have been a collision.

The good news is that the chances of this happening are small when the point is directly in line with the ball. The chances of it happening grow as the point comes closer to the edge of the circle's movement path. This is good news; as the chances get higher that you'll get a skip, the damage it does to the realism grows smaller. When chances are high that you will skip, it's often okay to skip. With small balls moving quickly (the condition we had that created this mess), a point that barely crosses the ball path will look like a point that the ball barely missed. As long as your user is convinced, your physics model is doing its job.

Another way to help ease skipping is to reduce your time interval. Remember that we're updating our physics on an interval so that it will be independent of the frame rate. You can simply force Flash to iterate your physics more often, allowing you to reduce the maximum velocity.

There is certainly a limit to how often you can go with the "reduce the interval" plan. You'll find that Flash will be unable to iterate your physics code quickly enough to match the interval you are asking for. That causes the interval calls to pile up. The result is the same as if you had just set the interval higher in the first place. It should be obvious that optimizing the part of your code that is executed every interval (collision detection mainly ) should be as optimized as possible. The faster that Flash can process your physics code, the more times per second you can update. The more times per second that you can update, the better your animation and behavior will appear.

Finally, if all else fails, there are ways to do your collision detection that are skip proof, but they are generally a bit more CPU intensive as a result. In any case, these are ideas for you to continue learning. Digging into the topic of advanced collision detection, although probably a lot of fun, is beyond the scope of this humble chapter on physics.

There is one final topic we need to talk about before we're ready to develop Pachinko .




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