TimerEvent vs. ENTER_FRAME in AS3/Flex games? - actionscript-3

Question

I'm trying to write a simple game in AS3 / Flex 4, and I'm trying to find the best way from the get-go to handle timed execution of code.
The most natural approach would be to use a bunch of Timer objects throughout the program. However that's supposedly pretty expensive on CPU cycles, compared to ENTER_FRAME.
However I'm not sure how natural it would be to base all of a program's timed execution off of ENTER_FRAME, and I have read on stackoverflow that it's got issues - that Timer doesn't - with regards to dragging down animation and framerate when the complexity of the program increases.
Another option that comes to mind is to simply use one Timer object in the program, whose event handler will go through and check on everything in one go around - kind of like blending the usual Timer and ENTER_FRAME approaches.
My question is this: What's really kind of the best idea for a video game in AS3/Flex 4, and why? Thanks!

Answer 1

It depends entirely on when you want to update values, check collisions, manage input and so on vs when you want to actually see something happen on the screen.
ENTER_FRAME will make your update logic and the rendering of your game synchronous.
Every time an ENTER_FRAME event is dispatched, the scene is redrawn. What this means is that all your game update logic is always immediately followed by the screen being rendered. If the frame rate in your game drops due to complex graphics on the screen taking a long time to render, so will the rate at which your game updates. ENTER_FRAME dispatches are erratic, meaning they're not good for update tasks that you need to perform with even intervals between them.
Timers will cause your update logic and the rendering of your game to become asynchronous.
Timers can trigger far more or far less frequently than an ENTER_FRAME handler would. This means that your update loop could run multiple times before the scene is redrawn, or that the scene could be redrawn multiple times with no changes. Timers are less erratic than ENTER_FRAME handlers, making them better at doing something at set intervals. With that said though, there will still be a little bit of offset between updates:
Depending on the SWF file's framerate or the runtime environment (available memory and other factors), the runtime may dispatch events at slightly offset intervals. For example, if a SWF file is set to play at 10 frames per second (fps), which is 100 millisecond intervals, but your timer is set to fire an event at 80 milliseconds, the event will be dispatched close to the 100 millisecond interval. Memory-intensive scripts may also offset the events.- help.adobe.com | flash.utils.Timer
Personally I have always used ENTER_FRAME vs Timers. To me it is logical that if I make changes to the objects within a game, those changes should be immediately represented on-screen.
Timers are good if you want to be able to update components within your game faster than the frame-rate is able to manage. Timers are also good if you expect a given amount of updates to be completed within a certain timeframe, because they're not bound by the rate at which the screen is able to be redrawn like ENTER_FRAME is.
As for actual implementation, you preferably want to pick one and implement one handler. This means that you should only have a single function in the entire game that will be triggered by either a Timer or ENTER_FRAME. You do not want to be creating individual handlers in every single class that should be updated. Instead, you want to have your top level class (or a close relative of that class) define the handler. You also want to create a list within that class which will represent everything in the game that needs to be updated.
From there, you will create a small collection of methods that will deal with listing and de-listing updatable instances from that class. Each updatable instance will either implement an interface or extend a class that defines an update() method. It could look like this:
public interface IUpdatable
{
function update();
}
From there, the update handler within the updater class will simply iterate over all of the updatables in the list and call their update() method, like this:
for each(var i:IUpdatable in updateList)
{
i.update();
}
A final note is that this approach means that if you do decide to switch from using an ENTER_FRAME handler to a Timer or vice versa, it's a simple switch in the updater class and doesn't require you to change any other part of the game code. If you go around creating handlers in each class that needs to be updated, your change of heart will mean making changes to every single class.