A few Foxhole controls skinned for Rivers of Olympus

I released the source code a few weeks ago, with no documentation at all and only a brief mention in the announcement for my game, Rivers of Olympus. Immediately, I received a number of requests for more info and general interest in giving the components a try. With the pressure on, I spent a week adding some much-needed features, creating some example code (including a skin, which I left out at first), and finally adding a little API documentation. Things have finally settled into a bit of stability, so I thought I’d make a more formal announcement of the Foxhole for Starling project now.

Here are a number of important links to get you started:

• Github Repository

• Wiki and Screenshots

• In-Browser Demo of the Kitchen Sink Example

• In-Browser Demo of the Display Object Explorer Example

• Example Projects and Skins

• API Documentation

• Bugs and Feature Requests

• Official Q&A thread on Starling Forum

Please don’t hesitate to send feedback. I’ve been having a ton of fun working on Foxhole for Starling, and I’d love to continue making it better for everyone. Enjoy!

As the non-Flash tech community gained strength in arguments against Flash (after getting a major ego boost from Steve Jobs’ famous Thoughts of Flash letter), I knew right away that Flash’s future would be changing. I spent a number of months exploring other, often competing, technologies. This included a look at HTML5 and JavaScript, Corona, and most recently, Sencha (which, I’ll say, confidently, is definitely the best web standards replacement for Flex that’s available today). Not long after, things got quieter on the Adobe front. I was still using Adobe AIR to build games, but I also talked a lot about the competition. I don’t know if this was an intentional reaction to my change in loyalty, or if my Flash work was simply less exciting. I’ll freely admit that a few semi-generic casino games that I built during that time aren’t exactly sexy demo material. Either way, the difference was obvious.

Still, though, I feel like my explorations of other technologies really made a difference in making Adobe technology better. I happened to receive a free one-year subscription to Corona about a year ago, and I took advantage of that time to really kick the tires. It resulted in several blog posts that compared and contrasted the capabilities of Corona and AIR. A couple of the posts were in favor of AIR while a couple were more critical. Most importantly, to me, the things I was most critical about have actually been improved in AIR in the time since I wrote those posts. Captive runtime and native extensions, in particular, are really removing old boundaries that made AIR less appealing (now if only captive runtime file size were smaller). I won’t claim that I had a big part in that. I was just once voice among many who were looking for a better experience with AIR. Regardless, it’s awesome to see things move in the direction that I asked for them to go.

Ultimately, I still somewhat feel like my relationship with Adobe is a little less warm than it was before. I’ll take that, proudly even, because I also feel like I helped in some way by finally deciding to provide some proper negative feedback when it was needed. In years past, I was less likely to speak up (but I was less likely to know what I really needed, as well). These days, it’s usually more clear to me what’s missing or what isn’t ideal. If I need something today, I’ll say it loudly, with more urgency, and less gently. I don’t want to wait years (or even months) for new features, and I don’t want to work around the same old issues over and over again in that time. Maybe that’s asking for a lot, but I just want to get the job done and make great apps and games.

Anyway, my thoughts tonight ultimately came about because I discovered that my game, Rivers of Olympus (you can read about how I converted it to Starling), was mentioned as part of Adobe’s Flash Player 11.2 and AIR 3.2 announcements (including the fascinating announcement of premium Flash Player features). I didn’t know that they would be mentioning my game, and it’s great to see a little nod from my old ally again after so long. Even after many attempts to explore alternatives to the Flash platform, I keep choosing AIR to build my games, and I still feel most at home calling myself a Flash developer. I recently created the Foxhole for Starling project, a set of mobile UI components build on Starling, and I feel like it has reinvigorated my interest in Flash and AIR. It’s been so awesome to see the community show a lot of curiosity in my work too.

I felt very conflicted when I realized that Flash’s future was changing (even before all of Adobe’s big announcements about Flex, mobile Flash Player, and everything else at the end of last year). It became harder as my expectations on the matter were met (and so abruptly). Now, though, I’m feeling like I can confidently keep using Flash and AIR to build games while also transitioning elsewhere for other work. I almost wish this had all happened earlier, so that I wouldn’t have had to ride the crazy waves for so long. Either way, I’m glad that I finally feel at peace with all that has happened in the last year and more. I’m looking forward to my next adventures too.

