Corona SDK for Mobile Development

Developing iOS apps using CocoaTouch and XCode is great. Creating games however is a challenge.The tools are just geared to app development I think.

Developing Java-based Android games seems pretty horrible all around. Java is great (powerful but not easy), but the code-test-code development cycle leaves much to be desired.

Luckily there are 3rd party SDKs that create native iOS and also native Android projects geared for gaming. One of those is the Corona SDK from AnscaMobile.

Benefits of Corona SDKfor iOS/Android Development (In AnscaMobile’s words);

  • Build Apps 10x faster – Corona’s framework dramatically increase productivity. Tasks like animating objects in OpenGL or creating user-interface widgets take only one line of code, and changes are instantly viewable in the Corona Simulator. You can rapidly test without lengthy build times.
  • Same code, multiple stores – Corona is the only complete solution for developing across platforms, OS versions, and screen sizes. You can write once and build to iOS, Android, Kindle Fire or Nook Color at the touch of a button — Corona will automatically scale your content across devices from phones to tablets.
  • Simple, powerful APIs – Make use of advanced features using just a few lines of human-friendly code. For instance, you can implement realistic physics in your game with just five lines! Corona’s ease of use is what allows developers from indies to major studios to create #1 chart-topping apps, games, and eBooks.
  • Create engaging experiences – Say goodbye to cookie-cutter apps. Whether you’re creating branded apps, graphically rich games, or interactive eBooks, Corona gives you everything you need to go beyond the ordinary. It’s easy to make your apps behave and look exactly how you want them to.
  • Cut costs. Monetize faster – Corona enables you to produce top titles without big studio budgets. And thanks to Corona’s integrated support for in-app purchases, banner ads, and offer-based virtual currency, you can monetize faster and easier than ever before.
  • Join developers like you – Corona boasts a very generous and knowledgeable community, a plethora of 3rd party tools, as well as a shared code repository where users can download and share helpful libraries and snippets with one another. We also have 347 Corona SDK studios across 47 countries worldwide

Pro’s and Con’s of Corona (In my words)

I have used Corona SDK for about 5 hours. I’m new.

  • Lua is very very fast.
  • The code-test-code cycle is the best setup I’ve ever seen. Its so fast, just save your latest lua file and *poof* the project compiles and growl (on Mac) shows an error or not and your project is already running with debug output. (Now if I can just get the LDT IDE to handle debugging. I can, soon!)
  • Lua is not OOP. Corona is not component based. Without built-in OOP or built-in component based gaming (like Unity for example), development with Corona leaves much to be desired.
  • Its 2D only (good or bad, depending on your preference)
  • No great IDE yet.
  • Graphics are raster-based – So its a fast, but not easily reusable graphics pipeline.
  • Compared to HTML5 it has good multimedia capabilities. Compared to Flash it has horrible multimedia capabilities
Developing one code-base for multiple platforms (iOS/Android) is great. As Leetr.com mentions;
  • Marketing dollars – instead of marketing the game on two platforms separately, we can do it at the same time
  • Momentum – word of mouth dictates that downloads on one platform will possibly translate into downloads on the other
  • Maintenance – we’d rather be working on the next game, than debugging two separate platforms
  • Laziness – Corona SDK has a lot of modules already built in, ie Facebook, OpenFeint

Getting Setup

The steps to get started are to download the Corona SDK, choose your favorite text editor (I’m using Lua Development Toolkit), and run Corona’s Simulator on one of the sample projects to prove you’ve got it all setup properly.

We’ll show the provided ‘Bridge’ project which is a physics demo of some circles falling on a monkey-bridge.

