Flight Odyssey on Android Giveaway of the Day!

Flight Odyssey is now featured on Android Giveaway of the Day! Check it out at http://bit.ly/1m4VtsU

Here are some helpful links for new players:

• Demo video
• Description
• Instructions
• Credits and License Information
• The Story of the App's Creation

Flight Odyssey Lite Available on All Major Platforms!

Flight Odyssey Lite is now available on the app store for iOS, Android, and Amazon. Click here to try it for free! If you enjoy it, please leave a review -- if we get at least 10 reviews in a week, we'll release a new plane!

If you're ready to try the full version of Flight Odyssey, with even more planes and no ads, you can click here.

Flight Odyssey Lite: Coming Soon to iOS

If you've been wanting to try Flight Odyssey, but not in the mood for parting with 99 cents, I've got good news for you: Flight Odyssey Lite is coming soon to iOS! It is already available for Android, where we've just unlocked dozens of new levels. Soon, Flight Odyssey Lite will be available for iOS too: we'll keep you posted!

Flight Odyssey Released

We are proud to announce that Flight Odyssey has now been released on the Google Play Store for Android and the App Store and is now also available at the Amazon Appstore for Android.

Not sure? Try it for free on Google Play. If you run an app review site, work in the journalism/media field, or have at least 1000 friends/followers on a Social Media website and are interested in reviewing our game, please contact us at FlightOdyssey+Promo@gmail.com to request a free promotional code.

Here are some helpful links for new players:

• Demo video
• Description
• Instructions
• Credits and License Information
• The Story of the App's Creation

Current versions: v. 1.006-1.028

Closure

Lua and Javascript are surprisingly similar languages, as I was happy to learn (coming from a Javascript background). Both of them are very loose in handling data types, don't require classes, and have a nice feature called closure. That's by no means an exhaustive list of similarities, of course. However, today I thought I'd write about some differences in how each of them handles closure. Take a look at the two code samples below:

Lua:

 
function main()
    local printFunctions={}
    local i,j
    for i=1,10 do
        local printi = function()
            print(i)
        end
        printFunctions[i]=printi
    end
    for j=1,10 do
        printFunctions[j]()
    end
end

main()

Javascript:

function main()
{
    var printFunctions=[]
    var i,j
    for(i=0;i<10;i++)
    {
        var printi = function()
        {
            console.log(i);
        }
        printFunctions[i]=printi
    }
    for(j=0;j<10;j++)
    {
        printFunctions[j]()
    }
}

main()

Both of these would appear to be identical. They create 10 functions which simply print the value of i. Then, each of the functions is called. You would expect the result to be "0 1 2 3 4 5 6 7 8 9," right? That's correct in Lua, but not for Javascript. Javascript prints "10 10 10 10 10 10 10 10 10 10."

UPDATE:
The following explanation is not accurate. See this Stack Overflow question for details.

Inaccurate explanation:
So why does this occur? It occurs because Lua and Javascript handle closure in different ways. Lua treats the closure as part of the function reference itself (see this reference), and therefore each time you create a function reference you get a new copy of the variable. The function is created 10 times, with i having values from 0 to 9 during those initializations, and therefore the numbers 0 to 9 are printed.

Javascript, on the other hand, creates a closure based on the variable declarations (see this reference). Since i was declared in the main function, i can only have one value for each time the main function was called. The main function was only called once, so i has only one value, and that value is 10 at the point when the functions are called.

Perhaps this is better explained with another example. What if we changed the anonymous function to print j instead of i? In Lua, nil is printed 10 times because at the point where the function is declared, j is nil. By contrast, in Javascript, the numbers 0 through 9 are printed, because at the point where the function is called, the j from the main function ranges from 0 to 9.

Hopefully that was helpful to anybody else familiar with Javascript and trying to learn Lua. If anybody else has a better way of explaining the difference, please feel free to leave a comment.

Useful Tools and Thank Yous

Now, I know that my Credits blog post already thanks all the groups who helped make Flight Odyssey possible. However, that was kind of cold and legal, so I'd like to take this opportunity to talk a little bit about each of the services that were most helpful. The purpose is twofold: first, to give out some well-deserved credit, and second, to help other developers who are trying to build apps without a huge infrastructure of support.

Let's start off with Clker.com, one of the most crucial resources in my search for images. Clker.com provides clipart/vector images licensed under CC0 (effectively public domain). It has a huge variety of images, and the price is right! The majority of my images come from this website, so I am incredibly grateful.

That said, let me point out a few caveats that may be of aid to other developers. First of all, the search engine built-in to Clker.com is pretty awful. My recommendation is to just use Google Images, but limit the search to Clker.com using the advanced search options. The other major issue is the ads. When I initially found Clker.com, I was using Chrome AdBlock, so I didn't realize that this was a problem. However, as soon as I switched to Firefox, I suddenly realized the website's ulterior motive in providing this great public service: lots of ads! (In fact, I was so surprised by the ads that at first I though they were being inserted by a virus on my computer.) Related to this is the fact that many images on Clker.com are actually downloaded from openclipart.org, so it may pay to try that site as well and see which you prefer.

