Skip to main content

Using Corona SDK

Corona Architecture Overview

Diagram showing the Corona SDK architecture -source Walter Lua - CEO Corona

The development process.

I built the game "Ninja Dinosaurs vs Pirate Robots" in a series of 4 development sprints. I used a familiar game format, the "Infinite Runner" to guide the overall structure, and built the game using the Agile development methodology and Simplicity principle: "simplicity: write the simplest code to do the job, do not provide hooks in your code for ‘future needs" - this prevents scope creep.
Studies by Jones (2009) have shown that Agile is most effective with small teams. Agile focuses on swift iterative cycles creating instances of working code, which are constantly reviewed and guided by the end users rather than a rigid commitment to a fixed system architecture. It values working code over heavy documentation, as might be encountered in a more traditional waterfall development approach.

Game Summary.

Whilst the game is an infinite, or endless runner akin to canabalt, or jetpack joyride in reality this style of casual games rarely last more than 2 minutes (when I’m playing anyway!):

Left - ScreenShot of the popular Infinite runner “Canabalt”, Right ScreenShot of “Ninja Dinosaurs vs Pirate Robots”
The Game is called Ninja Dinosaurs vs Pirate Robots. The game’s icon shows ninja dinosaur. When selected this launches the game. A Menu screen offers the choice of setting options, playing the game of looking at the high score. If options is selected the player can set the difficulty of the game and the volume using sliders.
If score is selected the player can see the highest score. If play is selected the animated player character sprite appears to run against a parallax scrolling background, and must overcome obstacles and defeat enemies. The object of the game is to survive as long as possible, and this is measured in distance travelled. The game is in landscape format, and supports but landscapeRight and landscapeLeft. The game runs on Android, or iOS, phone or tablets. It is designed for the iPad screen but should run in letterbox if scaled to other screens The player controls the game with touch events, a touch on the left side of the screen is a jump, double tap is a double jump. A touch on the right initiates an attack, throwing stars- “Shuriken”. Feedback to player is provided through animation, and sound effects. A score indicates progress, in metres travelled. A health bar indicates "lives" left. The game ends when the player loses all health, and offers the player a chance to tweet their score. As the game progresses it speeds up, becoming more demanding. Obstacles and enemies are generated pseudo-randomly. The game is controlled by a series of scenes, the menu, the game itself, the options, which allows volume and difficulty to be set, and the scores scene which shows high score.

The development environment

Diagram showing the breadth of tools required in the simple development environment used in this project.
Corona SDK is lightweight requiring only the download of the SDK, and a text editor. It includes a physics engine: Box2D, and handles Audio with OpenAL. The starter version is free and allows builds for iOS, Android, Nook and Kindle My initial development environment was a MacBook Air running Corona 2013.1135 and TextMate 2 with a Lua Bundle.
Launching Corona Terminal provides a trace of activity, and then opens the Simulator, which can be set to iPhone, iPad, or a range of Android devices.

Screenshot of basic development environment Textmate2, terminal and Corona SDK.
Code doesn't need to be compiled - Lua is interpreted, and can be written on the fly, refreshing the simulator with CMD+R which is useful for testing, and far faster than building for devices. As the project grew to more than a single main.lua file I tried Outlaw, project manager, and eventually settled on Lua Glider IDE which is built on Netbeans 7, incorporating Git tools, integrated versioning and "diff", code folding (useful in Lua which tends to have large procedural files), and code completion.
Lua Glider has good linkage to the Corona Simulator, (other methods require double navigation), but unfortunately has poor (non-existent) documentation. Luckily Netbeans is my IDE of choice, and I felt at home right away. Non-obvious functions required a fair bit of research in the various fora. 
Before deploying to actual devices a complex and convoluted process of creating provisioning profiles and development certificates needs to be undertaken, however this provides a measure of security against malware for app store users.
The first version of the game was deployed to Android through Dropbox. This is a simple process in Corona. The simulator is launched, select File>Build as Android from the menu, and wait. The .apk is generated and saved to the selected location, and when opened on the android device installs itself. It ran well and user feedback was used to create the actions and tasks for the next iteration.