Here are the links to get setup and publish a sample project;

  1. Download the free, unlimited-use Corona ‘Trial’ From AnscaMobile.
  2. Download the free, standalone Lua Development Toolkit (LDT) IDE from Koneki.
  3. Run LDT. You use LDT to setup the project and edit the code, but NOT for Corona code completion, NOT to compile and NOT to debug. I’m confident that all of that is possible, but I’m not yet sure how.
  4. Right-Click the ‘Script Explorer’ and choose ‘New Lua Project’
  5. Name it ‘Bridge’, choose ‘Create Project…’ and point to local url on your machine for ‘CoronaSDK/SampleCode/Physics/Bridge/’ where you installed the SDK.
  6. Open ‘CoronaSDK/SampleCode/Physics/Bridge/main.lua’, by clicking it in the ‘Script Explorer’. Don’t edit it. Just look at it.
  7. Run the ‘CoronaSDK/CoronaTerminal.app’ (on Mac). It will open terminal and also the Corona Simulator.
  8. In the Corona Simulator choose ‘File -> Open…’ and choose ‘CoronaSDK/SampleCode/Physics/Bridge/’. This will run the Bridge project in the Corona Simulator (an onscreen iPad emulator) and show any debugging output in the terminal.
  9. Done.
  10. Now without closing the Corona Simulator or the Corona Terminal, edit the ‘CoronaSDK/SampleCode/Physics/Bridge/main.lua’ file. Add the line ‘print (“hello”);’  without outer quotes and save the file. Upon save the Corona Simulator and Corona Terminal will automatically re-run the project. Nice!

Hello World Project

Typically a Hello World program illustrates the quickest way to get anything (such as text) onto the screen and publishing (or compiling) without errors.

In this post I have also added a few things. We see classpathing (‘com.rmc….’), a custom super class, and examples of publicity and privacy for class members.

The Project Output

Here is the example running. Corona’s included device emulator (“Simulator”) is in iPad mode. Other modes are available.

Debugging: Corona shows your debugging output too (using Terminal for example on Mac OSX). Simulator & Debug Window

The Project File Structure

Corona has many great demo projects included. Each project sits in its own folder. All files for a project sit within without using subfolders. I read on several blogs that while the Corona simulator allows for subfolders, that iPhone and/or Android does not. There are workarounds.

A development environment that does not allow for folders is ridiculous & irresponsible. – Me.

You’ll see my examples all feature a folder structure. For now, they run in the Simulator and that’s all I care about. I assume full folder support will come at some point in the future. If not, you can remove the subfolders from my demos before you start your final code.

HelloWorldOOP File Structure

Document Class

Lua doesn’t support OOP. Corona doesn’t support OOP. However it is possible to fake it.

I learned a good bit from Ludicroussoftware.com’s post, and JesseWarden’s post. There is more info about scope too.

The document class is the main entry point for your application. By default the builder looks for ‘main.lua’, and runs it. It is a required file and it kicks off the run-time of your project.

The lua file format shown here is my own creation. I use it for the main.lua file and then within any ‘classes’ which I create.

[actionscript3]

————————————–
— Imports
————————————–
local TemplateClass = require ("com.rmc.projects.helloworldoop.TemplateClass");

————————————–
— Metadata
————————————–

————————————–
— Main Entry Point
————————————–
display.setStatusBar( display.HiddenStatusBar )

–CLEAR OUTPUT
print ("");
print ("");
print ("  ——————-  ");
print ("  — HelloWorldOOP —  ");
print ("  ——————-  ");
print ("");

–CREATE
local templateClass = TemplateClass:TemplateClass();
print ("    samplePublicVar    : "..templateClass.samplePublicVar);

–TEST MEMBERS
local samplePublicMethod_str = templateClass:samplePublicMethod();
print ("    samplePublicMethod_str           : " .. samplePublicMethod_str);

[/actionscript3]

1. Imports

There are no true ‘imports’ in Lua, nor in Corona. The ‘require’ statement fetches a separate lua file and includes it in the current lua file. In my usage this essentially ‘imports’ the custom ‘class’ of ‘TemplateClass’.

2. Metadata

While not shown here in main.lua, within some classes there are ‘module’ statements (and others?) that help Corona/Lua know how to treat the current file. I call this ‘metadata’.

[actionscript3]

————————————–
— Imports
————————————–

————————————–
— Metadata
————————————–
module (…, package.seeall)

————————————–
— Class Methods
————————————–
— PUBLIC STATIC
–[[
This method is designed to…
–]]

————————————–
— Class Properties
————————————–
— PUBLIC STATIC
–[[
This property is designed to…
–]]

————————————–
— Class
————————————–
–[[
This class is designed to…
–]]
function TemplateClass()

————————————–
— Properties
————————————–

— INSTANCE
–[[
This is a self-reference required by OOP structure
–]]
local me = {}

— PUBLIC
–[[
This property is designed to…
–]]
me.samplePublicVar = "samplePublicVar";

— PRIVATE
–[[
This property is designed to…
–]]
local _samplePrivateVar = "samplePrivateVar";