Note: Until RIM adds Stage 3D support, I cannot deploy the Starling version to the BlackBerry PlayBook. The non-Starling version is still available on PlayBook.

UI Controls

My task for the conversion from classic display list consisted of two major parts. First, I needed to make my personal library of mobile UI controls run on Starling. These older “Foxhole” controls were built on fl.core.UIComponent included with Flash Professional. However, in Starling, I needed to start with a new base class. This meant either porting UIComponent over to Starling or starting from scratch with something simpler.

I decided to start from scratch and personalize things. In particular, I ripped out the styling system and made all styles in the Starling version into regular getters and setters. This gives me stronger typing and keeps code from getting too messy with all the magic strings that Adobe’s style managers often use. I should be able to build some sort of external style manager that injects styles into each component as they’re added to the display list, if I ever need something like that. For now, it hasn’t been too important. I also simplified the invalidation mechanisms to ensure that all components validate completely each frame. In general, the depth of nesting isn’t too extreme, so I feel pretty safe working like that.

The new Foxhole for Starling mobile UI controls are now on Github. They’re severely lacking in documentation and examples (in other words, there are none). They’re without a default skin too, so some assembly is required. Maybe someone will find them useful, though. I wish I could take some time off to polish them up a bit more for general usage.

Edit: I put together a very basic Getting Started page on the Github wiki. For the curious, it simply shows how to create a Foxhole Button control.

The Rest of the Game

Working on Foxhole for Starling was relatively easy, and I could mostly focus on each component in isolation. However, converting a full game’s codebase to Starling was a more daunting task. Not only did I have the basic Starling conversion of the display list (including changing all text to bitmap fonts), I also had to update the code to use the new APIs in the updated Foxhole controls. This left me working through compile errors one by one, with no ability to run my code for a couple of days. That’s a new and scary experience for me. I’m used to constantly running my code to verify that things are working, and even very ambitious refactoring will give me something I can run (even if buggy) within a couple of hours. Once I finally got it to compile, I ran into immediate runtime errors, so I spent more time tracking down each one until I could get a title screen or something displayed. Since the new Starling-based UI controls were still not fully tested, all this work took much longer, and I found myself switching between both codebases to fix bugs in each.

Overall, the full conversion, including both UI controls and the game itself took about a week, including heavy testing to be sure that I didn’t introduce any new bugs from the differences between the old and new renderers. With the UI controls stabilized now, and more experience in the steps required to do an ambitious conversion like this, I think I can finish the next game in about 3-4 full working days. It’s still not as simple as changing imports from flash.* to starling*, but it would be a lot worse if I were using a 2D framework that didn’t match the classic display list so closely. I cannot stress enough how nice it is that Starling matches the display list. Learning is easier, and if you need to convert existing code, it helps so much.

Starling Performance

Starling running on Stage 3D is obviously visually smoother than renderMode gpu in my games. Most devices I tested on were consistently running at over 30 frames per second, with many close to 60. Choppy framerates and hiccups, which can be all too common with renderMode gpu, already feel like a thing of the past. My games aren’t super intense, but this seems like a pretty significant improvement that will greatly increase what AIR mobile developers are able to do, especially on some older devices.

That isn’t to say that Starling removes all performance issues. In particular, very slow devices like the NOOK Color still needed some optimization to make things run smoothly. There seems to be a threshold where very, very slow devices have a slightly harder time with Starling than renderMode gpu, if you don’t do some basic optimizations, and then everything else gets a beautiful performance boost even without those improvements.

During testing, I found that the NOOK Color seemed to be rendering somewhat faster than it did with renderMode gpu, but touch events in particular where lagging way behind. I was uploading textures straight from PNGs for basically every single display object, like individual, separate button states. All the textures were staying on the GPU, but swapping between them all became a bottleneck. I needed to combine all my game’s images into a single 2048×2048 texture atlas to fix this. Even after that, if I created a single separate Quad (single-color rectangle) somewhere on the stage, the performance would drop significantly. If I wanted to display the framerate, I had to rewrite parts of this port of mr. doob’s Stats class so that the bitmap font and background would come from my atlas instead of using their own separate textures. It was a little frustrating, but the result was that the game ended up being more responsive than the previous version.

