Interegnum and Continuation

DON'T PANIC

Do you have your towel?  Good.  Understand tho - since we can't card you, there simply won't be any serving of Pan Galactic Gargle Blaster's.  Sorry - but Management simply insists - no one, but no one, is served. 

On to our story.

Hic.

Team C - good solid name that.  Not pretentious at all.  Not the uppity Team A, no sir.  Nope.  Too snobbish if you know what I mean.  Oh and not the social climber Team B - keep an eye out on those people...

No - we are Feet Of Clay - Solid Middle - Good Ole Team C. 

Sigh.

Guess we are gonna loose a lot of money over this decision.  Who wants to deal with a bunch of average SLAP!!!  Ouch!  Okay OKAY - yes I'm with the team all the way!  You betcha.  Team C all the way!

Where was I?  Oh yeah.

Ahem.

Flights of Fancy is going to continue.  Yes, we have decided - we really really need this on our resume's - oops, did I let out too much?  Anyway!  Yes - Flights of Fancy is going to be getting released as a playable Beta SOON!  Just don't ask me what SOON means okay?  I mean - you think we have the budget for a product lawyer?  Heck we can't even afford LegalZoom stuff.  Jeez.  Soon means as soon as we get it out is what SOON means.  Okay?  Got your towel?  Good.  Remember, don't panic.

Okay.

So - I'm going to keep cronicling - I mean chronicling - I mean adding stuff - to this blog as we go along.  Maybe others in the team will too - maybe not.

Yes the professor posted our grades.  No you don't get to know how bad - uh - I mean - whatever.  Forget it!! Move On! No - we are NOT endorsing any kind of political hack - I mean - whatever...

Next Blog Post - Sprites!  Sounds!!  Music!!!!

Great Job Team C!

Looking back on this quarter of SE591 combined with SE491 last quarter, our group has come a long way to say the least! Each of us has gone from knowing very little about Lua (at most) to becoming quite adept with coding in it, particularly of course with how it is used in the Corona SDK. I believe I was the only team member who had some experience with Corona prior to this project, though I was still very much a beginner. Based on those humble beginnings, I am very impressed with how far we have come and the quality of the product we have created.

Overall, these 2 quarters combined have been a great learning experience. This has been an exciting and productive project to work on. I was very impressed with each of our team members and the effort they put into our project. Going forward, we plan to continue as a team to improve the game and continue with our original plan to release it to a wider audience on the Android Play store and hopefully onto the Apple App Store as well.

One other note for this last blog entry of the quarter is that one of the things I have noticed while working on the project is that the mobile application development ecosystem seems to be expanding quite a bit. There seem to be at least a few other platforms in various stages of development that seem to be preparing to give Corona some competition (e.g., www.lanica.co, to name just one, which according to the website, includes among its founders one of the co-founders of Corona). It will be very interesting to see how the various platforms come along as time goes on and how the development experience on other competing platforms compares with Corona.

"...and that's a wrap."

Well, this week the team and I spent time wrapping up any final details and issues left in the product before our final presentation and demo.  We came to an agreement as to what issues should be addressed, what "low hanging fruit" could be fixed or implemented and what to leave alone.  Since we are under a hard deadline there are many issues that we simply have no time to fix. (for now).

Shortly after the quarter ends we plan to continue our collaboration with the goal of seeing this project reach completion.  We are quite simply too invested in it to just let it die.  We are all in agreement that we want to develop all the features that the original plan called for.  We want to take the time to polish the graphics, the gameplay, the level design and the story; we want to release it on somebody's app store (Google Play or Apple App Store or Kindle?  we are unsure right now. maybe all three.)

Above all else, we just want to be able to say, "Hey, you know that mobile game 'Flights of Fancy'?  WE did that!

JSON and the boolean medusa

John had provided blessed silence - added a mute button.  Just one thing tho - state was not being saved from scene to scene.

I figured since I had grasped that nettle before it would be a fairly straight forward task to add the mute state to the other options that were also being kept.

And as we all know, the road to hell is paved with good intentions...

It all started so simply.  I wasn't sure if the Corona SDK JSON module would save anything but a value inside quote marks - the typical "this is a string".  So I started out using "true" and "false" as values in the save state for muting a scene.

Uh oh - John was using the value as a boolean.  Snap.  That's when I thought to see if the JSON routine would save it as a value without the quote marks - and was happy to see that it would.  Awesome.

Except - when going thru the game - the file would get saved with quote marks and errors would get thrown.

Poor Medusa...

Several hours later I removed all the places where I was writing the value wrapped in quotes - and happy day it worked.  So - level one and two have the code that saves the state and sets the mute button based on the state value when the scene starts up.

A couple of housekeeping measures this week too.  Added boss ship movement and shooting to level 2.  The boss shooting had been in the code - just wasn't getting fired due to a small type in the function call.  Level 2 uses different planes from level 1 - and I randomized hits to the enemy planes, you have a 1 in 2 chance of making a fatal hit.

Oh - Professor Jia had suggested our team create a poster for the final presentation:

TBowers Week 9 Report

This week felt like it was spent mostly buttoning up the final product. From a product standpoint, I spent the majority of my time testing our current offering in the simulator and on a Nexus 7 to see what bugs or UI issues I could find and fixing those. The good news is the number of issues discovered is significantly decreasing since we have unofficially frozen the introduction of new features and are focusing on quality and testing. From a process perspective, I created our weekly tag as well as experimented more with importing our code base to BitBucket. Hard to believe we've hit the 20th beta (averaging more than one a week).