————————————–
— Constructor
————————————–
–[[
This is the constructor…
–]]
function me:constructor()

–TRACE
print ("TemplateClass:constructor()");

–METHODS
me:initialize();

–RETURN
return me;
end

————————————–
— Methods
————————————–

— PUBLIC
–[[
This is the initialize.
–]]
function me:initialize()

–TRACE
print ("TemplateClass:initialize()");

–DRAW

end

–[[
This method is designed to…
–]]
function me:samplePublicMethod()

–Test Private — It Works!
local _samplePrivateMethod_str = _samplePrivateMethod();
print (" _samplePrivateMethod_str : " .. _samplePrivateMethod_str);

return "samplePublicMethod";
end

— PRIVATE
–[[
This method is designed to…
–]]
function _samplePrivateMethod()
return "_samplePrivateMethod & ".._samplePrivateVar;
end

————————————–
— Events
————————————–

— PRIVATE
–[[
This event handler is designed to…
–]]
function _onSampleEvent()
return "_onSampleEvent";
end

— RETURN INSTANCE VIA CONSTRUCTOR

return me:constructor();
end
[/actionscript3]

1. Class Definition

In my solution I place the ‘TemplateClass’ class in its own ‘TemplateClass.lua’ file and treat it like a Lua ‘module’. You can see in ‘main.lua’ how I import and create an instance of ‘TemplateClass’.

2. Static vs Instance Members

The instance members in this demo work great. I had static methods and static vars working too, but broke them somehow. I have removed them from this demo. I’m confident is possible.

3. Publicity / Privacy

The instance members in the demo feature full, working publicity and privacy. Nice.

4. Inheritance

I have not included inheritance in this demo, but it is possible. I’m working on a simple game that I will post soon. I have 3 generations of inheritance going on and it works FAIRLY well. For my onscreen objects I extend using ‘display.newGroup()’ as a base. It is a bit ugly how to override methods (See the Ludicroussoftware.com link above), but it works. I’ll post that in the future.

The Output

[actionscript3]
Copyright (C) 2009-2011  A n s c a ,  I n c .
Version: 2.0.0
Build: 2011.704
The file sandbox for this project is located at the following folder:
(/Users/srivello/Library/Application Support/Corona Simulator/HelloWorldOOP-27E895459A9154336232E091AB34F950)

——————-
— HelloWorldOOP —
——————-

TemplateClass:constructor()
TemplateClass:initialize()
samplePublicVar : samplePublicVar
_samplePrivateMethod_str : _samplePrivateMethod & samplePrivateVar
samplePublicMethod_str   : samplePublicMethod

[/actionscript3]

1. Output Tool

By default the output comes through your Terminal (on mac). There is setup to get the output to come through Lua Development Tools (or other Eclipse based editor with the Lua Plugin). Once you build once, you leave the terminal and emulator open and just edit and save your code as you like. With each save, the simulator AUTOMATICALLY reruns the app and the terminal shows the output. The ‘build time’ is 100 Milliseconds or so. The speedy iterative development is great.

2. The Output

You can see in the output example above, the first few lines are outputted by Corona itself, then your custom

Conclusion

I created this demo as part of my evaluation of various mobile programming languages (Lua) and development environments (Corona SDK and Lua Development Tools). Coming from a (objectively speaking) really really spoiled development environment of Flash game development, I have the same basic gripes with Corona as I do with HTML5 gaming. The language (lua) is not fit for OOP. It is not intended to do so. Lua and Corona are indeed LIGHTNING FAST both at compile-time and at run-time. That is fantastic and cannot be under-stated.

The Corona SDK community is growing and offering some add-ons;

  • Lime – Tilebased gaming
  • PubNub – Multiplayer Gaming API
  • More community projects…

And now a few tangents…

Do I Need OOP?

No. But for me an implied architecture (implied within the built-in language features) of OOP or component-based development greatly speeds up development for me. I’m able to get more feedback from the IDE and reuse code more effectively. Many developers prefer procedural programming. I’m not sure why. If you have an opinion please post below. We will see TONS more gaming built upon the horrible limitations of JavaScript. If you love JavaScript, that is great. For me its not the right tool for game development.

Some OOP Solutions for Corona;

Upon a quick look, each appears to be valuable. Not sure which is the most full featured yet. In the future I may create a demo of each for comparison’s sake and blog about it.