To be clear, these optimizations only applied as requirements on the NOOK Color, and an equally-underpowered Motorola Droid 1, among my various test devices. The original unoptimized code worked flawlessly on the Nexus One, Nexus S, NOOK Tablet, Kindle Fire, iPad 1, and iPhone 3GS. Several of those devices couldn’t keep up with 30fps in renderMode gpu (but were “good enough”), but all were running above 30fps with Starling. The best didn’t quite reach 60fps, like my PC, but a few were in the low to mid-50s consistently, even during tweens that changed the entire screen every frame.

Come on in, Starling

Any game I make with AIR for mobile (and probably Flash Player, but I’m pretty focused on apps these days) from now on will use Starling, for sure. In fact, the performance improvement feels so good that I wish I had the time to port all of my existing games over to Starling. I doubt I would see enough improvements in sales to make it worth my while, though. Still, maybe I’ll have the occasional weekend afternoon to catch up on all that over time. If you’re developing 2D apps for mobile with Adobe AIR, I highly recommend checking out Starling or another 2D framework built on Stage 3D. Between Stage 3D and captive runtime, AIR is finally getting close to a “perfect” rich mobile app solution for my needs. Now if only Adobe offered a way to remove parts of the captive runtime to decrease the final binary size. There’s always just one more thing you wish were better, no matter what technology you use.

Mentioned above: Rivers of Olympus

The Breakdown

In total, I earned $21,551 from game development in 2011. This includes mobile device game sales, non-exclusive licensing of Flash games to portals, ad revenue from free Flash games, and a couple of small game-related freelance projects (short-term contract work). As always, I’m sharing only my earnings as a game developer. I also work on a variety of other freelance projects throughout the year that are mostly RIAs, and I sell an educational app called Logicly.

Let’s start by comparing the differences in the percentage breakdown from last year to this year. Last year, freelance work brought in 79% of my game development revenue. In other words, the vast majority of my earnings came from working on games for other people. That doesn’t exactly matching my goal of eventually going totally independent (or nearly so). This year, freelance work dropped to 14% (again, this is for game development only. RIA freelance projects still make up the majority of my total income). Mobile game sales went in the opposite direction from a mere 8% last year up to 80% in 2011. In spite of total earnings staying nearly the same from year to year, I’ve seen a major shift in what is earning me money, and it grew significantly.

The Best App Stores

Next, let’s take a look at why my mobile game sales increased so strongly. Seeing which app stores performed best should make it particularly obvious:

The device that deserves to be in the spotlight is the NOOK Color (and now the NOOK Tablet too) from Barnes & Noble. As you can see, NOOK apps make up 90% of my app sales. It seems to be kind of a dark horse in the app store world. I think most mobile developers don’t know about the NOOK store, or they haven’t given it a fair look. NOOK readers are very willing to pay for e-books, or they probably wouldn’t have bought the NOOK. I took a peek at some of my favorite novels, and they sell for at least 7 or 8 bucks a piece. An extra 50% or more for newer releases. Compared to that, an app that sells for 2 to 4 dollars is no big deal. This is an audience that seems to be even more willing to spend money than iOS users—at least in my experience so far.

NOOK sales brought in over ten times more than iOS sales, while the Android Market and the BlackBerry PlayBook both got lost miles behind. Neither of those two earned over $200 (although, full disclosure, two of my games aren’t yet out on Android Market and one isn’t on PlayBook yet). The Amazon Appstore for Android didn’t even make the cut. I hadn’t earned enough to get a check in the mail from them by the end of 2011. However, Christmas sales of the Kindle Fire must have been halfway decent. App sales finally started trickling in from Amazon around Christmas. At the moment, my Amazon sales are comparable to my iOS sales. If I were to limit myself to three stores, it looks like NOOK, Amazon, and iOS come out on top, with NOOK being the absolute first priority.