Next will be preparing the final set of documentation for the project. This includes the group documentation as well our individual document enumerating our accomplishments. John has provided a great Visio diagram showcasing the interdependencies among modules throughout the game. It serves as a nice technical architecture diagram that will be a useful reference in the future.

Bug Fixes

In our usual Saturday group call this week (3/2), we discussed, among other things, our plan going forward. Since there are only a couple weeks left until our final demo, we plan at this point to work mainly on bug fixes. It was also mentioned that we should plan to do regression testing any time we make changes in order to monitor closely for any unintended repercussions of our bug fixing. We all agreed that we don't want to introduce any significant new features that could potentially cause issues.

A couple of the remaining bugs that we discussed which I hope to resolve this week are:

- The bullets rotate when the player ship rotates. I'll look through the code to see if I can pinpoint why (and where in the code) this is happening.
- On level 4, when an enemy bullet collides with an enemy ship, the bullet rotates. I plan to resolve this by adding a fix so that enemy bullets do not actually collide with enemy ships.
- Multiple healthbars appear, one on top of another.

Something else I would like to work on this week if time allows is to try to improve the explosion effects. However, depending on how long it takes for me to fix the bugs I have outlined, I may not have time to work on this task. I also will get started this week on my final individual write-up (the summary of my individual contributions).

Week 7 Accomplishments

One significant accomplishment this week was that Travis was able to get Twitter & Facebook posting functionality working. We can now accurately say that our app is 'social'. I ran builds to test them out on my device and both are working now! Great work, Travis!

What I did this week was focus some more on the bugs still appearing in Level 4. A couple of the fixes I added this week were:

- When the player is killed on Level 4, the enemy planes continue to fly across the screen. The cause of this problem was the fact that the "drawEnemyWave" event was not being removed. I added a removeEventListener function to resolve this.

- The enemy planes were still remaining on the screen when the end of Level 4 was reached. This was a simple fix. The problem was simply due to the planes not being removed. I added the following code to resolve this:

    for i = enemyGroup.numChildren,1,-1 do
            local child = enemyGroup[i]
            child.parent:remove( child )
            child = nil
    end

Also, I was getting an error this week that points to the json.lua file. Specifically, the following error was appearing, which referred to line 309 of our json.lua file (in method decode_scanString):

base.assert(stringEval, 'Failed to load string [ ' .. stringValue .. '] in JSON4Lua.decode_scanString at position ' .. startPos .. ' : ' .. endPos)

This ended up being an issue with the Twitter code we had in the game.

One topic of discussion in our Saturday meeting this week was the question of whether an android package file (.apk) can be unpacked into the source code that was used to build it. I will do some research into this to see what I can find out.

Forward Movement

This week (week 6) I finally added the forward movement in the accelerometer that I had meant to get to a while back. I also fixed the warnings that were being thrown when playing the game on a device (i.e., using the accelerometer). In addition, I was able to fix a few bugs that were appearing in Level 4: 1) a single collision no longer kills the player, 2) the healthbar now gets incremented when the player is hit, and 3) the pause button now pauses all elements on the screen (previously it was not pausing the enemy planes or the generation of enemy bullets).

In this week's Saturday group call, we talked about trying to find a Corona and/or Lua debugger. One of the tools discussed is a debugger called "Lua Glider". I downloaded it and installed it on my mac, but was running into problems when trying to run it. When I start it up it says "Background scanning of projects..." and, according to the display, the process is stuck on 92% and does not advance past that. So far, I have not gotten the software working on my mac. I will plan to download it on windows partition and see if it works better there.

Another thing we did this week was start putting together our PowerPoint presentation to prepare for the demo coming up next week. Going forward from now, we plan to focus mainly on what additional features we hope to be able to add to the game between now and then. We also have some bugs that still need to be fixed.

Short and simple

This update is short but simple.  As the class is winding down, we as a team are ramping up our effort towards bug fixes and putting more time into addressing the overall stability and quality of our game.  That's what I'm doing currently and as the "PM" I I've been keeping abreast of progress from the others as well.

TBowers Week 8 Report

What I've liked about our team is we all come from diverse, yet similar, backgrounds. We mesh really well and I've come to really respect and appreciate the opinion of everyone on the team. Yet it still feels like we're nearing the end. At least so much as the class is concerned. We've already discussed how we can continue the work of the team beyond the scope of DePaul. Subsequently, I researched some alternative source hosting options and ultimately created a repository for us at BitBucket. When this course is over, we will migrate our source to them for private hosting and continued work (which will be nice).

I also have been working on being able to demo the final to the class. We need to be able to demo a native build on an Android device in order to show functionality that isn't available in the simulator - in particular  the method in which we've integrated Twitter and Facebook. I think I have a solution, whereby I use a desktop application to remote debug a Nexus 7 that allows me to pull screen images off at a decent frame rate.

First I had to download the driver for the Nexus 7 from Asus. Then, I had to enable USB Debugging on the device through a weird (though neat) little technique where you go into the Settings and About info and tap the build number 7 times; enabling a developer settings menu. Then, I ran Droid@Screen, to get this image.

Like I mentioned, the frame rate isn't stellar but it works. I've also been trying to get MyMobiler to work which seems to offer a better experience but I have yet to get it working.

Good stories need an ending

A number of things got added this week.

Option menu got changed again - added a button to the scenes that allows the player to click it.  And cleaned up a lot of code so as to use it!  Now a user can turn the auto fire on/off and change sides.  Once those picks are made they return to the start of the scene they were playing - and not go all the way back to the main menu.