Do I need a strong IDE?

Yes. I’m dumbfounded by developers who defend using text-edit as their tool of choice. Sure there is an warm-fuzzy feeling about being so ‘raw’. But an honest appraisal of your productivity will trump that if you are a serious contributor to your industry. Spend a few hundred dollars, spend a few thousand dollars on performant hardware and legally-licensed software designed for your productivity. Be a professional.

Game Development Environment Utopia

In my research in gaming technologies (Many, many HTML5 frameworks, Flash Platform, Unity3D, iOS, Android, Cross-platform iOS/Android), I am evolving an idea for the ideal game development setup. This list will probably change over time. The dream is a setup that works for small game projects and can scale up to large team projects.

  • Fast Code-Test-Code Cycles – Under 1 second allows for optimal iterative development
  • Fast Run-Time Performance – Stable 30 frames per second or greater across target devices
  • Great IDE – Project creation, project compilation, project debugging (breakpoints, stack/heap introspection), intellisense on built-in and custom libraries, etc..
  • Strong Typed Language – Implicit intent in your design, IDE-feedback/errors/auto-fixes, generics, deep refactoring, etc…
  • Scalable Graphics Pipeline – To facilitate multi-screen development. Vector source with run-time conversion to raster seems to be the best setup yet for 2D. Streaming textures is ideal for 3D.
  • Implied Architecture – OOP (ex. Java) and/or component based (ex. Unity3D)

Stay Tuned

  • I have created a complete game using Corona. A tutorial, HD Screencast Video, and full source code are coming soon.

Questions for the Readers

  • Do you a better OOP setup? Fork my code and push a solution. Great!
  • Know how to setup LDT to show debug output and breakpoints? Post a comment below!
  • Can you setup LDT to show intellisense (auto complete) for the Corona SDK classes? Post a comment below!

New Corona Book Released!

Packt Publishing has published a new exciting book on Corona SDK – Corona SDK Hotshot!

If you’ve used the Corona Software Development Kit to build your very first new mobile app, you already know how easy it makes developing across all the pieces of this fragmented market. This book upgrades your knowledge of Lua and the Corona API with designs, habits and advanced concepts to speed your development and create more exciting apps.

Corona SDK Hotshot will show you how to combine advanced Lua features such as coroutines and metatables with Corona’s sophisticated tools, including physics and networking, to develop exactly the game or app you or your customers need, quickly and with an eye towards updating your app with improvements in the future.

Corona SDK Hotshot will expand your basic knowledge of Corona with an insight into making the most of its event platform, using physics wisely and easily, and moving on to advanced programming tasks like path-finding.

You will focus heavily on how to keep your programs understandable as they become more complicated, by using modules and events to divide it up. You’ll practice ways to make AI scripts and map files easily understandable to designers and other collaborators, and use networks like GameCenter to publish progress.

The last projects will combine the full range of covered material to illustrate how you can produce sophisticated and exciting apps as a Corona Hotshot!

Using a project based approach you will learn the coolest aspects of Corona SDK development. Each project contains step- by-step explanations, diagrams, screenshots, and downloadable materials.

Get the book here: http://www.packtpub.com/corona-software-development-kit-hotshot/book

Next Steps

  • Hello World – Download the full source code*
  • Hello World OOP – Download the full source code*
  • Hello World OOP – Watch the HD Screencast Video Tutorial*
  • Checkout More Tutorials on LearningCorona.com (Fantastic!) and DesignerSandbox.com

*See ‘Member Resources’ below.

Member Resources

[private_Free member]Enjoy this members-only content!

Source Code

HD Screencast Videos

[tubepress video=”43251034″ embeddedHeight = “350” embeddedWidth = “550” showInfo = “false”]

[/private_Free member]

Considering Flash-To-Mobile Development

THE CHOICES

Software development has gone mobile. We see a large audience using smartphones and tablets, and as developers/marketers/entrepreneurs we want in. When planning such a project there are myriad decisions.

CHOOSE – THE PLATFORM

The choice of target platform (e.g. iOS) and target device (e.g. iPad2) is a primary consideration. Apple’s iOS hits the majority of the market but with time others will mature and may offer more competition. Moreover to hit your market you may be best served to offer your software to more than one platform and more than one device-per-platform. Quite quickly a rather conservative project can target 5-10 unique pieces of hand-held hardware.

