3 ms·

Thanks ismarc! I appreciate all your pointers, but I feel that some of them are somewhat subjective. 1. True, chipsy pointed this out and I actually changed i

Thanks ismarc! I appreciate all your pointers, but I feel that some of them are somewhat subjective. 1. True, chipsy pointed this out and I actually changed it last night. I'm not sure how global variables specifically effect unpredictable gamerate (and I don't think they're actually global anyways - they're class variables of the main game mxml). 2. True, I can see how the application mxml can get too big in code size without a "Game" object. I also changed this last night. ;) 3. You're right that functionally all of those loops can be reduced into one, but I feel that that comes at some cost of code readability and extensibility. For example, if my game logic was 10x longer than it is now it might be best modularized into discrete methods that reflect the separation of loops that I have currently. 4. Fair enough, but I think that this point is also somewhat subjective. E.g. the meanings of RBC/WBC are pretty clear with a single class definition lookup (it's right there in the class comment). I hope that my response doesn't seem ungrateful, I really appreciate your help. Please let me know if you think I'm mistaken on any of these points (I am learning after all).

ismarc 17y ago
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.
- slow_bro 17y ago
  Okay, gotcha. Thanks again. :)

ismarc 17y ago

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.

slow_bro 17y ago
Okay, gotcha. Thanks again. :)