Here are my notes: Use ON_ENTER_FRAME events and getTimer(), not TIMER. The Timer class is a low-accuracy system good for tweens, but it runs aground of Flash'

Here are my notes: Use ON_ENTER_FRAME events and getTimer(), not TIMER. The Timer class is a low-accuracy system good for tweens, but it runs aground of Flash's "elastic racetrack" throttling behavior: Flash will try to keep a balance between rendering frames and code execution and that conflicts with the absolute control a game needs. ON_ENTER_FRAME will keep your main loop running once-per-frame, which is what you want; with getTimer() you can still apply a dT to your objects. You're using strings in your enumerated constants. These will compare slower than integers. However, the bigger concern for performance is..... You're using the Flash transform functions on a per-frame basis for rotations. This will always be slow; software rendering is fast only at simple memory copies and nothing else, which translates to using copyPixels as much as possible in the inner loop. Hence the performant way to architect Flash games is to prerender a giant spritesheet with draw(), use that as a lookup table for each rotation, and to draw the result onto a single surface rather than to maintain objects on the display list, because the Flash display list will do event processing per object. If you need to finely control draw layers, defer the actual rendering operation into a queue for each layer, and do it all in one pass later. Your "GameObject" won't scale well for a more complex game because it mix three concerns(drawing, motion, collision) in a single class. This caveat is true of the Flixel/Flashpunk architectures too; a more factored approach would be to push these things into components and instance them on each entity type. For an example of a more factored entity system look at Pushbutton Engine. Anyway, it looks pretty good overall, but it's a simple game. The companies may be looking for something a little more elaborate.