Saturday, November 24, 2012

Winter Intersession - the Game goes on...

I'm taking advantage of the period between the two sessions for now.  I've started working on the beginning/training missions/point of our intrepid player having to make his/her first in game choice.

So I've started by adding a few new ships to the mix.  Found a bunch of nice top down view graphics, and adapted them to our use.

For the here and now these are the 'canon' images I've added - these should be considered source files in that the in game images have been altered:

First is a background for our training mission:
 
This image is a cut out from the full size below:

 
I wanted something modern and very different from the rest of the game.  But I noticed the transitions were choppy - then I really looked at the image.  It's lighter at the bottom than the top, and of course the small craters or whatever they are don't match up.  So I found another desert type background that is a lot more even:
 
 
I also added a whiteboard:
 
This helps keep the intro-training text in an uncluttered environment.
 
As for ships, I've added  three - first is a training drone:
 
This gives our pilot something to test his/her new prototype GAU-6 20mm Vulcan Rail cannon against.
 
Next is the Zeppelin that may or may not make an appearance later:
 
 
And a steam punk boss of all bosses zeppelin which may make its debut later in the game:
 
From the looks of this bad boy our hero may have just met his/her match.  Kind of excited to see what happens...
 
 
Okay - now in keeping with a tech discussion with our Tom Resource writer - my original question was how do we keep a slightly future tech airframe full of gas and bullets in the time frame of 1917?
 
So I took some liberties.  Our pilot has two X type technologies on board - a Warshawski generator (okay - kudos to the Honorverse BUT Warshawskys has been a huge auto parts seller in Chicago for a very long time...) and the GAU-6 20mm Vulcan Rail cannon.  The current gen Vulcan is a GAU-4 - I added the electric Rail gun so means no cartridge case, propellant etc. to worry about. In other words we are just carrying the things that go out the barrel - nothing else.  The rail gun supplies the motive power.   In a pinch add ball bearings - heck even just washers and out they go at an astonishing speed.  Tom Swift can eat his electric rifle!
 
What's a Warshawski generator you ask?  Slyly I answer - it's the typical Sci-Fi X device that allows this discussion to move forward.  Gives us the ability to take slightly future tech and have it run in 1917 without trying to figure out how we are going to get JP8 or any other type of AvGas for our jet driver.  It's when our plane driver is asked to test full military power that things get - well, interesting shall we say?

Wednesday, November 21, 2012

Installation for Amazon Kindle Fire


General Notes


Flights of Fancy is not yet available thru Google Market or Amazon.  The file needs to be manually downloaded and then installed on your device.

Installation for Amazon Kindle Fire


Download our Amazon Fire Flightsof Fancy apk file to your PC.

If you don’t have a file manager installed, you will need one.  Select Apps, Store and look up either EasyInstaller or ESFile Explorer and install.  Both of these are free from the Amazon Apps for Android Store and are compatible for Kindle devices.

You have to turn on Allow Installation of Applications in your Kindle Fire.  Navigate to Settings, More, Device, and click the ON button next to Allow Installation of Applications from Unknown Sources.  Click OK at the warning; this will get turned off later.  Click the Home icon.

Connect your Kindle Fire to your PC using a USB cable.  Once your PC recognizes it, copy our Flights of Fancy.apk file to your Kindle Fire; then select the Disconnect button on your Kindle to safely unplug the USB cable from the PC.

I’m going to use ES File explorer for the rest of the guide.  Navigate to Apps, Device, ES File Explorer and select it.  Navigate to where you placed our Flights of Fancy apk file.  Select it and a screen is displayed asking if you want to install the application.  Choose Install. 

Once completed, our app is installed.  Now would be a very good time to turn OFF Allow Installation of Applications from Unknown Sources from Settings, More, Device.

We hope you enjoy Flights of Fancy!

Installation for Android devices


General Notes


Flights of Fancy is not yet available thru Google Market or Amazon.  The file needs to be manually downloaded and then installed on your device.

Installation for Android devices


Download our Android Flightsof Fancy apk file to your PC.

If you don’t have a file manager for your device, you will need one.  ASTROfile manager is one often mentioned for Android devices, it’s free and it is available from the Market.  You will need to install it before you can continue.

You have to allow your device to install from “Unknown Sources”; these are non-Market apps.

To do this, navigate to Menu, Settings, Applications.  Make sure the box marked Unknown Sources is checked.

Once you have a file manager installed, connect your Android device to your PC using a USB cable.

Mount the external card and copy our .apk file from your PC to your device.

Once the file has is on your Android device, navigate to it using your file manager and select it.  I’m going to use ASTRO File Manger as the example.  You should get a dialog box that allows you to install our app; select Open App manager.

On the installation pages that follow, select Install.

Once completed, our app is installed.  Now would be a very good time to uncheck Unknown Sources from Menu, Settings, Applications.

We hope you enjoy Flights of Fancy!

Sunday, November 11, 2012

This Week's Progress

