Skip to main content


Williams(2008) indicates the key design principles for non-designers:
    - Alignment, Repetition, Contrast and Colour -
These tenets were adopted in the early design process, the background uses a blue/purple colour scheme, which repeats focusing attention on the foreground characters. All buttons use a common look, and location that contrasts vividly with the background.

Diagrams of early screen layouts and design ideas


Corona SDK offers extremely useful APIs to handle graphics, including a Sprite library, which provides a very simple way of animating Sprites.
The following code creates a sprite object, from the spritesheet, which has a regular 256 x 256 size. Because the images are regular it can then set up a sequence - here named “running” which starts at frame 1 and steps through to frame 7, over 1 second.

local ninjaSpriteSheet = sprite.newSpriteSheet( "ninjaSpriteSheet.png", 256, 256 )
local ninjaSpriteSheet = sprite.newSpriteSet(sheet1, 1, 7)
sprite.add( spriteSet1, "running", 1, 7, 1000, 0 ) -- play 7 frames every 1000 ms
local running = sprite.newSprite( ninjaSpriteSheet )

Many mobile systems require fixed sized sprites sized in a power of 2, due to graphics constraints. This can lead to excessive texture memory use/wastage.
For example a 140 x 140 pixel image has 19600 pixels, each with a default 32 bit colour depth and brightness, so 4 bytes for each pixel (though practically less with compression) Our 140 pixel square would have to sit on a 256 x 256 spritesheet with padding (too big to fit on a 128 x 128 sheet)
If each sprite action needs at least 8 states to simulate motion, then precious memory is very swiftly used up.
By packing multiple sprites onto a single sheet a great reduction in memory usage can be achieved, with further reductions using 16bit colour, and image dithering.
Following tutorials I created my initial Spritesheets by hand, but found them fiddly, as unless the images were all the same size the layout and code required became increasingly complex.

simple original hand made spritesheet, created using photoshop.

Applications like Zwoptex, or Texture Packer arrange sprites onto a sheet optimizing space, and provide indexed locations for the images in a data sheet.using sprite sheets: compare small sprites to sheet-

Spritesheet of animated objects in ND vs PR created with Photoshop and ZWOPTEX texture packer.

Zwoptex creates a data sheet as well as efficiently packing the images to use the least space.

  name = "barrel1.png",
  spriteColorRect = { x = 0, y = 2, width = 80, height = 158 },
  textureRect = { x = 0, y = 0, width = 80, height = 158 },
  spriteSourceSize = { width = 80, height = 160 },
  spriteTrimmed = true,
  textureRotated = false

For the next iteration of the game I have bought another application - Spine, which provides a skeletal structure for sprites, providing a far finer degree of control.

Screenshot of “spine” Sprite manipulation application


As Lua is a dynamic language there is no compiler feedback to highlight simple mistakes, and typos. There is some support in terms of syntax from the TextMate Lua bundle, and the LusGlider IDE, but it misses case sensitive variable names, and similar errors.
Because the language is dynamic at runtime, it needs to be run to test the behaviour of dynamically generated content.

    --create ground
    for i = 1, 20, 1 do
        groundType = math.random(4)
        local groundBlock = display.newImage("images/ground"..groundType..".png")
        groundBlock.x = (i * 127) - 127
        groundBlock.y = groundLevel

Here the variable groundblock gets assigned a image file by concatenating the groundType variable with a string. This can't be checked with static code review.
I fully intended to use an OO approach for the project, and have separate unit tests. Practically this doesn't work well in Corona, the unit testing libraries are designed for plain Lua and don’t mesh well with Corona extensions. This could lead to frustration for developers who prefer a test driven development approach. A larger application that doesn’t cycle through all components within such a tight timescale as this game would need to carefully consider how to incorporate unit testing, this will be particularly true for identifying stress related defects. These may remain hidden until the system is put under load, and that load may depend in part on the platform to which the app is deployed.

Debugging physics by using DrawMode.
Corona does include some useful tools to allow dynamic analysis of physics based situations - DrawMode as demonstrated in the VPD allows the individual physics objects to be seen in a hybrid mode, overlaid on the graphics, or as pure physics objects. I used this in an early version to determine why an object was “falling” off the screen, and found it had a “round” physics body rather that the anticipated square.

