Thursday, February 7, 2013

Progress This Week


I started out this week by adding a level to the game in between levels 2 & 3. The reason for this was to make the game more progressively difficult as the player moves from level to level. On level 2 the enemy shoots back at the player, but doesn't move. On level 3, the boss shoots and moves around the screen. Level 4 is the previous Level 3. The enemies fly across the screen in a wave-like flight pattern.

Also this week I started modifying the code in levels 2 & 3 to more closely match the code in level 1. The main purpose of this was to make the code more consistent to simplify changes in code as we add more features across the various levels. There are a couple of spots where the code doesn't exactly match, but for the most part these levels are consistent now, which should simplify things.This should also make it easier to create a new level. The basic process for creating a new level would be to copy one of the existing levels, change some of the references accordingly (e.g., change the title "Level 1" to "Level 5"), and add the new level-specific code.

I also applied a fix to the pause function. I had noticed that clicking pause was triggering a 'shoot' event. In and of itself, this would not be a huge deal, but in some cases it was causing errors. Some of the errors incidentally were somewhat misleading and I couldn't figure them out (e.g., the screenGroup display group was inexplicably becoming nil when the pause button was tapped). In any case, to keep the 'shoot' listener from triggering, and to get around the errors, I added a "return true" to the pause listener. That "handles" the tap event and keeps it from propagating to other listeners (i.e., the 'shoot' listener). There is some documentation on this at http://developer.coronalabs.com/content/events-and-listeners#Touch_Events.

There is one more interesting issue I came across this week. I noticed that when I had methods named exactly the same across levels I was getting errors, which confusingly referenced the same method name but from different level scripts. I suspect this is some type of memory-related issue. What I did to get around this was to change the method names in the various levels to have unique names (e.g., "gameloopLevel2"). It seems to me there must be a better way of fixing this. Nonetheless, this fixes the error. I hope to revisit this at a later time and find a workaround. 

Update: Travis has pointed out that this seems to be due to the functions being global. He found a way to "forward declare" the functions so that the function names can remain consistent throughout all the levels. This may presumably be less prone to memory leaks since the functions are no longer defined globally. 

No comments:

Post a Comment