Update February 10, 2012: Amazon sales are still going strong, and they’re typically better than iOS on most days. Still not as high as NOOK sales, but Amazon is now number 2. Moreover, the PlayBook seems to be doing better now too, and iOS is pretty much in fourth place. Funny how things can change so dramatically, and also a sign that focusing on new and smaller app stores can be a good choice for indies without much marketing budget or experience.

Everything Else

Other revenue either came from small projects, like some portals that wanted an older Flash game site-locked or quick freelance projects that took no more than a day. Nothing significant, but a quick buck here and there for very little effort. To my surprise, ad renveue from MochiAds, MindJolt, and Google AdSense is still coming in. Ads earned me enough to pay my bills for about a month, and I did all the work to make that happen 1-2 years ago. This ad revenue won’t last forever, but it’s nice to have it while it lasts.

Into 2012

The huge jump in sales thanks to NOOK is awesome, and I hope to continue exploring this platform and finding apps that resonate with its unique audience. However, each new release was just a little bit less successful. I was lucky to get in at the very beginning when the number of apps was well under 1,000. As with the iOS gold rush, it was easy to get recognized by potential users because you couldn’t drowned out by everyone else clamoring for attention. Thankfully, as with the Amazon Appstore, NOOK sales spiked on Christmas, and they still haven’t completely dropped back down. There’s still a little time to enjoy the benefits of being an early developer.

My first game, Chroma Circuit, is my absolute favorite of my creations. It wasn’t the very best seller, but the fans it found have some real enthusiasm that is inspiring, and I hope I can find more of them. I’ve been working to release a huge new content update for quite some time, actually. Several new elements are all coded up. Some rotate like the others. Some slide around instead. They’re fun new additions and there are a lot of little animations and things that add to the aesthetic experience that I didn’t have the time/brainspace to add when I first released Chroma Circuit three years ago. The biggest barrier now is building new levels. I built a great little visual level editor (unlike the original version, which had hand-coded XML!), but it’s still a time consuming process, and I don’t want to release anything until I have over 100 levels. I’m at about 60 now, and I think I’m going to set some daily or weekly goals to get me over the last hill and to the finish line.

Other than that, I don’t have many other concrete plans for the new year. I mainly want to continue releasing games that can sell decently as NOOK apps. Whether they’re unique games like Chroma Circuit, or more generic ones like Sweet Shop Slots and Rivers of Olympus, I’m willing to explore both directions. I’d like to stick to shorter projects that don’t go longer than a month or so, and then I can see if a bigger collection of games can create the foundation on which I can become more and more independent. If some turn into real hits, even better, but I’ll be happy with small and modest successes.

We’re all aware that certain options may be technically or aesthetically inferior. Yet, we can’t improve the situation without getting our hands dirty. Rather than preach to the choir, we should be providing clear, visible evidence of where web standards (or implementations of the standards) need improvement. We should be creating publicly visible works that push the limits of the browser as it exists today, even if doing so requires the nastiest of workarounds. In fact, finding those workarounds should be a priority because I want us to be able to point to them and say, “Hey browser vendors: I made this, and users love it, but check out this code that’s going to make you want to puke (or this overworked CPU, or excessive memory, or whatever). You need to fix that.” By showing truly compelling projects that can hit barriers and raise awareness of web development pain points that anyone can see, I think we’ll find that browser vendors can be far more agile than some people assume.

The open web community has been calling out Flash for many years, whether their arguments were accurate or not. Now that they’ve “won” for certain use-cases, I think that it’s time for the tables to turn, but in a more productive way. Targeted and actionable feedback, measurable data, along with impressive content will do much more to improve the web than complaining that we miss the good old days. Our jobs may not be as fun at first, but wouldn’t you rather make it better sooner than later?

Native Extensions

One question native-only developers ask people like me, who use AIR or Corona, is why we would limit ourselves to the features that Adobe and Ansca are willing to implement for us. It’s a valid question, and I can see why some developers might feel too restricted. Personally, I prefer to work with languages that I will enjoy using and to have quick and easy APIs like display lists that don’t require screenfuls of low-level code. I prefer those sugar features so much that I have no hesitation living without the rest.