local physics = require("physics")
physics.setDrawMode("hybrid") --overlays collision outlines
--physics.setDrawMode("debug") --shows the collision engine outlines of bodies only
--physics.setDrawMode("normal") --default state with no collision outlines.

Bug Tracking.

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.

Rapid development.

Corona claim 10x faster development- certainly offers compelling examples -
2 lines in Corona Lua, to achieve the same as 306 lines of Objective C ,
and 100 lines of java and even 4 lines of Flash Actionscript:

Building the game highlighted that Corona does use a significantly smaller amount of code to achieve the desired results, especially when working with OpenGL. The simulator refresh function is far faster than compiling and building, and the capacity to build to Android and iOS in the simulator and deploy to devices is incredibly useful. Graphics are scaled well, providing correct build settings are provided. Personally I’m very at home using Netbeans so using Lua Glider worked very well for me, but even the basic environment was a pleasure to use, and very easy to set up, in contrast to say Xcode or Eclipse.
However because of the lack of compiler support some small errors can take a very long time to identify, which isn’t helped by the slightly strange syntax Lua has adopted.
The priority of some Lua optimisations like using “local” variables also dictates the shape of the code, which leads to some rather inelegant structures. Memory leaks are par for the course, and I used the RG super meter to detect and fix these, mainly down to forgetting to destroy objects once they have been used.

The Corona claim of 10x faster development : faster/ [accessed on 22-7-13] seems to clash with Brookes assertion that
"there is no single development, in either technology or management technique, which by itself promises even one order of magnitude [tenfold] improvement within a decade in productivity, in reliability, in simplicity."

Whilst the changes in OS are often not as marked as those between iOS6 and iOS7(in beta) the contrast here does serve as a warning to the way in which an applications look and feel can be changed markedly byexternal factors. If one does not update an app to match the native look and feel it may seem “old fashioned” or may not work at all, requiring legacy code bases to be maintained for users on previous OS.

Screenshot showing marked design differences in iOS6 left and 7 right - source

This is less of an issue with games which don’t use native UI components, but does make creating a familiar navigation structure more complex.

Optimisation and analytics.


I used a third party library “RG Super Meter” to identify inefficiencies in my code, and highlight memory leaks.
RG SuperMeter provides information using a frames-per-second meter, and main and video memory meters that graph the total memory usage over time. Piecemeal tools like this, whilst very useful are not as powerful as the native tools provided in Xcode and Android studio.

Deployment issues

Whilst the process of building for iOS and Android is simple in Corona, the business side, of gathering a provisioning profile, and developer account, and submission of an application to the app store, is far from straightforward.
Ohrt and Turau(2012) indicate that the safest way for a developer to avoid rejection of an app for technological reasons is to use the SDK provided by the target OS vendor.
However, it is clear from comparing the Apple app store with its rigorous review process, and the Google Play Store, which offers a more “open frontier” approach, that App rejection and the arbitrary implementation of guidelines whilst difficult for the iOS developer, also mean that the iTunes market place is far better curated than Google’s Play store.


As expected working in Corona provides a very rapid development environment.
Discussions with developers indicate the 10X faster claim is reasonable, within the frameworks limitations.


Ohrt, J., Turau, V.- Cross-Platform Development Tools for Smartphone Applications - Hamburg Univ. of Technology - Hamburg, Germany - Computer (Volume:45 , Issue: 9 pages 72 - 79 ) Sept. 2012
Williams, R. (2008) The Non-Designer's Design Book (3rd Edition) - Peachpit Press.
Heitkötter, H., Hanschke, S., Majchrzak, T.(2013) Evaluating Cross-Platform Development Approaches for Mobile Applications - Web Information Systems and Technologies - Lecture Notes in Business Information Processing Volume 140, 2013, pp 120-138
Toz Software (2013) CoronaBlitz competition details - Available at: 38370-coronablitz-1-theme-and-information/ [Accessed on 16-8-13]
King, T., (2012) Build an Endless Runner Game From Scratch: Using Sprites- Available at: http:// [Accessed on 21-7-13]
Raj, R. and Tolety, S.B. (2012) A study on approaches to build cross-platform mobile applications and criteria to select appropriate approach. India Conference (INDICON), 2012 Annual IEEE
Publication Year: 2012 , Page(s): 625! - 629

Popular posts from this blog


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.

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...