One of the items I worked on this week was to fix the bug in level 3, which was showing up only on restart, where the enemy ships did not appear. This was a logic flow problem that I had not noticed before IEric pointed it out to me). While I was fixing this problem I ran into other logic issues which I ended up fixing at the same time. For example, there was also a bug in level 2 where, after restarting, you advance to level 3 after shooting the enemy boss only 1 time. I fixed it so you now need to shoot the boss 5 times to advance, as intended.

Something else I worked on this week was I added explosion effects when enemy plans are killed. Ther eare 2 separate explosion sequences: the first that appears when an enemy plane is shot down; the other, which is a bit larger,  appears when an enemy boss is shot down. These effects are not quite as cool looking as I had hoped. Therefore, I hope to find a chance to revisit these at a later time to improve them and/or add other explosion effects. I implemented the code for these functions within the displayfunction.lua script. That should make it relatively straigtforward to improve upon, since the code is modularized to within just 2 separate functions in that single .lua file.

Another item worth mentioning for this week is the problem I came across when implementing more than one method with the same name (though in different .lua files). I found out that this throws an error. It sounds like you can get around this by removing (or destroying) the functions when you exit that .lua file. I have yet to test this. This was a difficult bug to figure out because the error messages gave me no clue that the problem was that I had 2 methods with the same name. This is one of the errors that our group has discussed: some of the error messages that Corona throws are difficult to interpret.

Cross Platform Craziness

Well, this past week I spent time fighting with Facebook (yet again).  The issue was that you have to register your app with FB in order to obtain an app ID used to authenticate that the app trying to connect to FB servers has permission to do so.

This is not unheard of and is even standard in most distributed type of applications.  The first problem was that you need to be a registered FB developer before you can obtain this ID.  This wasn't a big deal; just the standard "create a new account" stuff you would expect.  It was in "verifying" the account that an issue first manifested.  FB has two options for verification; a verification code can be sent via text message to your cell phone, or you can give FB your credit card information (assuming you have one and assuming you want FB to have this information)
I chose option 1 because I'd rather not give FB my credit card information.  Option 1 never worked for me. the verification number that was sent to my phone was eight digits long and the text box on FB's verification page only allowed six.  I kept getting a "verification number incorrect or invalid" error which then strongly urged me to give up my credit card info instead (I started sensing a pattern here).

Another member of our team had mentioned that he was pretty sure he was already a FB registered developer so he is going to try and register our app under his account.

Issue two stems from the fact that when FB changes their API for connecting to FB servers, the group responsible for the Corona SDK must also change the way the SDK implements FB connections.  As any experienced developer knows, this takes time and resources.  It seems to me that since Corona SDK is still young, its resources are still limited.  Case in point - FB has changed the way iOS 6 devices connect because iOS 6 now has FB connection integrated right into the OS.  Corona SDK has not made the update yet, or at least hasn't documented it yet.

The process to connect via Android is a little different from iOS but doesn't "seem" to have changed all that much in the past few years.  In the interest of time, I may end up just implementing the Android FB connection and leaving the iOS piece for later.

-Eric

Player State

My task this week was to display the players high score.  A simple task yet it lead to several paths...

Okay, so first up was just to display a simple high score.  I built a way to keep this tidbit of information, using the json library available in the corona sdk.

It's nice, what gets created is a essentially a name/value pair list.  Nice and light, especially for this use.  So our game has two of these data constructs - one keeps the current level and score values (it gets zeroed out at the start of the game), then there is another key value pair that holds onto the highest level and score achieved by the player, as well as a simple counter that holds onto the total score number for the player.  Not sure if there is any value to that yet, but we'll see.

So next up was a task to display the high score value.  Fairly easy to do, John created a topScore library file to which I added the functionality to read from the json table, then display the high score.

Well - that was so easy I figured I might as well add the highest level the user attained.  Few more minutes of coding and done.

Okay - but my current gaming obsession is Fallout New Vegas.  Second time around in fact.  And that reminded me - there are achievements in the game based on hitting certain criteria.

So I built a quick if...elseif...else structure and then got some simple achievements displayed.

Nice, but not all that satisfying.  Besides, it just looked like it was going to get clumsy trying to keep that up and running in case the rest of the team liked the idea.

This really needs to be a table based data construct - so I found that lua/corona sdk supports SQLite tables.  Built a nice quick and dirty one using SQLite Admin - and changed the code from the ugly if...elseif...else structure to a sql call to the database.  Took a bit more time to get the correct code but it's in place.

The payoff will be later on - this is a solution a number of other developers use to not just keep player state in but also stats of the various objects in a game. 

Here is a screenshot of our topscore page from the game:

TBowers Week 9 Report

Now that we have started to flush out more behavior in the three levels that we have, we are starting to experience the pitfalls of the current approach and do not want to end up with 20 levels that have a low level of cohesion and instead of components copied amongst each level's file. The break between quarters will hopefully give us a good opportunity to refactor some of the level design into a heir achy that makes sense with common components shared across. How to implement these sorts of OO practices that we for granted in Java or C# is what I spent a good part of this week researching. I picked up a new book to help me grasp some of the best practices which I think we've all started to realize are a moving target and subject to interpretation.