Thankfully, though, AIR 3 comes with support for native extensions. If Adobe hasn’t exposed a feature that I need in my AIR app, and I’m willing to write a little native code to implement it, then I can add that feature myself by including a library with my app. To me, that makes AIR the best of both worlds. It’s almost as if AIR is just another native framework, but it has the support of all the tools and libraries of the Flash ecosystem.

Now, if only I had the same opportunity to extend Corona. This, to me, is a huge change in the balance between choosing AIR or Corona. Almost any capability Corona offers out of the box that AIR does not, I can implement myself, if needed (or maybe someone in the community already has!). The only places where I might prefer Corona is graphics performance because Stage3D in AIR is only on desktop for now (and TV, I think, but who actually cares about that?) and Lua support because Lua is more fun to write than ActionScript. Not that I’d use Lua for a Flex-like project, of course. Each language has its place.

Shaders

Flash Player and AIR support Pixel Bender shaders. These allow developers to manipulate display objects with cool rendering effects, at pretty impressive performance levels. Drop shadows and glows, color manipulation, distortion, blend modes, and all sorts of fun stuff are possible. The closest thing Corona has is additive blend, which is nice, but a single blend mode seems strangely out of place. Oddly enough, I can’t even find it listed in the Corona API docs.

At Adobe MAX this week, we also saw a preview of CSS Shaders. Eventually, web frontend developers will be able to enhance their content in very cool ways. I know it’ll be awesome for games. Love the flip-book effect video. I have a similar 3D-like manipulation I want to include for the powerups in Gridshock HD (notably, a game that I built with Corona).

Interestingly, that blog post from Ansca on the additive blend mode mentions shaders, so it looks like they may have it on the roadmap. Hopefully, sooner than later.

Build iOS Apps on Windows

Finally, something that isn’t related to AIR 3′s recent release, but I didn’t mention it in earlier posts. Each time I work with Corona, this one becomes more and more annoying. I can’t build a Corona app for my iPad or iPhone from my Windows machine (which is my main development machine). Instead, I need to grab my old Mac laptop, transfer the files over somehow, and do the build over there. Adobe has provided the ability to create iOS apps with AIR on Windows since they first introduced it as the “Packager for iPhone”. Yes, Apple had a huge hissy fit about this a while back, but they got over it.

Switching computers to do a build, especially if I can only test something on a device, is a major time sink (and mental context switch) that I shouldn’t need to deal with. I’ve been building iOS apps with Adobe software on Windows for two years. Isn’t it about time to play catch up on this one?

More grudge matches to come, I’m sure, as AIR and Corona continue to evolve.

The idea here is that it’ll be an escape the room by moving things around, setting up mechanical contraptions, and deactivating obstacles sort of game. As you go from room to room, the puzzle solving gets more complicated. I guess it’ll be kind of like Portal, but without the portals (and in 2D, obviously). The player will be be a bit more omnipresent, though. It won’t involve controlling a character restricted to the world necessarily. I may have a “token” that must advance to a specific goal in each level, but the player will be able to manipulate the entire level from a higher plane. I want to try to make multi-touch an important component too, as this game will be targeted at tablets and phones.

As you can see from the artwork, I’m going for kind of an ancient temple theme. Yes, it’s looking rather pristine at the moment. That’s just me fighting myself over how complex I want to make this thing. Ultimately, I don’t think it will look right without some wear and tear. Though it’s not too detailed yet, I have a feeling that this will become some of the most ambitious game artwork I’ll have created so far. Earlier this evening, I started considering an idea of ever increasing damage to the structure as the player advances to higher levels. As you get deeper in this temple, these changes may be part of a simple narrative of some sort. Maybe puzzles will start to work incorrectly, and odd workarounds will create a “new” solution. I think it’s possible make this game fun, even without a narrative underlying the player’s progress, but this is just another place where I think I can benefit from pushing myself to try new things.

