Posted by Zeh Fernando on 30/June/2013 at 19:54
I’ve been toying around with creating OUYA content with Adobe AIR, and I’m happy to say it’s a pretty easy and straightforward development workflow. Information on it is hard to come by, though, and the official Adobe AIR support samples doesn’t seem to exist anymore, so here’s a few high-level notes on how to get it working. As a bonus, remember this can all be done with free tools (a big myth of Flash development is that it requires some proprietary, commercial-only IDE).
- Download the Adobe AIR SDK and unzip it somewhere. This has the compiler that you’ll use, called “ASC 2.0″. Normally you want to have that in a generic location, since it can be used by more than one project. Mine is always at a “D:\air” location – at any moment in time, I always have 3 or 4 copies of different versions of the compiler, each on a folder with a different name depending on its version.
Download the latest version of the Flex SDK and unzip it somewhere. This is the compiler that you’ll use. Normally you want to have that in a generic location, since it can be used by more than one project. Mine is always at a “D:\flex” location – at any moment in time, I always have 3 or 4 copies of different versions of Flex SDK, each on a folder with a different name depending on its version. Download the Adobe AIR SDK and unzip it somewhere, but then move its contents over to the Flex folder. This will replace (old) AIR files that your Flex installation came with, updating it to the latest version of Adobe AIR.
- Set your workflow up to be able to edit and compile a pure AS3-based project, as well as using the compiler in that AIR version for compilation. This will vary depending on your IDE of choice. You can use any text editor (if you’re happy using the command line to compile). More focused IDEs exist, though. A good free one is FlashDevelop. Commercially, there’s also Adobe FlashBuilder and FDT (both based in Eclipse). I have to say the latter one is my favorite and it makes development easier by automating some tasks.
- Remember to setup your compiler parameters to use the most modern settings available, to avoid problems with legacy parameters. I especially recommend compiling your SWF as Flash version 11.7 or higher (that’s “SWF version” 20 or higher). Also, if you have used the Flex SDK before but are new to ASC 2.0, it’s very likely that you’ll have to do a few small changes to your code. Read this compatibility document for more information.
With this, you should be able to compile and run AIR applications on your desktop. There’s a lot more to it, like creating a descriptor file and embedding assets correctly, but it’s beyond the scope of this small post; read the online documentation for more information.
One last note:
theoretically, you don’t need the Flex SDK installed, since the AIR SDK package already includes the tools necessary to compile AIR-only, ASC 2.0-only content. The Flex SDK is still required by some IDEs, however, so it’s wise to have it available too. I have updated the above instructions to ignore this altogether, as ASC 2.0 is now pretty mature and supported by most (all?) of the IDEs out there.
Development and debugging
The beauty of developing AIR applications is that you can test your content on the desktop most of the time, only deploying to the device when you need to make sure performance and memory usage is OK, or to make sure it works with the input interface of the target device. This is the workflow I use for Kana Mind, and it really speeds up development.
In that sense, what you should do is have a command line or a compilation profile for several different situations. How you do this will change depending on your IDE and project workflow, but in general these are the testing/deployment profiles I use:
- A desktop debug profile. You will use this for most development and testing. Things will compile and launch in seconds, and you don’t need to use the device or switch screens for testing since the application is launched on your computer.
- An Android debug profile. You will use this for testing elements of your game that can be constrained by the device’s capabilities. Overall performance, memory usage, and device input fall into this category. This can be used quite often too, depending on what you’re testing.
- An Android release profile. This will be used when compiling the final, optimized, non-debuggable version of your executable. This will also be faster and use less memory than a debug version, so it should be used for the final round of testings too.
Code-wise, make sure that you:
- Use a framework for hardware-accelerated graphics. While this is not a hard requirement, and it can make development more difficult (you lose some of the flexibility of using Flash’s typical vector drawings), it’s an absolute necessity if you want to unleash all the potential the OUYA can offer (or any other mobile device, for that matter). Starling is the standard recommended framework for 2d graphics. If you’re looking into 3d content, you should take a look at Stage 3D or any of the libraries that make use of it.
- Use the GameInput API to support the OUYA controller. Do not use “Native Extensions” for gamepad support. Native Extensions are a great way to add support of certain native features to Adobe AIR, and it was needed before the OUYA gamepad was officially supported, but it is not recommended anymore.
Finally, at some point you’ll need to test on the device.
- Turn on your OUYA, connect it to your computer via the micro USB input, and get it to be recognized as an Android device. You don’t need to download the ODK. Still, this is a somewhat involved process, but then again it’s nothing new if you’re already had to setup drivers for some random Android device.
- The OUYA has its own manifest requirements that you should be aware of before publishing. Search for “OUYA intent category” on the ODK setup page for more information.
Using the OUYA to work for debugging can be somewhat annoying, since you need a separate monitor, so keep that in mind. In any case, you can have both the OUYA and your computer connected to the same screen and then keep switching the input of your main monitor (as I’m doing until I can get an HDMI/DVI adapter for my second monitor… ugh).
While it is theoretically possible to run OUYA-like specs as an emulated device on your machine, I wouldn’t really recommend it. Unless you have the right combination of hardware (for performance acceleration) and spend a good amount of time getting the right virtual machine images, Android emulation always gives you terrible performance. It is instead much better and faster to test your game as a normal (desktop) AIR application, and then deploy and test in the device when necessary.