I spent the second half of this week creating our final presentation for the quarter. Then on Saturday, we had our meeting and collaborated on the presentation in real time (a credit to Google Docs). It was interesting to reflect on what we've done, the processes we've adhered to (or created), as well as discuss what's gone well and what hasn't. Overall I'm really happy with the quality of interaction and output from this team, I am glad we will be together again next quarter.

Monday, November 5, 2012

Progress This Week

Some notes about what I worked on over the last week:

I spent some time this week attempting to implement some type of enemy flight pattern logic into the game. I did a lot of research and ended up finding some sample code showing how to implement a "sine wave" pattern. The sample was not specific to a game, but I was able to adapt some of the logic to implement a basic flight pattern, which I put into the code for Level 3. I'm not completely happy with the code. It's not exactly the look I was looking for and plus I was hoping to find something more readily adaptable to other patterns. I hope to find some other ways to improve this aspect of the game going forward. This type of logic seems like an important aspect of game development, so I hope to learn more about how it's done effectively.

Another thing I worked on this week was modularization of the section of the display that shows the player's score. This was mostly done as a proof of concept. I wanted to get the hang of implementing external module calls in Corona. I did some research and found some helpful tutorials on the topic in the Corona documentation. I created the 'displayfunctions.lua' module. This is a very basic module so far, which contains only a few functions so far, but could potentially be a place to put additional logic in order to keep things more logically organized.

On a separate but related topic, I have noticed that some aspects of Corona "best practices" seem to be in a state of flux. For example, I found this 7/6/11 entry on the Corona site on how to implement external modules: http://www.coronalabs.com/blog/2011/07/06/using-external-modules-in-corona/.  I later found this 9/5/11 entry on the Corona site: http://www.coronalabs.com/blog/2011/09/05/a-better-approach-to-external-modules/. The latter entry, written by the same author just 2 months after the former, explains a "better" way to implement external modules compared with corrections to the method described earlier. A comment posted on the later entry notes that a technique described in the earlier entry had been deprecated by the creators of lua.

A Social Dilemma

Getting this Facebook thing going is proving to be a pain.  As I posted earlier, Facebook needs to make doing this easier considering how vital it is to their business model.

I'm setting up an Facebook age for the FoF game and will seek to register the game with Facebook  n order to obtain a registration number.  This number is needed by the code used to log in and access Facebook  from within the game.

This week I also finished implementing the "Post It!" button on the game over screen.  The button transitions to a new screen that contains the FaceBook icon and a Twitter icon.  I'm at a standstill on Facebook  development until I get the registration code from Facebook because without it I can't even test the Facebook  ode to see whether or not it is functioning properly.

In the meantime, I made tapping the icons show a dialog that explains that this function is not fully implemented yet.

Next week I intend to investigate advanced enemy movements while I wait for the access number.

Hurricane Sandy

I'm becoming a veteran of this I guess - last year was Irene, this year Sandy.  I live in a semi-rural area - which means my water comes from a well.  No electricity no water.  However, I do live on a lake, so getting water for other use (think flushing...) is only a bucket away.

We stocked up on water - bottled and filled up a number of water jugs - got propane, positioned tools, camping gear, all the other things that need to be done before the storm hits and power goes out for several days.

We lucked out - lost power for a bit over 24 hours - Monday afternoon to Tuesday evening.

So - after the clean up, got back into coding.  I extended and refactored our scoring scheme - instead of just using a text file, I found that Lua has a fairly robust support for JSON.  It becomes almost trivially easy to have a SQL-less data table get created, read from and written to using the built in JSON library.  So I've got the following libraries:

File IO - general functions to read, write and append files; functions to write to and read from Lua tables.

User State - functions that use the File IO library that write or read user state; right now current level and current score, functionality for highest level and score started on.

Player Score - a centralized set of functions that use the User State library to write out or read from the user state tables.

Code has been added to the main.lua as well as the three user level lua files that writes out the user score.

Plan is to further extend this code so as to have the highest level achieved and total accumulated score to also be saved.

Sunday, November 4, 2012

TBowers Week 8 Report

I spent the majority of time implementing a player health bar. Before, a single collision with an enemy would decrement your lives. Now, the player health is represented by a bar along the bottom and starts at 100%. Getting hit decrements health by 10%. When the health is 2/3, the bar turns yellow and when it's below 1/3, the bar turns red. This should give the player an at-a-glance view of their health status. I also spent some fixing some bugs in how we transition scenes and allow the player to restart the game after dying. I also refactored our pause system into its own scene in the storyboard framework that is transitioned to as an overlay from gameplay. It smokes out the game scene (which is still viewable underneath) and displays "Paused" on the screen.

I think we've had some great progress this week. The social integration with Twitter and Facebook is firming up and starting to look really. Now it just has to be hooked into the actual services themselves which Eric is researching. Lee is using Corona's built in support for JSON for serialization of data out to a file which I think is going to make maintaining state and potentially hooking into game services like Game Center easy to manage. As we move forward with fully supporting more than one level, we want to prevent duplication of code as much as possible. So John and I are taking a look at inheritance in Lua and how might be able to solve some of these challenges.