The code I’m running at the moment is targeted at Corona. I wanted to play around with Lime, a tile map library for Corona, and I’m experimenting with the built-in physics too, which Lime integrates with rather nicely. I was a little wary of using Lime because there are supposedly performance issues on devices (which the website makes abundantly clear), but I found that my initial test “level” is running great on a first-generation iPad. It’s likely that people developing platformers and other games with Lime have much larger levels than I intend to build. Additionally, my tile size is currently 138px, which is probably enormous in comparison as well, and I assume that can end up making the level simpler to draw due to fewer tiles filling up the space.

Side note: I’m stubbornly and irrationally opposed to using graphics with dimensions at powers of two. Ever since I realized how often people suggest it, I’ve had the quirk of purposefully choosing something else. Yes, I realize that it’s generally suggested for good reason, but my inner artist will not be obstructed by silly technical restrictions.

As I get further along, I’ll try to share more. Perhaps when I begin experimenting with more puzzles and obstacles, I’ll highlight a few and explain how they came about. I expect things to continue being experimental going forward for a while. The artwork itself involved some playing around in Photoshop on one boring Saturday afternoon. I had some basic ideas for a physics stacking game that I wasn’t really committed to. I made the block with the gem in the middle (from the first screenshot above), and I immediately felt how it could be manipulated by touch, and I could start to imagine the temple-like environment that would surround it. With that small success as a foundation, I intend to continue using play and experimentation as my primary motivator for continuing to build upon this idea.

Game Network

Last time, I noted that OpenFeint support in Corona could only be used with iOS. Thankfully, OpenFeint works on Android now too. Moreover, Corona developers have been given a choice between OpenFeint and PapayaMobile. Leaderboards and achievements for all. More and more, I’m finding that I’d rather integrate a service that focuses exclusively on this sort of thing because the experience can be far better than a home-grown solution (at least for an indie developer, like me).

Advertising

Ansca has also partnered with InMobi to bring advertising to Corona apps. Whether it’s to monetize a lite version or to go completely free and try to mimic the typical route of free web games, ads are extremely important. I’ve been waiting for quite a while now for the ability to try releasing a free game with ads. Since I’d rather not go fully native, I needed a supported library from an ad network (which apparently isn’t a priority), or ad support in my platform (thanks, Corona!).

Hold on there, AIR

Day by day, I realize that while AIR is getting some cool features that can wow the senses (like Stage3D), Adobe is forgetting, ignoring, or not prioritizing features that keep a roof over a developer’s head. Some things players expect or demand in games, like popular social networks for leaderboards and achievements. Others help us earn just a little more money, like advertising and in-app purchases (both of which can be useful outside of games too). I immediately felt limited without these essentials back when AIR on mobile was first introduced, and it’s been frustrating to see little support from Adobe or third-parties after so long. Maybe that’ll change with native extensions, but those are still a bit further away in the future.

Platform API Support

In Corona, there are a number of features that are currently only supported on iOS. Among the most compelling features, I noticed that In-App Purchase and OpenFeint are both marked iOS-only, and there are some others too. In particular, OpenFeint’s leaderboards and achievements are a big reason for why I chose Corona for Gridshock HD on iPad. I know that players demand OpenFeint and/or Game Center, and I simply cannot use either in AIR right now. As great as it is to see OpenFeint available in Corona, I’m not a big fan of runtime-included features that aren’t cross-platform.

On the other hand, the ability to extend Corona with native code would be awesome, just like it would be awesome to have the same thing in AIR. If native extensions existed, the power would be in my hands to choose whether I want to (or am even able to) implement a feature on a specific platform. The development effort for robust extension APIs is, of course, a big task, and I understand that a young platform like Corona might want to include a few high-demand third-party features out of the box before they get around to more daunting things.

Regardless, I’m sure that there are constantly feature requests for Corona to include an API for <insert personal favorite library here>. If native extensions were available, individual developers would be free to add two very valuable types of functionality:

1. Highly specialized features that few other developers need.

2. Features that might be coming the future, but there’s an immediate need that cannot wait.

With those out of the way, Ansca can focus on core APIs that work well across all supported platforms and that are useful to the largest majority of their customers—making everyone happier. In addition to native extension support in the runtime, a place to share (or maybe even sell) extensions would be ideal so that folks like me, who never want to touch Objective-C, can look through what others have already built.

Simulator

