As an update to my previous post, Adventures with Corona, Part 1: What Corona offers that’s better than Adobe AIR, I thought I’d take note of some new features in a recent release of Ansca’s Corona SDK. In particular, Corona developers now have access to more useful services. Services that we simply cannot use in AIR today, for various reasons.

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.

Where I am today, in life and my career, is thanks to a powerful drive to always learn, grow, and push my limits. I’ve rarely encountered much internal conflict related to this process. Often, I have a wealth of things that I might choose to work on. In the past, I typically picked something that seemed fun or interesting at that particular moment. That was pretty much the only criteria. Now that I have the freedom to spend more time on personal projects, especially ones that earn revenue, I’m having difficulty continuing with the same process. These days, I feel like I need to prioritize. As a result, I feel like I’m missing out on wider explorations that I would have chosen in the past. Lately, that’s been troubling me.

As you probably know, I started creating casual games a couple years ago. Within about four or five months, I released three games. Since then, I haven’t finished a single new game. Actually, no, it’s time to be blunt. I haven’t started a single new game either. I played around with some ideas, but they didn’t make it beyond the early prototype stage. Those ideas simply didn’t resonate the same way that my first game, Chroma Circuit, made me want to start creating games in the first place. Gridshock and Qrossfire, my other two games, were deliberately derivative because I wanted to spend time focused on building a foundation of knowledge and code that could be used across many games in the future. Qrossfire, in particular, cemented this new direction of how to decide what to work on.

Since then, instead of starting fresh with new ideas, I’ve mainly continued iterating. I haven’t stopped expanding my knowledge in this pursuit, even with the same three games, and I’ve found enjoyment during every step of this process. I’m experimenting, adding features, and refining the experience in many ways. I’ve improved the controls, refreshed the graphics with better artwork and special effects, and I’ve added new mechanics. I still have many avenues I could explore with these games. Their modest success on mobile is just good enough that I don’t feel like they’re a complete dead end, but they’re also doing just bad enough that I’m driven to continue with them just to prove that I can do better.

For some reason, though, I feel kind of stuck. Part of me wants to move on and try new genres of games. I want to get back out of my comfort zone and force myself to write code for things that are more advanced than what I’ve done so far, or at least work on things that feel newer to me. Obviously, I’ve only focused on the same sort of game. Maybe that’s slowing my advancement. Not to a halt, or I’d be completely bored, I would have moved on to something different by now. Instead, it’s enough to keep me interested, but I’m clearly not propelling the same way I used to in school and during my early career.

I can see the deceleration just in the fact that I don’t blog as much anymore. I don’t say, “hey, look at this random cool thing I worked on last weekend” very often these days. I’m okay with that, to a certain degree, because my blog posts have been getting longer too. When they’re finished, I feel like I accomplished something, and that they include more insightful information now than I could include in my old writings. Of course, I’m far more active on Twitter now than when I was blogging weekly or monthly, so it’s not like I’ve disconnected myself from the Flash community that I first joined thanks to my blog posts.

Even after writing down my thoughts, I’m not feeling any more decisive. I’m frustrated with myself for not finishing a few projects that would bring my existing games to new platforms. They’re at least halfway done, if not more, so I’m feeling like I wasted time if I don’t get back on track with them. Then there are way to improve the games and learn more by adding features that I’ve not tried implementing yet. Micro-transactions. Achievements. Stuff like that. On the other hand, I have those prototypes that would easily make playable games, if not necessarily breaking new ground for me, and I have a few ideas that are still simmering in the back of my mind that I want to start exploring. I want to reach a point with one of them where I’ve verified that the idea is fun, and it excites me to move from prototype to the complete game.

Both directions that I keep comparing pull at my interest, but I don’t want to split up my time between both of them either. I feel like I need to choose because the day has too few hours to work on everything at once. I’ve already divided my time between games and other software. There are other activities, not involving programming, that I want to dabble in too. Every project I continue to work on is interesting to me in different ways. That’s the hardest part about making choices in this area. I want to fit everything in, and I want to get it all done in the time it would take if I chose just one. You might say that all that potential is a good thing, but it feels like a major barrier to me.

In my first look at Ansca’s Corona SDK, I mentioned several features that Corona offers where Adobe AIR is currently lacking. These were compelling enough for me to rewrite my tablet game, Gridshock HD, with Corona for the iPad version. That said, it wasn’t all sunshine, lollipops, and rainbows. Some of Corona’s core APIs and functionality can feel a bit half baked in places. Let me share some of the places that seem, to me, in most need of some love.

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.