I was looking for a new background map.  We were finding the farmland one I added a bit too dark - and I wanted to get some other backgrounds in the game anyway.

I had used a tool I found from Spiral Graphics called Genetica - they provide a viewer so you can do very minimal manipulation of their files.

So I grabbed two more - their croplands and one called Cherry Orchards.  It was their cropland file I ended up using and adding as a background to a couple of the scenes.  I still need to lighten or replace the farmland graphic.

Now for the fun stuff - I added an ending to the game.  There is a final battle with zeppelins:

Then just as our pilot thinks things are looking good - well he is in for a bit of a surprise...

Splash screens to give the sense of a serial:

And some kind of logo:

Some refactoring also took place.  I noticed that when playing enemies could get hit even before they were dislayed on the screen.  So I added code to the collision handler to ensure that the enemy object would have to cross a certain threshold before the collision with the bullet would actually do anything.  Now you have to see the enemy object on the screen before you get to shoot them.

Next up - enemies were showing up partially off screen.  Which wasn't so bad until I added the zeppelins in the final battle.  Half a zeppelin isn't as good as a full one - so I refactored the randomizer that set the initial x coordinate for the object as it was created.  Now when an object is created it gets fully displayed on the players screen.  That code is in the majority of the scenes and I need to continue moving it to the rest.

Last - we have a hit counter for a boss and for the player.  But nothing like that for the rest of the enemies.  And ran into a bit of a conundrum - the player is an unique object as is a boss.  But the rest of the enemies aren't.  And I couldn't quickly come up with a way to keep track of the hits done to a particular enemy object.  So I put in a hack.

In level 3 and the end level there are two different enemy types that get created for the screen.  In the event handler for a particular enemy type I added used the math.random library to give me an integer between a certain range.  So in level 3 you have a 50-50 chance to blow up the second enemy type with a shot.  In the final level you have a one in four chance to blow up a zeppelin with a shot.
 

Pre-Game Prep

This week I spent my time banging my head against the proverbial wall trying to get GGTwitter to cooperate with me in anticipation of the coming class demo.