In the simulator, what you see on your PC may not be what you see on the device. Sometimes, that’s impossible to fix, since some features just can’t work on desktops (Although, I’d like to see more console output that basically says, “you called function X correctly, but it cannot be used in the simulator. Please test on device”). Sometimes, though, the simulator can do things that device builds cannot. In my opinion, that’s much worse. For instance, I saw multi-line text working in the Windows simulator, but discovered that an iOS build only displayed a single line. With simulators, it’s best not to get my hopes up.

The Mac version of the simulator has skins for iPhone and iPad. It makes sense, on one hand, because the Windows version can’t output iOS builds due to Apple’s stupid rules. However, I can’t be the only Corona developer who codes on Windows and builds on Mac. Even if it requires extra notification that I can’t build for iOS, those skins would be super helpful. Alternatively, I would like to be able to add completely custom device skins. In the latter case, all I really care about is specifying a custom screen resolution for the device. If I can get 320×480 or 640×960, then I simply don’t care if the skin looks like an iPhone or not.

Finally, the console output for runtime errors in the simulator always seems to get cut off. On Windows, at least. I can’t remember off-hand if the Corona Terminal on Mac has the same problem. Anyway, I can live without a debugger, but then the stack trace must be as detailed as possible when that’s the case. Half missing information could be the difference in finding an error in seconds versus finding an error four hours later. I’m sure you can guess which I’d prefer.

Language

Lua’s standard library is probably as stark and barebones as you can get. Basically, it provides some math functions, some string functions, and a few functions that turn a table (usually called an object in other languages) into an array by adding and removing from numeric keys. Some of the most basic things I’ve come to expect from a standard library just aren’t there. For instance, how often do you call indexOf() on arrays? I do it all the time, and I was forced to write my own version in Lua. It may not be optimal, and I’d rather use something that a dedicated person or team has vetted better than I could with my time constraints.

On one hand, the small standard library makes sense. The language itself is tiny, and that’s a big advantage. On the other hand, I wonder if the wheel has been reinvented tens of thousands of times by various Lua developers. From what I can tell, there isn’t one true community-supported standard library out there, like I would have expected. Maybe I missed it. Honestly, though, I get the impression that most people throw the Lua interpreter into their C++ games and write super short scripts that don’t need much supporting utility code. Anything complex just goes in the C++ layer.

Corona is different. In Corona, all your code except the super low-level stuff is written with Lua. Corona developers have a more pressing need for a robust standard library that is closer to what’s available from the top-level classes and functions in JavaScript or ActionScript. If Ansca has big dreams for much larger game projects built with Corona, they need to spend some time filling in the gap here so that developers aren’t bogged down in low-level implementation.

Moreover, if Ansca wants to support any kind of open source community, a standard library declared from on high will nip a couple of potential problems in the bud. Since I’ve yet to see any Lua code that uses some sort of namespacing, name collision is pretty much inevitable. Likewise, duplicate functionality will be rampant as everyone includes their own flavor of the missing core library. For anyone that wants to mix and match third-party libraries, that’s going to be a mess of headaches. As Corona-targeted libraries get more complex, the chances of this happening grow exponentially.

Choose the Best Tool for the Job

I enjoyed porting Gridshock HD to Corona. I learned a new language that I hope to develop with again in the future, and I was able to take advantage of features that aren’t available to me in my usual environments. It has given me some inspiration and expectations that I intend to take back with me to Flash. I might be a little more harsh on Adobe’s runtimes when I give feedback now, but any criticism I make will be because I want to see Flash Player and AIR continue to be the best at what I use them for.

Am I now a Corona developer? I’m certainly not leaving Flash behind. However, I’ll be keeping an eye on Corona to see where it ends up. I don’t have current plans for more Corona games, but I may change my mind if certain features are compelling enough, or if I decide that I haven’t played with Lua enough lately. We’ll see. It’s another useful tool to have at my disposal. I’m very glad that I spent some time learning to use it.

Language