CHOOSE – THE DEVICE

Each device offers unique features. The market-penetration, platform, processor-speed, input-capabilities, screen-size, and other factors are all important. Two major form-factor camps are ‘phone’ size and ‘tablet’ size. There is some overlap between these categories such as the Samsung Galaxy 1000.

CHOOSE – THE MONETIZATON

There are many monetization schemes possible. Here are a few of the popular ones;

  • Free – To gain experience and reputation.
  • Freemium – Offer a free version and market within the experience for a pay-version with more features.
  • Ads – Integrate video ads, animated ads, or still ads into the experience.
  • Micro-transactions – Offer bite-sized purchase opportunities which enhance the experience.

CHOOSE – THE DEVELOPMENT PATH

When the platform(s) and device(s) have been chosen, the path to develop must be chosen. In general there are two strategies

a) Native App Development – This means you use the 1st-party language (and tools) offered by the platform creators. This means using XCode tool with Cocoa framework coded with the Objective-C language when developing for iOS. Native development generally offers the very best potential performance (i.e. for high-end gaming) and tightest integration to the devices (e.g. detect battery level, etc…) and OS/marketplaces (e.g. iOS in-app-purchase).

b) Non-Native App Development – Many 3rd parties offer code libraries and tools to ‘speed up development’. Some of these are in the native language and some are not. Some of these non-native solutions offer the ability to ‘code once (so to speak) and deploy to multiple platforms’.

c) Mobile Web Development – Instead of a standalone application, an experience can be made available via web-browser and development to fit the size of the target (mobile) device(s). With HTML5 much is possible, but in general this is used for less-expressive less-device-specific experiences. It can also be a very inexpensive way to ‘break into mobile’, as you can use assets/code from your existing website..

CROSS-PLATFORM DEVELOPMENT

While the ability to develop one project for multiple platforms offers many advantages in saved development time and ease in maintenance, it also offers many challenges. Designing a compelling application that takes advantage of the unique features of each device and looks polished on the dizzying array of screen sizes out there can be daunting. For Flash-To-Mobile there are many resources on Adobe’s Mobile Devnet to help you learn the basics.

BACKEND

It is possible for an application to be self contained, including all data/assets with the original install. This is common for games. However many projects require internet connectivity. The data/assets loaded can reside on existing servers outside of your control, or can reside on your own servers. Custom backend solutions using typical backend languages (c++, Java, PHP, Python, etc…) may also be required. All of this depends on your particular project. In general any of the development-paths can contact any of these backend solutions, but some may connect more easily than others.

EXAMPLE…

Let’s assume you have a great new game and want to capture a ‘big audience’ with ‘modest investment’. If the application does not require deep-device-integration a recommended choice is to target both iOS (iPad1/iPad2, iPhone3G/iTouch3G, iPhone4G/iTouch4G) and Android (various devices). If your team has Flash expertise the Flash-To-Mobile publish path may be ideal.

FLASH-TO-MOBILE

With Flash CS6 and more-so Flash Builder 4.6, Flash/Flex developers can publish ONE codebase to MULTIPLE platforms. Using Adobe’s AIR 2.7 (latest public release) you can develop many platforms & Devices.

Compatible Target Platform/Devices: Web-Browser (Mac+Windows+Linux+Non-iOS Mobile Browsers), Desktop (Mac+Windows+Linux), iOS (Ipad1+Ipad2, iPhone+iTouch 3rd Generation, iPhone+iTouch 4rd Generation-Retina), Android (Myriad Devices), Blackberry Tablet OS (Blackberry Tablet).

Supported Flash-To-Mobile Device-Specific Features: Flash-To-Mobile does offer view-persistance, data-persistance, video playback, still-camera capture, still-camera-roll save/load, internet access, in-app web-browsing, accelerometer/gyroscope, Microphone, Geolocation, Multitouch, File-system access. Not all devices offer the same features. In the future ‘Native Extensions’ (see below) offer a solution.

