3 ms·
chipsy covers a good number of concerns, and I unfortunately don't have time to enumerate the full list of issues seen in both, so I'll quickly cover some of th
by ismarc 17y ago
chipsy covers a good number of concerns, and I unfortunately don't have time to enumerate the full list of issues seen in both, so I'll quickly cover some of the higher level issues:
1. (asteroids) Tracking state in a series of global variables and then relying on that state in timer callbacks to implement your gameloop leads to unpredictable gamerate and framerates.
2. Embedding the core game logic in mxml file is "bad form". I would suggest creating a game class that is instantiated and called from within that initial mxml file, but it's basically to get the launcher.
3. (symptom) You have entirely too many, pointless loops. You iterate over the same list of objects numerous times in multiple locations. A good example would be in the most recent Level.as update() function. You iterate over the GameObjects 3 different times (not counting the inner loop for collision detection) when this can be reduced to 1 loop.
4. Variable names...they're poor. An example is:
for each (var object:GameObject in O) {
What is O? Scroll to the top of the function. O is the result of getObjects(). Well, getObjects obviously gets some objects, but which ones? What type of collection does it use? Go to getObjects() definition and it uses a Vector, but you use the name O to build the vector internal to getObjects as well. The variable name should, at a minimum, provide a hint as to what purpose it serves. game_objects would be good, or gameObjects, or activeObjects. And, I can only guess what RBC and WBC even mean. I'm guessing maybe it's red blood cell and white blood cell? Even the associated class files don't provide any information, so from the point of view of someone reading the code, RBC and WBC are random letter strings representing a "something"
- slow_bro 17y agoThanks 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 agoOn 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 agoOkay, gotcha. Thanks again. :)