I, and I think many Flash developers who have been around for a while, kind of miss dynamic languages. I often hear that Flash isn’t as “fun” as it used to be. I can relate. It would be great if we could use something less strict than ActionScript 3 in our Flash projects. Yes, I know I can turn off strict mode, but if I’m going to use ECMAScript, I want AS3′s dialect to be updated with features that have been added since ES4 was dropped by the committee. There’s some cool stuff coming in Harmony.

Corona includes Lua, which is my new favorite language of the moment. It’s super flexible and a lot of fun to work with. If there were a way to compile it down to bytecode that could run in Flash, I’d consider switching to Lua over ActionScript 3 for much of the Flash content I create. AS3 is good for Flex apps, but for games, web experiences, and stuff like that, a dynamic language like Lua (or modern ECMAScript) would be more fun for me, and enjoying my work is a top priority.

For reference, this is a minor need compared to the ones that follow. I can live with AS3 for all my Flash development. It’s a decent language, but I simply desire a little more choice. If you look at JVM or other runtimes, they all have extra languages beyond the main one(s). I want to branch out more, and it would be awesome if I could keep a foundation in Flash.

Graphics

Corona offers OpenGL-accelerated graphics. I had no rendering performance bottlenecks, and it was a dream. However, we all know that AIR will be getting Molehill hardware-accelerated APIs in an upcoming release. Corona has the advantage now, but it may not be for long.

Libraries

Corona includes out-of-the-box support for OpenFeint and Game Center. These services are considered a requirement by many mobile gamers these days, and they’re sorely missed in mobile AIR game development.

Developers simply need a way to run native code with AIR. There are compelling third-party services that only provide native libraries, and we can’t use them if we want to develop with AIR. Even worse, many are unlikely to be added to the runtime, so without native libraries, we’ll never be able to use them. In addition to game leaderboards and achievements, I know many would like to access things like in-app advertising and custom hardware or accessories. Moreover, being able to use native libraries will help us avoid rewriting existing libraries that are already working well in a native form. It expands the reach of AIR and saves time and headache. Native code would be a major win, for sure.

Runtime

Everything you need for Corona is included in the output. There’s no separate runtime. I suppose it’s similar to how AIR app work on iOS. Developers like me want to include the AIR runtime with Android apps too. I strongly dislike requiring my users to install a runtime before they can play my games. It’s an extra potential point of failure, and it feels somehow unprofessional as a potential source of annoyance for the user. While you’re at it, allow me to include the runtime on Windows, Mac, and Linux as well.

The age when separate app runtimes were a valid choice for targeting consumers is gone. I know games are a big focus for Adobe right now. Flash Player is a huge target for casual games. I’d love to use AIR to release commercial desktop games that are more polished, bigger, and better than my free web games. However, asking potentially-inexperienced users to install or update AIR is a big reason for why I’m not exploring AIR on desktop for games. Adobe has probably done the best it can to make the install experience painless, but I just can’t get over being wary.

As for updating AIR, let’s be honest. The latest version of AIR doesn’t get installed as quickly as Flash Player. I’ve never heard Adobe talk about stats for AIR runtime installs. Given how often Adobe presentations include the graph with Flash Player installs, I refuse to believe that they wouldn’t be sharing AIR install graphs too… unless they’re just not impressive. Let me package in the runtime, and I’ll never need to worry about the AIR runtime version. I’ve heard that a ton of Java apps package in the Java runtime now for similar reasons, and I’m sure that’s way bigger than AIR, so let’s get with the times.

Mobile is still a new frontier, and closer to the casual experience on the web, so I’m tolerating a separate runtime on Android, but my feelings are much the same as with the desktop runtime.

A Tight Race

In a follow-up post, I take a look at a few things that I don’t like about Corona. Yes, the coin flips both ways. Corona has some advantages that made it an obvious choice for my iPad game… today. However, AIR is not that far behind Corona in this particular race. In some ways, AIR is much further ahead. To put it simply, I was willing to make some trade-offs in development comfort to get the features I wanted. I didn’t like that, but I sucked it up and only grumbled to myself.

I know both technologies will be improving over time, but I think that Corona is going to need to fight harder to stay on top in the situations where it holds my interest right now. So far, I’m only interested in Corona for iOS support. That’s a precarious place to be when there are a variety of pros and cons on both sides.