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