Monthly Archives: October 2011

Corona versus AIR again: Where Corona falls behind

Now that Adobe has released AIR 3, it’s time to expand on my previous comparisons between AIR and Corona and to take note of some places where Corona definitely doesn’t offer what I need. Because I’m a fan of both technologies, I’m trying to continually put a little pressure on both sides to offer the right capabilities for modern mobile apps. This time, Corona gets a turn again.

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.

Dev Journal: Ancient Temple Puzzle Game #1

Here’s a very, very early preview of a game idea that I’ve been playing around with for the last week or so. My plans around this idea are still extremely vague, and everything here is subject to change. I’ve already scrapped the earliest seed of this process completely, and I’m not yet sure that I’ve arrived at the final game that I’ll commit to finishing. To get out of the block I’ve been experiencing lately, I’ve been trying to push myself away from my comfort zone as much as possible. Sharing something in the brainstorming to early prototyping stages is part of this process. For science!

Screenshot 1 of Ancient Temple Puzzle Game

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.

Screenshot 2 of Ancient Temple Puzzle Game

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.