Next, Bitbucket. I hate to admit it, but this is my first project where I've used a formal version control system. I can assure you wholeheartedly that I will be using it for my next project as well. At least once or twice I was spared from hours of work by a backup in Bitbucket, and several times the reassurance that the backup was there let me be more aggressive in making changes. To put it bluntly, version control is awesome, and Bitbucket implements it really nicely. Not only do the provide you with free private repositories for up to 5 users, they also have a nice GUI (SourceTree), a decent issue tracking system, and everything you would expect out of a paid Version Control system (despite being free). One caveat: they don't have an official mobile app or a mobile-friendly website (helpful things when testing on devices and reporting issues), but BitBeaker is an Android app which interfaces through their REST API and works nearly as well as an official app would.

Another major issue I've faced in my project is performance. Some performance issues, of course, are related to memory consumption, while others are more complex. One tool, though, that I believe has greatly improved Flight Odyssey's performance is TexturePacker. I first discovered TexturePacker when I read this article/video. Just like Corona SDK, that video made some pretty bold claims about the performance benefits of TexturePacker, but they appear to be true. I'll admit I was skeptical at first, particularly when the initial impact of the software was to increase texture memory usage by a factor of 6 (since all images had to be loaded, not just the ones in use). Nonetheless, when I ran my app on a device, performance appeared to have dramatically improved. I still don't really know how that worked, but I suppose the theories presented in the video must be accurate. Not only does TexturePacker improve performance, it also provides a better way of organizing sprites, unlocks several features of Corona SDK that are only available with sprite sheets (like easy animations), and can decrease the size of the app. The biggest drawback is that it costs $40 to get the full version. Fortunately, you can use the essential mode for free (though it lacks some of the optimizations) and bloggers/framework developers can get a free license for the full version.

Some other helpful tools include GIMP (a great way to fine-tune the free clip art from Clker.com for a specific purpose), Paint.NET (like GIMP but lighter weight), ImageAlpha (for image compression), and Notepad++ (once I discovered that you can create a workspace in the sidebar, I never had to use another text editor).

And of course, this list could never be complete without Corona SDK. I've mentioned before how impressive it is, to the extent that it inspired me to create this app, but it can't hurt to repeat it.

That's all, and thanks for reading! If you would like to suggest any other helpful tools for independent game development, feel free to leave comments!

Demo Video

Yesterday, I set out to create a demo video for Flight Odyssey. I knew it wouldn't be easy, but I expected the tricky part to be the video editing. You see, previously I had tried screen recording directly from a device using adb, but since I was getting frame rates around 0.2 fps (5 seconds per frame), I decided to just record the simulator. It turns out that wasn't much easier.
The first thing I tried was CamStudio, a free, open source screen recording software that I had used previously for a demo. I knew that it was a bit clunky (as free software tends to be), but I did not realize one crucial difference between my past use and this one. The last time I had used this software, I was demo-ing a piece of UI heavy business software. Frame rate was nearly irrelevant as I simply clicked on buttons and typed in text. By contrast, Flight Odyssey runs at about 30 fps, and at any speed slower than 20 -25 it looks unacceptably laggy. CamStudio recorded at about 10 fps, not to mention that there was no obvious way to hide the cursor and record audio.
So, I did a quick Google search and came up with two alternative screencasting programs, ZD Soft Screen Recorder 5.4 and Screencast-O-Matic. ZD Soft started off badly by recording with an odd codec (Xvid MPEG-4 Codec). After I had wasted about an hour trying to view the files it produced (which wouldn't open in QuickTime or Windows Media Player in their default configurations), I finally was able to view them using Aiseesoft Total Video Converter Platinum. They ran extremely smoothly at just about 30 fps (perhaps the odd codec helped?), but of course it was too good to be true - there was a watermark. I didn't want to spend $40 to get the full version of ZD Soft, and I didn't feel it was morally right to remove the watermark (though it wouldn't be too hard, if you left enough whitespace around the part of the screen that you're capturing), so I tried Screencast-O-Matic. Same story.
Finally, I thought I'd go back to CamStudio and give it one more shot. A little bit of searching revealed that even though the "Record Speaker" option wasn't working, this could be easily worked around by using "Record Microphone and setting the speaker as the only input mechanism in the Control Panel. The annoying cursor could be removed with the Cursor Options command. So, all thenmimor annoyances were resolved and only the main problem remained. Suddenly, I realized that there was a menu command called Video Options that I had been overlooking (I'm not sure why). It contained an option to reduce video quality and increase maximum frame rate (set by default to 10 fps for unknown reasons) which I quickly took advantage of.
All was not yet resolved, though. The resulting video, though taken at a whopping 40 fps, was a complete mess. The graphics were blurry and any movement left long artifacts trailing behind. Furthermore, any attempt to increase graphics without decreasing frame rate led the game itself to lag. Ultimately, I found a happy compromise at 20 fps and switched to recording on a desktop computer for better performance. Finally, I had my video, right?
Of course not. iMovie wouldn't recognize the file format that CamStudio produced. So, one last step was necessary - back to Aiseesoft Total Video Converter to convert .avi to. m4a. At last, all was well.
Hopefully that was helpful to anybody else hoping to make a video demo of an app - the video I made is available here on YouTube. Thanks for reading!