这完全取决于您何时想要更新值、检查冲突、管理输入等,以及何时想要在屏幕上实际看到发生的事情。
ENTER_FRAME
将使您的更新逻辑和游戏的渲染同步。
每次ENTER_FRAME
调度事件时,都会重新绘制场景。这意味着你所有的游戏更新逻辑总是紧跟在被渲染的屏幕之后。如果由于屏幕上的复杂图形需要很长时间渲染而导致游戏中的帧速率下降,那么游戏更新的速率也会下降。ENTER_FRAME
调度是不稳定的,这意味着它们不适合您需要在它们之间以均匀间隔执行的更新任务。
计时器将导致您的更新逻辑和游戏渲染变得异步。
与处理程序相比,定时器的触发频率可以高得多或低得多ENTER_FRAME
。这意味着您的更新循环可以在重绘场景之前运行多次,或者可以多次重绘场景而不进行任何更改。计时器比ENTER_FRAME
处理程序更不稳定,使它们更擅长按设定的时间间隔做某事。尽管如此,更新之间仍然会有一点偏移:
根据 SWF 文件的帧速率或运行时环境(可用内存和其他因素),运行时可能会以稍微偏移的间隔调度事件。例如,如果 SWF 文件设置为以每秒 10 帧 (fps) 的速度播放,即 100 毫秒的间隔,但您的计时器设置为以 80 毫秒的间隔触发事件,则该事件将在接近 100 毫秒的间隔时调度. 内存密集型脚本也可能抵消事件。
- help.adobe.com | flash.utils.Timer
就个人而言,我一直使用ENTER_FRAME
vs Timers。对我来说,如果我对游戏中的对象进行更改,这些更改应该立即显示在屏幕上,这是合乎逻辑的。
如果您希望能够以比帧速率能够管理的速度更快的速度更新游戏中的组件,那么计时器是很好的选择。如果您希望在特定时间范围内完成给定数量的更新,计时器也很好,因为它们不受屏幕能够像ENTER_FRAME
现在这样重绘的速率的限制。
至于实际实现,您最好选择一个并实现一个 handler。这意味着您应该在整个游戏中只有一个函数将由 Timer 或ENTER_FRAME
. 您不想在每个应该更新的类中创建单独的处理程序。相反,您希望让您的顶级类(或该类的近亲)定义处理程序。您还想在该类中创建一个列表,该列表将代表游戏中需要更新的所有内容。
从那里,您将创建一个小的方法集合,这些方法将处理从该类中列出和删除可更新实例。每个可更新实例要么实现一个接口,要么扩展一个定义update()
方法的类。它可能看起来像这样:
public interface IUpdatable
{
function update();
}
从那里,更新程序类中的更新处理程序将简单地遍历列表中的所有可更新对象并调用它们的update()
方法,如下所示:
for each(var i:IUpdatable in updateList)
{
i.update();
}
最后要注意的是,这种方法意味着如果您决定从使用ENTER_FRAME
处理程序切换到计时器,反之亦然,这是更新程序类中的一个简单切换,不需要您更改游戏代码的任何其他部分。如果您在每个需要更新的类中创建处理程序,那么您的改变将意味着对每个单独的类进行更改。