Then late in the week Travis made an awesome discovery.  Instead of doing Twitter integration "natively" by calling APIs from within the application, we could harness the fact that our devices have web browsers on board that our applications can also utilize.  Essentially what was discovered is a small piece of HTML code that posts "Tweets" directly from a browsers address bar.  By calling this code in our app, the device recognizes the code as html, opens a browser within our app and makes the tweet (also allowing the user to log in if they aren't already)  Awesome!

Yeah, I know it's not exactly what we were going for, but it works and it's simple.

The rest of the time was spent doing small code cleanup and debugging while trying not to step on anyone else's toes or introduce any more new bugs while the team prepped fro the class demo.  

Guest Blog - Tom Resource

Hello gents, Lee’s spawn here to report my observations on the latest version of the project my dad showed to me. It is coming along rather nicely from the pre- pre- pre- alpha build I got to see after Christmas! I know I, realistically speaking, threw everything I could think of having to do with the shooter genre at you guys with a story tacked on to hold it together and am rather impressed with what you’ve managed to come up with so far. Along with that, I took a very “see what sticks” approach to the throwing, and having gotten a chance to test it out live on Pop Greffin’s Kindle, I got to see how those ideas are working and playing out in real time.

 Storyline wise, the only real concern I have is a clear differentiation between the two opposing sides. This ties into gameplay, as the version I was using didn’t allow a clear choice and kept forcing me to fight against the British. This is tempered, of course, with the realization that there is still a bit of work to do on this extreme coding adventure of yours, but I really worry from a consumer point of view that instead of buying a game with two different yet parallel storylines, they will essentially be the same. Then again, might also just be me and my big mouth running off into the sunset again.

Gameplay wise, the one feature I am really curious about is inclusion of some kind of limited-fire secondary weapons to add some variety to the normal tap-to-shoot gameplay. Again, having tried it out in real practice, I have no idea how ya’ll would go about implementing such a thing, but that was the only major concern I had in that area seeing as they were something of a value in the write-up I made for you.

Other than that, looks good and like a solid step forward. Lee’s spawn, out.

Resource Tom will be checking in from time to time to give pointers, observations, blah...

Liars Figure and Figures Lie...

Did I say that?  Oh my, get out the Phels Naptha soap and get ready for some soap chewin'...

Seriously (well - for me anyways), for this week we have the first of two presentations to make for the group.  I volunteered to get some stats for our work since Q1 of this course.

Well being a programmer - which is a definition of an individual who will do prodigious amounts of work for hours and hours so as to get out of a few minutes of repetitious labor - I found on the intertubes a nice (free! Who can not say free is not nice!!) tool that works with Subversion and does all my work - oh wait - snap - provides analysis, graphs and charts - of what we've accomplished in a fairly short period of time.

The tool is StatSVN- and you get it from here.

Now, I admit I love point and click.  Meaning this whole command line thing just - well - it's not my thing.  So read the darn readme file that is included in the project.  Then kinda think about it.

Meaning - it's a Java file.  Java is - simple?  crippled?  stoopid?  Idunno.  Anyway the absolutely brilliant statsvn.jar COULD NOT FIGURE OUT SPACES IN THE FRIG****G FILE SPEC - sorry, give me a minute - there my mind is back to the right way of thinking....

So.  I re-checked out our SVN branch file to a more kindly file at the root of C (no - this isn't a Sousa march dearies - we is programming now) and then re-followed the instructions.

Oh frabjous joy!  I got the report.  And I'm really impressed.  There is a huge amount of value in using this truly brilliant Java file.  It does a huge amount of work based on the svn.log file that you need to create.  It's well worth your time to figure out and use.  Truly.  You need to do this.  Why  are you waiting?  Do it NOW.  There - dont't you feel better? 

Oh, you didn't do it - well...

DO IT!! NOW!!!

Okay - so besides this I actually did some programming work this week:

1. Fixed the pause bug for the autofire feature
2. Using LuaGlider got rid of warnings/errors in the training/intro code
3. Error/warnings in 'the choice'
4. Added more functionality to the options menu:

The messaging object at the top of the screen tells you what you have picked in terms of autofire and which side you are helping.  And if you make a choice the text changes.  To get back to the main menu you need to click the Main Menu button - so if you have difficulties making choices you may be here a long long time indeed...

Next up - a guest blog entry from Resource Tom!!

TBowers Week 7 Report

This week has been spent, as is becoming more common, fixing bugs and trying resolve the numerous warnings across the code base. On the new feature side, we appear to have a functional implementation of Twitter and Facebook. It took a lot more time than expected integrating these features but it was one non-gaming aspects of Corona we really wanted to explore. After exploring various libraries that purported to facilitate to integration with the two networks, we finally found some success.


A side  benefit of creating our developer Facebook account was the ability to create a community page for the game. This can help serve as both advertising for the product as well as a social page for fans of the game (with and without Facebook accounts) to meet.

Work will continue on the bug fixing side, trying to ensure as much quality as possible in the few weeks we have remaining.

Advanced enemy movement

I've been hell-bent on getting some really cool advanced enemy movement patterns written for our game.  I was truly happy when Lee found a Corona SDK demo showing how this is done with Bezier curves.  Essentially you draw an invisible (or fully transparent) Bezier Curve on screen and write methods to have each enemy plane "follow" that curve from beginning to end.  This didn't sound too bad.  So I thought I'd give it a go.

Yeah right.

The author of the demo, as well as several others that I have subsequently found, never give the full demo source code, nor do they explain the intricacies involved.  It seems as though these authors are using their demos as part of their online portfolios for potential employers to peruse.

John has been coming up with some good standard linear movement patterns that will have to do for now, given the time constraints of the project.  I want to focus on the team delivering a fully playable bug free app.  The bells and whistles can wait till later when we continue to develop the app outside of class.

Social media is simply a moving target

Social media is simply a moving target for developers wanting to write cross-platform apps.  Twitter integration "almost" works now in our app, but I have run into several article that point out that the cose I'm writing should work for Android devices (and Kindle) but not iOS.  Why is that you ask?  Because Apple likes twitter so much that they integrated twitter right into iOS.  This greatly simplifies accessing twitter from within a native iOS app but does nothing but complicate the issue for cross-platform frameworks.

Corona SDK will address this in a future release but for now we're stuck with checking the target OS and writing the appropriate code.

As for "Flights of Fancy"; we will be forced to develop only for Android/Kindle for the moment.

TBowers Week 6 Report

This week was spent working on bug fixes, evaluating a great new Lua IDE Eric discovered, and implementing an level skip feature for internal testing.

Everyone has been on deck this week on the bug fix front following the discovery by James that the last beta we released exhibits strange runtime behavior on the target hardware only. Everything appears fine in the simulator but when running on an actual Android device, the boss doesn't appear to take damage. It is a very strange issue - this sort of inconsistency between simulator and target hardware hasn't been seen before. Based on yesterday's meeting, the current theory is the json library inside our code base (required for the twitter integration) may be conflicting with the json library built natively into  Corona. The why part isn't exactly known at this point but we are still working it.

As I mentioned, Eric discovered and subsequently suggested we all try the Lua Glider IDE. In just a few days with it, I think we all already wish we had started using something this high quality all along. It has built in support for the Corona SDK with realtime debugging that has already proved invaluable. Additionally, it automatically calls out and highlights potential errors and warnings. Running our project through this environment has exposed a lot of issues (mostly minor but numerous in nature) that we need to work through and try to correct to increase quality.

I also had time to implement a level skip feature for our internal testing. I added a global debug_build flag that can be checked anywhere. When the pause scene is created, it checks for this flag and adds an additional button to cycle through the available levels. Once you have the one you want picked, hit the "jump" button to set the selection and then unpause. When the originating scene resumes after the pause, it checks to see if it should perform a level skip and if so, it automatically transitions to that scene. The OO nature of the storyboard API makes this sort of jumping clean and consistent. Hopefully this feature will help us in testing issues within specific levels without having to constantly play through the game itself.

Beware the widget



The Jabberwock, as illustrated by John Tenniel

 

"Beware the Jabberwock, my son!
The jaws that bite, the claws that catch!
Beware the Jubjub bird, and shun
The frumious Bandersnatch!"

 

So, I wanted a simple drop down list so a tester/player could pick a scene and then go there.  I didn't find what I wanted, but there was this nice feature of the Corona Widget object library called the newTableView:

 

Looks good, maybe more complicated than what I need but the code looks straight forward (okay, not as easy and straight forward as old school classic VB 6 - but not as weird and hard as Visual C++ MFC of the same era - and once again I'm dating myself...)

 

The demo's I found here and here provided the basics - but!  I need to incorporate this inside the Corona Storyboard construct.  And that is where the fun and games began...

 

Now a mea maxima culpa is in order - what follows is probably due to my being overzealous in getting rid of memory issues.

 

I created two arrays - one is a straight forward array with the names of the scenes in order that I want to provide.

 

The second is an array of arrays used by the tableView object.  One of the weaknesses in using Corona is the documentation is sparse and terse - just enough to get you into trouble - but the stuff you really need to know is found in the forums. From what I've figured out is the row construct in the list allows you to have a picture object, a title and then descriptive text. There may be more, but this is far more at this point than what I really need.  Hence an array of arrays - or to use the Lua way of thinking - a table with individual rows that could contain a number of fields (columns) greater than one.  Let's move on.

 

He took his vorpal sword in hand:
Long time the manxome foe he sought—
So rested he by the Tumtum tree,
And stood awhile in thought. 

 

Got my lists, got my tableView, and wow - it actually displays what I want!

 

 

It's just that the damn thing crashes when I do a selection.  This one got me. 

 

And as in uffish thought he stood,

The Jabberwock, with eyes of flame,
Came whiffling through the tulgey wood,
And burbled as it came!


 

So I unsheathed my vorpal sword - er, I started to really use the Lua Glider debugger.  Need to go back a bit here.  In my desire not to create any more memory leaks I had made sure in the storyboard function scene:exitScene I set any variable I declared to nil.  And that was the source of my errors. 

 

One, two! One, two! and through and through
The vorpal blade went snicker-snack!
He left it dead, and with its head
He went galumphing back.

 

The errors were just - weird.  Didn't make sense.  And here is where using Lua Glider saved the day (used as my vorpal blade).  I set a break point for the listener function in my code - the code that gets fired when a user clicks on a selection in the list.

 

And as I expected the code worked perfectly - selecting the correct item in the selection array based off the event index.  But then we went down the rabbit hole...

 

It turns out after all of that the storyboard code kicked in.  The exitScene code got called - setting all of my variable to nil.  Oh - and then the listener function got called again - and since everything had just been set to nil it set off errors - oh my...

 

Okay, I'm sure my code isn't the most efficient at this point.  Why the listener function is getting called twice I can't answer.  However I did learn a valuable lesson here.

 

"And hast thou slain the Jabberwock?
Come to my arms, my beamish boy!
O frabjous day! Callooh! Callay!"
He chortled in his joy.

'Twas brillig, and the slithy toves
Did gyre and gimble in the wabe;
All mimsy were the borogoves,
And the mome raths outgrabe.

 

Clearly, at this point in my Lua/Corona development the ONLY stuff I should be setting to nil (null) in the storyboard scene:exitScene function are those objects that get inserted into the display view/self view group.  Anything else - well as the maps used to say here be dragons...

 

Cross posted at my other blog Greffin's Feather





Bugs and Options

This week has been a combination of extending the UI and continuing the debugging.

As a team we started using Lua Glider as our main development platform for working on our game.  I had installed a demo version of Corona Project Manager – which is now known as Outlaw – and worked with it for a short while.  I just liked Lua Glider better.

Lua Glider has a lot of hooks into our project tools:

·         Works with Corona SDK

·         Provides debug capability with the ability to set breakpoints with Corona SDK

·         Works with both Subversion and Git

·         Works with Bugzilla and JIRA (no plug in that I can find for Mantis BT)

So it’s been a week of tracking down and taking care of bugs using Glider.

The more interesting part of the week has been adding an options menu to the game.

If you tap twice on the of part of Flights of Fancy (note the elipse around the word) – and then click the Play button:

You get this menu screen.

Set Auto Fire – this button either turns it on or off.  It does a read/write to a save state JSON file.  Code has been added to the scenes to utilize this - and I've found a couple of 'features'...

First one - I've not commented out the tap listeners in the scenes.  So you can double the fire rate by allowing the autofire to go, and them supliment the rate of fire by tapping like mad.

Second 'feature' - in scene 3 where there are multiple enemy planes - the shots coming from the player can show two bullets side by side.  Nice!  Just need to be able to replicate it as a feature later on!

Change Side – this button changes the side that you picked – so if you started working for the  Allies you now work with the Axis powers and shoot down your former buddies.  Again, does a read/write to the same JSON file.

After selecting either of these buttons you go back to the main menu screen.

Do Intro – this button allows you to redo the intro/training missions.  Once pressed you go immediately to the first scene of the intro.

Scene List – this one took a bit of time to get in.  Clicking this button displays another screen:

 

This screen uses a Corona Widget table view object.  It’s a bit cranky, but when it works it opens up the scene that gets picked from the displayed list. 

I'm going to write another post on an issue I ran into using this object.

Debugging Latest Issues

We've just recently discovered issues when running the app on a device. What happens is the app locks up on the training level. What is strange about this is that when running in the simulator we don't see any error messages or warnings that indicate problems at that point.

To try to get to the bottom of this, I started looking into ways to debug an app while it's running on a device. I had already installed the android sdk on my pc and figured there must be some debugging capability built in. I looked around and found a pretty good amount of documentation from Google (and other sources) on how to use it. Here is a summary of one way I've found to do some debugging.

- I first connect my device (Galaxy S3) to my windows pc, where I have the Android SDK installed.

- Then I open a command line in the folder android-sdk\platform-tools, which is where the 'android debug bridge' tool is found (adb.exe).

- Then, I make sure my device is recognized by typing adb devices (I had to install the correct driver from Samsung because it wasn't recognizing it at first).

- Then I type adb logcat Corona:V *:S. I found that tip here: http://developer.coronalabs.com/forum/2012/08/08/debugging-device-tips-and-tricks

- Then I launch the app on my device. The display messages and errors now show up on my pc in a terminal window while running the app.

Looking back, it would have helped if I had figured out how to do this from the beginning so we could monitor for issues all along! Ugh. But we haven't run into this type of issue until now where the app runs into problems on the device, but not in the simulator.

Although I still have a ways to go to know what the problem is, I have made some progress while debugging. At first I was seeing a runtime error that seemed related to the ship rotation that I had put in over the xmas break. Error message was:

Lua Runtime Error: lua_pcall failed with status: 2, error message: ...level1.lua:485: attempt to index upvalue 'ship' (a nil value)

So I removed the ship rotation from the code to see if that fixes the problem. But now while on training level 1, I see this each time I destroy a ship:

Lua Runtime Error: lua_pcall failed with status: 2, error message is: ...x folder/depaul se491/Flights_Of_Fancy_Main/json.lua:309: Failed to load string [ return "totalScore"] in JSON4Lua.decode_scanString at position 2 : 14

The game continues to run fine for a bit, but after that message pops up in the terminal a whole bunch of times (once for each time I kill an enemy ship), the debug terminal stops logging the messages. Then shortly after that (sometimes after the boss appears, sometimes before) the app locks up. 

Still debugging, but that's latest I'm seeing. Hope to make more progress this week!

Offering the red pill...

So this week is about choices. 

The player was given the ability to make a choice during the demo/training scenes - but we weren't doing anything game wise with the players pick, at least up until now.

I've got a version in my SVN repo for the team to demo - now if the player decides to assist the Axis powers he/she gets to shoot down what would usually be the good guys airplanes.

Let's start with Snoopy's favorite ride - a Sopwith Camel.  This is currently the default Allied ship the player is going against.

Keeping with the RAF motif - the second enemy fighter the player goes against is a S.E.5a.

And the boss is a RAF RE.7 two seat light bomber/recon/fighter.

So, how does this work.  We  have two modules - a background and a ship module.  Using the JSON file created when a player makes a choice in level 0 -

local playerScore = require "playerScore"

local mySide = playerScore.whichSide() --pulls the value from the mycurrentstate.json file

some function()

     if (mySide == "A") then

         --do some Allied stuff --I love warm beer and haggis

     or

         --do some Axis stuff --I love bratwurst und sauerkraut!!

     end

end

 

This way the 'knowledge' of what choice the player makes is only available to those modules that need it. 

 

However this isn't going to be as pure as an OO narzi would like it to be.  I'm thinking to keep things compact and easy we may well have to have various scenes in on the players choice - some things may happen different depending the story line specific to the side the player chose. 

 

And I added a new background to our game:

I found this site:  http://www.spiralgraphics.biz/packs/terrain_civilization/index.htm

If you download and install their Genetica viewer you  get access to a lot of images, then can change the image size, then save it as a jpeg or png file type.

Once I saved an image I used Paint.NET to carve out the final image and size it to fit our game.

 

The red pill reference - that's a rabbit hole for another time...

TBowers Week 5 Report

This week was spent mostly trying to create more unit tests for the system. It's been as much (if not more) of a challenge than expected finding predictable chunks of code that can tested on there own and give some sort of test driven development aspect to the project. I have successfully integrated a debug only menu into the game itself that allows a tester to run different test suites right from the device. This should help out should results vary based on platform. I plan on continuing pulling out pieces and slowly building up the amount of suites we have on hand.

In addition, this week the rest of team made great strides in refactoring the code base. The number of levels is expanding to a respectable number and we have some ideas how might be able to provide a stark contrast in appearance using different graphics depending on which "side" of the fight the player has chosen. I think this will allow us to reuse most if not all of our code and provide a rapid way to effectively double to amount of levels perceived by the player.

Also worth noting is a great tool Lee has provided us that acts a standalone demonstration of animating a graphic along a bezier curve. With the fighter jet graphic moving along this path, it gives the animation a feel natural and fluid quality. I added this to our repo so everyone can take a look at it. Very cool find on Lee's part.

Moving forward, I am going to work on any bugs we have present with the current milestone and work with James to provide another round of prebuilt APK's to the releases area on subversion. Hard to believe Milestone 1 is almost behind us!

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. 

Potential Memory Leaks

While working on various features (forward and backward accelerometer movement, improved enemy flight patterns, etc), I seem to keep running into confusing and/or misleading error messages. I attribute this in part to the fact that I am not a Corona and/or a Lua expert. However, some of the errors I'm seeing do not seem to make a whole lot of sense. It's hard for me to say as a relative beginner to Corona, but some of the messages may not be completely accurate. At the very least, some of them do not seem to point out the correct line(s) of code causing the problems. 

 

For example, I've been trying to take the code form Level 1 and incorporate it into the other levels. I kept getting an error that was pointing to a null value in the variables bg1 and bg2 (which we are using for the scrolling background images). I tried debugging via display statements, changing various calls, etc., and I was stumped. Eventually, I was able to resolve the problem by changing the name of the methods to be unique to that level. For example, I changed gameloop to gameloopLevel2. Apparently, a conflict was being caused by the use of 2 methods of the same name - even though the methods were in 2 completely different .lua scripts. That may or may not be a function of lua itself. Either way, it would have been easier to debug the problem if the error message generated had somehow pointed that out as a potential cause of the problem. 

One guess I have is that this problem may be related to memory leaks in corona and/or lua. I see quite a few references to memory leak problems in the lua discussions on the www.coronalabs.com site. As I get to be more familiar with the platform, this is one of the problems I hope to get a better understanding of.

TBowers Week 4 Report

I've spent the majority of this week trying to integrate a unit testing framework into our existing code base. While Corona doesn't directly support (or endorse) any unit testing framework, there are a hand full of general Lua unit testing frameworks that have been tweaked to be used with Corona. I am currently experimenting with LunaTest and Lua-TestMore. LunaTest seems to be the more promising offering and that is where I am spending most of the time.

The second challenge is finding areas of our code that are suitable for unit testing. Right now, I am mostly testing what kind of tests the framework supports. Then I will have to refactor portions of our utility code to make it more suitable for unit testing.

While this has proven to be more of a challenge that I originally thought (having been spoiled by JUnit and Java development), I think it will pay off dividends in the future if we can successfully move to a test driven development model and ensure quality as future changes come in.

Moving On

New Stuff

Spread Shot

Added a new ‘spread shot’ feature to the game.  First I tried to do it programmatically, which didn’t work as I thought it would.  Simply put – I was trying to use the same graphic image twice –both images had the same vertical axis but the horizontal axis would be slightly different for the individual shot.  Just couldn’t get it to work.

So, I created a new graphic which has three shots in it.  Looks nice, and is easier to control.  Here is a screen shot: 

New Enemy Plane

Added a new enemy plane which for now debuts in level 3:

This isn’t working as well as I wanted, and I’m going to have to put some more effort into it.  What I wanted to see was first the default red enemy planes, then my new planes, then the boss.  For right now that isn’t happening, the new planes don’t display – so for demonstration purposes I changed the ‘default’ enemy plane to the new one for this level.

Intro Level

I made some refactoring changes here as well.  First of all, I pulled in Jim’s code that provides more player ship movement - it now moves up and down on the screen as well as rotates in the direction of travel.  Looks a lot better this way. 

Travis had originally gotten rid of the health bar and the multiple lives for the intro; unfortunately they both got reintroduced due to the additional code.  Changes were made to again not display the health bar and the additional player lives.

Lua IDE’s

Downloaded and installed then started working with two Lua/Corona SDK IDE’s:

·         Corona Project Manager – now known as Outlaw

·         Cider – now known as Lua Glider

I’m more impressed with Glider but I’ll be playing with both off and on.  My original editor was TextPad which I still like – but it clearly does NOT have all the features a full blown IDE has.

One thing I liked about Lua Glider, and should see if Outlaw also has – Glider ‘understands’ Subversion.  I was able to look at the back history of modules (as long as comments were posted to the SVN commit).  Very nice feature.

Flight paths

Well, I continue to plug away at the twitter thing.  It turned out that it was making calls to other libs that were not included and I had to hunt them down.

It still doesn't work, but I'm at least a step or two closer.

In the mean time I have also been investigating advanced enemy flight paths.  It seems the most common way is to draw an invisible bezier curve on the screen and have the enemy ships "follow" the path.  Ok, how do we do that in Lua on the Corona SDK?  I have no idea (yet).  There are quite a few game authors out there who have managed to do this very thing in Corona SDK and they are very quick to show off their efforts with cool YouTube videos of bezier curves and objects following the curve paths, etc...

But none of them has been forthcomming about HOW they did it.  No source code or even examples to be found.

I won't give up though.  If they can do it so can we...

The Twitter "Developer" experience

Well, integrating Twitter into FoF is going better than the Facebook experiment.  Registering an app with the service went rather smoothly.  They didn't ask for any invasive personal information like FB did.  The only thing that was required was to have a Twitter account, which I did not want, but I made one anyway for this class and will delete afterwards.

I received my consumerKey and consumerSecret numbers rather quickly.

Once those were in hand I added code to our game that would take care of connecting to Twitter, authorizing the app and posting a "tweet" containing the players high score and level achieved.  The code came from a freely available library obtained on the 'Net whose specific purpose is to do all the Twitter "stuff".  Sweet, Right?

I have yet to get it to work :-(

I have nothing else to blog about today as I am busy messing around with this task.  I hope yo have actual results soon.

-E

Plugging Memory Leaks in Corona

I’m finding out that Lua is not as forgiving a language as I had first thought.  These were the changes I made in level0 to get rid of the various memory leaks I had created.

Destroying Objects

This was the most obvious thing to do, and so became the first order of business.  We have been inserting objects into a self.view group – and that order of removal is a very important thing in Lua.

Using this article on removing objects properly as a guide I found a number of things.  First just removing an object from a group isn’t enough for the garbage collector – the reference the variable is pointing to must also get removed.  So there are two steps to destroying an object – first is to remove it from a group by calling the group:remove( object name or index ) or object:removeSelf() methods.  Then you have to set the object = nil to remove the reference.

But wait – there’s more!  The order of removal from a group is also important.  In fact a common pitfall is to iterate thru a group in a normal forware fashion – which may in fact skip every other item in the group.  I’m going to copy and paste the relevant section from the above link here:

Common Pitfalls

A common mistake is to improperly remove all objects from a group. This typically happens when you write code that iterates through a group attempting to remove each child from the display hierarchy. It’s natural to iterate through the group in the forward direction. However, this can cause no end of confusion.

Continuing with our solar system example, consider the following where we attempt (incorrectly) to remove all the objects from the solar system.

for i=1,solarSystem.numChildren do

        local child = solarSystem[i]

        child.parent:remove( child )

end

The problem here is that we are modifying a collection (i.e. the group’s children array) as we iterate through that same collection. The result is we remove every other child. The easiest way to illustrate this is with a parallel example involving an array of integers:

local array = {1,2,3,4,5,6,7,8,9,10}

print( table.concat( array, " " ) ) --> 1 2 3 4 5 6 7 8 9 10

 

for i=1,#array do

        table.remove( array, i )

end

 

print( table.concat( array, " " ) ) --> 2 4 6 8 10

The fix is to iterate backwards.

for i=solarSystem.numChildren,1,-1 do

        local child = solarSystem[i]

        child.parent:remove( child )

end

Of course, this only ensures that all children have been removed from the display hierarchy; you till have to set all references to these display objects to nil. So in this example, we were merely trying to illustrate the highlight the pitfalls of iterating forward through the children of a group and modifying the group at the same time. A good implementation would also set the corresponding properties in solarSystem to nil for proper cleanup. 

So as part of my exitScene function I’ve added the following:

for i=screenGroup.numChildren,1,-1 do

        local child = screenGroup[i]

        child.parent:remove( child )

end 

Then I do this:

screenGroup:removeSelf()

And then set the various objects equal to nil.

We aren’t done yet tho…

Forward Referencing

This part comes from reading this handy article on The Significance of Local Variables in Lua.  We’ve all seen this:

local myFunction = function()

        callback()  -- ERROR: function 'callback' does not exist yet

end 

local callback()

        print( "Hello World" )

end 

myFunction()    -- will produce error 

Refactored this way, the code works: 

local callback    -- forward reference (for later use)

local myFunction = function()

        callback()    -- output: "Hello World"

end

-- function below is still local, because of forward reference

callback = function()

        print( "Hello World" )

end

 

myFunction()    -- no error; happy code :-) 

So I took every function that was not part of the scene template and moved it above function scene:createScene( event ).  This took care of a few ambiguous runtime errors.  This includes the addListeners() and removeListeners functions.

At this point things were supposed to be better, but I started to get screen freezes – holy cow things are getting worse!

Runtime Listeners

I next turned to this handy guide, Corona SDK Memory Leak Prevention 101.  And found this handy scrap if information:

When you remove a display object, listeners that are attached to it are also freed from memory. However, when you add listeners to Runtime (e.g. enterFrame listeners), those never get freed until you manually remove them.

 

A common leak that occurs with Runtime/enterFrame listeners is when a developer adds a Runtime listener to the particular screen they’re in, but they forget to remove the event listener whenever the user leaves the screen. So what happens is, the user leaves the screen, and then when they come back to it, there are two identical Runtime listeners running on top of one another.

Now, we do add a Runtime enterFrame listener with the gameloop code.  I make extra sure that the removeListeners function has the Runtime:removeEventListener('enterFrame', gameloop ) and that it gets called.

Timers and Transitions

Again back to this handy guide, Corona SDK Memory Leak Prevention 101.  I’m just going to copy and paste from the guide:

Timers and Transitions are probably one of the most common causes of crashes, mostly due to the fact that countless (unaccounted for) things could happen between the time the timer/transition starts, and the time it ends. What’s worse, if you forget to cancel these and nil out their variables when no longer needed, things could get stuck in memory and cause more leaks.

One way you could manage these is to store ALL of your timers and transitions in a table, so that when you know for sure no timers or transitions should be running, you can cancel all of them at once.

If you add the following code to your main.lua file (or another module and require it in), you can easily keep track of your timers/transitions and also cancel them all at once if and when needed:

timerStash = {}

transitionStash = {} 

function cancelAllTimers()

    local k, v

    for k,v in pairs(timerStash) do

        timer.cancel( v )

        v = nil; k = nil

    end

 

    timerStash = nil

    timerStash = {}

end

--

function cancelAllTransitions()

    local k, v

    for k,v in pairs(transitionStash) do

        transition.cancel( v )

        v = nil; k = nil

    end 

    transitionStash = nil

    transitionStash = {}

end

Then, whenever you start a new timer or transition, you assign it to the respective table first, like so:

timerStash.newTimer = timer.performWithDelay( ...

transitionStash.newTransition = transition.to( myObject { ... 

Then you can use the cancelAllTimers() and cancelAllTransitions() functions to stop all timers and transitions all at once. If you have timers you don’t want to be cancelled, then don’t add them to the “stash” tables in the first place (but be sure not to forget to keep track of them). 

So I added the above cancel functions to level0, and then call them after the removeListeners call.  I found I could do this in the gameloop function and it would work:

transitionStash.newTransition1 = bg1:translate(0,2)

transitionStash.newTransition2 = bg2:translate(0,2)

 

Things are better but I still was getting some runtime errors – not as many, and no crashes but still annoying.

Proper Placement of Cleanup Code

I was experimenting with the right place to put all this garbage collection code – and in desperation decided to go back to the documentation.  One last link – storyboard.gotoScene():

Description:

Used to transition to a specific scene (determined by scene's module name). Internally, this will handle all loading/unloading of the scenes. Scenes may also be explicitly unloaded/removed by the user.

When this function is called, the "exitScene" event will be dispatched for the currently loaded scene (if one exists), followed by the "createScene" event (for the specified scene—sceneName—if no "view" property is present), and then the "enterScene" event (also for the specified scene—sceneName).

It dawned on me – keep the code in the exitScene and it would always get called in correct order. 

At this point I was about 99.5% there.

Zombie Scenes

Yes, the dead still inhabited the program.  I was seeing calls to level0 when in level2 – no crashes but still getting some runtime errors.  So I found this reference to storyboard.purgeAll().  In cutscene1, the scene:createScene( event )function I replaced the call to storyboard.purgeScene( priorScene ) with storyboard.purgeAll().  Inside the Lua command box I was seeing calls to scene:destroyScene( event ) in both level0 AND train3.  More importantly it got rid of the last runtime errors.