Project Setup: A recommended options is one bulky Flex Library with (most) all code and assets, and then one Flex Project *PER PLATFORM*. You add/edit to the library and publish each of the projects as needed. You can test with an mobile-emulator (fastest) window that appears on your computer, or on the device via USB (best to test hardware features like accelerometer. The ‘flash’ code is converted to ‘native code’ (so to speak) before deployment.

Deployment: Upon completion the platform-specific file is uploaded to the platform-specific marketplace (e.g. iTunes’ App Store for iOS). A Flash-to-Mobile project sits along-side native applications. Ostensibly users have no idea the application was developed with non-native tools. The marketplaces do not delineate this or otherwise make that info available in any way to users. The end-user experience can be indistinguishable from a native app (project type and project polish depending).

NATIVE EXTENSIONS

In light of the ‘Device-Specific’ features listed above, Flash-to-mobile currently leaves us without everything we may want to do (e.g. iOS in-app-purchase). The yet unreleased (release date is ‘early October 2011’) Adobe AIR 3.0 will include ‘Native Extensions’. In short, this allows for *ANY* Flash-to-mobile project to access *ANY* feature on *ANY* supported device (Android / iOS / Blackberry Tablet). Developer will require knowledge of both AS3 (flash) as well as the Native language(s) on the target device(s) to add new features. Or your team can find free and premium extensions which the community could share. This is not just for mobile, this technology will also allow AIR on desktop computers and AIR on TV’s to integrate with those devices too.

LINKS

Native Mobile Development

Marketplaces

Non-Native Mobile Development – Flash-To-Mobile

Non-Native Mobile Development – Others

THE FUTURE

Some of what is coming in the future is listed below.. This may or may not all be included in the very-next tools. Recently Adobe has announced What’s new in Flex 4.6 SDK and Flash Builder 4.6.

I. The Second Coming (Halleluiah) – Flash-To-Mobile Native Extensions

This future feature will ostensibly allow Flash-To-Mobile projects to access *ANY* feature on *ANY* targeted device (e.g. in-app-purchase on iOS).

Updated Febrary 23, 2012: See Here…

II. The Second Coming (Halleluiah) – Stage3D


Stage3D (Formerly codenamed ‘Molehill’) is a set of API’s available in the future that will ostensibly allow Flash Browser projects (using Flash Player 11) and Flash-To-Mobile projects (using Adobe AIR 3.0) to show high-grade hardware rendered 3D. Finally, the Flash Platform can truly compete as a 3D gaming engine. The same API (despite the name) can also be used for radically improved 2D gaming performance too.

NOTE: These API’s are low-level and challenging to understand. We expect 3rd parties will wrap this functionality with easy-to-use API’s for free/premium use.

Update March 10, 2012: See Here…

III. The Second Coming (Halleluiah) – Air 3.2 = Stage3D for Mobile + Many Stage3D Frameworks

So with AIR 3.2  (See Adobe Press Release) we can use Stage3D for mobile. This means GPU-Accelerated graphics on iOS/Android. I think there is a marketable benefit on getting the Flash Player to compete against other 3D gaming solutions (such as Unity3D) and perhaps compete less with emerging 2D gaming solutions (such as HTML5 gaming) so I can sympathize with Adobe’s (better late than never) focus on 3D for Flash. This article “Why Starling (or any other 2D framework on top of Stage3D)?” explains some really good reasoning.

[tubepress video=”ZPHATCbnHE0″ embeddedWidth=”500″ embeddedHeight=”350″]

Mind-blowing Demo’s of AIR 3.2 on mobile

Regardless of why, Stage3D is here, and Starling’s power lies in how it uses the Stage3D – first available in Flash 11 and AIR 3.0. Stage3D is designed for GPU accelerated 3D. While its possible to use the Stage3D API’s directly, it is very difficult. There are 3D frameworks for AS3 , but for many game developers we can exploit its power for 2D gaming. That’s why Starling focuses purely on 2D. So an API like Starling helps developers make great content – quickly.

AS3 frameworks use Stage3D for 3D gaming;

AS3 frameworks use Stage3D for 2D gaming;

Key Articles I’ve written on the subject

Stage3D Games

Spaced Away

Spaced Away

Falanxia brings its FWA Award –winning space physics puzzle game to both iPad and your web browser.

Play game Learn more

Angry Birds Facebook

Angry Birds Facebook

Join your friends on Facebook to take out Rovio’s famous pigs with enhanced special effects.

Play game Learn more

Waste Invaders

Waste Invaders

Waste Creative’s tech demo lets you blast aliens at a silky smooth 60 fps, across browsers and iPad, with Stage3D.

Show demo Get the source