Frame Rate for Game

Hi, I've seen different folks create ActionScript 3 games at different frame rates, but the question becomes...what is the best or most appropriate frame rate for a game? I've seen 12 FPS, 17 FPS, 24 FPS and 40 FPS, but why so many different rates?

Based on that, I assume that different types of games use different frame rates, so are there best practices for setting my frame rate?

Who is Participating?
tomaugerdotcomConnect With a Mentor Commented:
ideally, you would want to set your framerate high for any game involving animations or motion, in order to guarantee the smoothest-seeming motion. If you've ever played a first person shooter game, you know how important "FPS" (frames per second) is to the gaming community.

The problem with Flash-based games, as opposed to die-hard commercial games, is that you don't necessarily have a hard-core audience who have tweaked out their boxes for maximum juice when fragging their buds. Instead, you have a diverse audience from casual users to business users to hard-core gamers.

Taking that into account, the problem with setting a high framerate as your way to create a smooth gameplay experience, is that if the client's computer is not capable of delivering the rendered frames at the desired rate, the framerate drops - as a result of the CPU bogging down. All of a sudden that bullet traveling through the air goes into slow motion, the character's walk cycle looks like he's swimming underwater and the game's response to keyboard or mouse input becomes sluggish.

The solution is to NOT base your game update cycle on framerate AT ALL, but instead to use an independent clock, leveraging the ActionScript Timer class, to power your primary Game Update Loop.

So my advice to you is set your framerate to whatever you want - 20 - 30 fps is a good rule of thumb. You'll use that framerate for any timeline-based animations, for example if your character has a walk cycle. For updating motion, physics, collisions, etc, set up a timer.

Now that in and of itself doesn't solve the problem. The timer, when handled in this way does provide a little more numeric independence from the screen refresh rate, but if the CPU starts to bog down, the Timer events will as well. What may be surprising to some is that if you set a Timer to fire 10 times a second (equivalent to 10 fps) there OUGHT to be exactly - precisely - 100ms between each tick. But if you measure that, there's usually more. Sometimes as much as twice the amount! So if the game loop is meant to move a bullet 20 pixels every tick (every 100ms) then it stands to reason that if the tick takes longer, the bullet should have moved farther by the time we get around to updating the screen.

This sort of calculation is handled by a time delta factor that's easily calculated by checking the exact time (in milliseconds) of the current update cycle against the time of the last update cycle. You then use this factor in all of your motion calculations so that if more time has elapsed than expected, the objects move that much farther.

oheilConnect With a Mentor Commented:
The frame rate should be as high as possible, but if you like to adress customers with low performance clients, like net books, you should go for low frame rates.
Actually it depends on the game you offer. Some games maybe playable with low frame rates, so why use a high one. If you offer a fast action game with non trivial graphics, a high frame rate must be used to make the game playable, which might than be not playable on a netbook.

So here's a bit of code:

private const INTERVAL:int = 100; // 100 ms in this example (this is SLOW by the way)
private var _lastUpdateTime:int;

private var _timer:Timer = new Timer(INTERVAL); 
_timer.addEventListener(TimerEvent.TIMER, updateLoop);

private function updateLoop(event:TimerEvent):void {
  var currentTime:int = getTimer();
  var deltaFactor:Number;
  if (_lastUpdateTime){
    deltaFactor = (currentTime - _lastUpdateTime) / INTERVAL;
  } else {
    deltaFactor = 1; // for the very first time we hit the update loop

  // ... update stuff!
  heroMC.x += heroVelocityX * deltaFactor;
  heroMC.y += heroVelocityY * deltaFactor;

  // ... more stuff

  // finally, store the current frame time for the next round!
  _lastUpdateTime = currentTime;

Open in new window

// disclaimer: code not tested, check for typos!
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.