The features and bugs were created as "stories" in Pivotal Tracker, to enable effective feature and project management. 
Basic debugging takes place on the fly, Lua Glider has TODO comment scanning functionality, that allows custom Tags to be added to scripts, and tracked in the Action Pane, for the selected file, selected project or all open projects. Further filtering can take place with extensive logical constraints applied by file, category and type.

Screenshot of Lua glider development environment
Because Lua is interpreted and not compiled there is little in the way of help from the IDE that one might get in Java for example. This makes the use of continuous testing, version control, and the ability to roll back to a working version all the more important, and the Git integration is a boon here. Identified bugs that don't prevent the game running are logged and registered in Pivotal tracker.
I set up a Jenkins server: a continuous integration system, in theory making it easier to integrate changes to the project, and obtain a fresh build. The automated, continuous build could in theory increase productivity, but this proved to be overkill, and I have not used it.

Framework quirks.

Lua starts counting at 1 rather than the traditional CS 0, this will take some getting used to. The build.settings file sets the Android manifest file and permissions, and also populates the iOS *.plist file these are critical, and require on device testing.


The Corona Simulator supports: CAF, AIF, and MP3 formats.
For Android devices, the sound needs to be preloaded with the media.newEventSound API. There is no volume control API for EventSound. It is intended for alert sounds and the volume is controlled
by the device's hardware controls.


Cross platform development in Corona requires some additional work that is handled automatically by the native development environments, such as creating a range of icons suitable for the different screen sizes with the appropriate naming convention. Another example is the range of default.png s that are required to support the different targets even on one platform:
Default.png (320x480 non-Retina iPhone portrait)
Default@2x.png (640x960 Retina iPhone portrait) Default-Landscape.png (1024x768 non-Retina iPad landscape) Default-Landscape@2x.png (2048x1536 Retina iPad landscape) Default-568h@2x.png (640x1136 Retina iPhone portrait)

Issues with reliance on 3rd party libraries.

Software and systems should have high cohesion and low coupling. Coupling describes reliance on external structures. The Corona SDK provides a way to build to various platforms and test and deploy on multiple simulators. In the starter version the Lua code created is "built" using a remote server, which avoids issues with local instances of Xcode, or Android JDK. However it does mean the process is very closely coupled and reliant on that service.
Whilst investing in a framework is a risk to developers, as the service may change or go away, Corona have just expanded with an additional $2m venture capital funding, and seem relatively stable, and time invested in learning Lua is a transferable skill.


Corona SDK is easy to pick up, and intuitive to use, it works well as a rapid development environment, and deploys products easily and reliably across platforms. It excels at graphic manipulation, but becomes less useful if trying to build more traditional menu driven business style applications that adopt the native look and feel of a device. However by the same merit using native APIs means relinquishing some of the look and feel of an application, which may spoil the overall effect. An example of this is the popular clean, minimalist design of iOS game Letterpress, which has to use the iOS gameCentre - launching a jarring green baize card table widget. Where look and feel is important, it may be better not to use native widgets at all.

Screenshots showing the contrast between the app look (left) and the generic iOS look (right)

Popular posts from this blog

Spine again - animating game assets

Laura Tallarday gave a neat demo of how to build an animation in Spine on the CoronaGeek Hangout, so I had a bash at chopping up an image and animating it.
The plan is to add some more sophisticated animations to the new game "Duck sized horse".. but as was discussed in the show adding a whole bunch of spine animated objects might hammer a mobile device... and as the aim is to have 100 tiny duck sized horses, I'd best choose another approach for them.

anyway here's a swaying viking...


Beta Beater

The Google Developer Console is really very very good.
It's logically set out, and makes it super easy to run a Beta test.
I'm on the tenth iteration of the final draft, and think I've got to a point where I can actually promote the app to Production.
The latest revision changed the icon set, and removed a load more cruft, slimming the app down to just 12.14Mb. I could strip out the iOS icons and lose a few more bytes but the original aim way back when I started on this project was to build a simple game that could be deployed cross platform, so I think I'll try and maintain just one codebase... as I really should submit this to the iTunes store too, to close the project.