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.