On 1, I didn't see a class declaration inside the mxml file for asteroids, but I may have missed it. For the unpredictablility, if global, any portion of the a

On 1, I didn't see a class declaration inside the mxml file for asteroids, but I may have missed it. For the unpredictablility, if global, any portion of the application can modify the values. This means you don't have any access control or format enforcement. This leads to the potential of unintended changes at any point in the application (say, the level was changed somewhere else) and you now have to catch all possible changes in the game loop rather than providing the proper update on assignment. On 3, I had to read through the code several times to even make sure the last loop would run for each object. You could have one loop (with one inner loop) and perform the updates (one was 1 line, the other 3-4 if I remember right) and keep the same clarity. It can also be performance impacting given too many objects. On 4, some of them are subjective (the rbc/wbc for sure), but letters are free and these are being used as code samples. Code reviews are always subjective, but if it's going to be a code sample, it should stand on its own using best practices and comments when they're not reasonable to follow. Given the sample, I'd ask things like "how does it perform with 1000 game objects?" I hope I didn't give the impression I thought it was bad, it just has some common mistakes that, given a project of larger scope, would quickly become unmaintainable without lots of effort.