Guest Post: We put the brakes on Flash

Share on Facebook0Share on Google+3Tweet about this on TwitterShare on LinkedIn0

Alright, alright — so  Carlos’ post about Flash last week seems to have ruffled a few feathers (as was his intention! :-P). So, now allow me to point you to Exhibit B.

Gianluca Pinoci is a former Flash fanatic. A few months ago, his agency BOOM Interactive was commissioned by British auto brake maestros Ferodo to build a branded app.

The result was the Ferodo Race Challenge game for iPhone, but not without some initial (Flash-related) hiccups…

Gianluca Pinoci, BOOM Interactive

I wanted to share my experience with other developers in the Corona SDK community — particularly with some of the technical challenges involved in developing a top-down racing game, which is different from the more popular platform-based games developed in Corona. Not only did I transition from Flash to Corona, but I learned that Corona SDK really can deliver with a much more efficient effort! 🙂

When we were commissioned to develop the Ferodo Race Challenge app, our confidence was high. We had never heard of Corona so, being Flash developers since the beginning of time, we believed Adobe was the answer. Since Adobe was pushing CS5.5 so strongly, we had no reason to doubt that a Flash top-down racing game could be delivered to iOS and Android via the AIR packager.

How wrong were we!

Once we started the development of the game in AS3, our confidence started to drop as fast as the frame rate. By the time we added a large graphic for the track, applied a physics engine, and implemented steering controls, we were already down to 12-15 fps. It was evident that there were tremendous performance issues with delivering a game like this on mobile.

After attempting many workarounds — trying a GPU based physics engine, dropping the engine altogether, and even bribing Adobe to give us a copy of the AIR 2.7 SDK — we decided to abandon Flash.

That was a scary day because the road ahead was uncertain…

After much searching on the web and lots of feature-comparing, Corona was the one prospective SDK that stood out to us. I was still a little wary about learning a new language (Lua) in the tight timeframe. So, I spent a very geeky weekend by going through the whole API documentation. I had never heard of Lua and, even though I’m not the best programmer in the world, I was able to pick it up in less than two days. The secret is that Lua, being a scripting language, is extremely simple and very similar in the syntax to the fun-to-write ActionScript 2.

This is why the development team at BOOM Interactive decided to adopt Corona for the Ferodo Race Challenge app. For the technically-minded, interested in the specific challenges we faced in developing this top-down racing game, please keep reading!Also, I must give kudos to Ansca Mobile for the way they structured the documentation: general introductions, specific API docs, tons of samples and even full game templates offer everything one needs to know to start and complete a project. Not to mention the resources offered by the community in the forums and in the Share Your Code section — simply invaluable!


Physics engine in a top-view game

We’ve all seen Corona’s capabilities in physics-based platform games. But not many top-view racing games have been made with it. The general rule to use a physics engine in top-down view rather than side view is to simply kill gravity, but that brought a side effect, quite difficult to get around: orthogonal velocity. When the car gained speed, going up or down on the screen, orthogonal forces started to push the car from the side, bending its trajectory until the car flipped and faced the opposite direction!

In Flash’s Box2D, there is a function called killOrthogonalVelocity which applies a ‘friction’ in a direction orthogonal to the body’s axis, therefore keeping the car straight.

Due to the lack of time to experiment, we had to find the quickest way to resolve this issue. This was done by using a mixed approach.

For controlling the car, we created functions to set the linear velocity (position) manually at every frame and to compute all necessary values like speed, acceleration, deceleration, ground friction, steering friction and steering acceleration. Basically, the approach used in classic games without any physics engine.

We then used the physics engine to deal with collisions: set game boundaries, trees and obstacles, opponents and most importantly determine whether the car was on the track or on the grass (this was a tricky one, more on it below).

Corona dealt with the mixed approach really well, never having an effect on performance.

Although the mixed approach worked fine for the purpose of the game itself, we’d still like to get the game working using solely the physics engine. Few days ago we discovered that someone contributed their Lua version of the Vector2D class on GitHub. We’d love to use this class to contribute our own version of the killOrthogonalVelocity function to the Corona community — maybe even provide a top-down racing template. If someone reading is experienced in multiplying 2D vectors, do get in touch!


Camera movement

When we moved to Corona we weren’t sure of how to implement a camera following the car around the track. This is where the community proved its value. There are a lot of contributions on the site forum and we cracked this task in no time by grouping everything in one main object and using no more than 5-6 lines of code to move it across the screen.

Once more, we were genuinely surprised on how smoothly Corona dealt with this, especially after seeing how poorly Flash was doing. Not to mention that the track image is 2048x2048px and so is the shadows layer on top of it!

I guess having a full OpenGL-ES rendering engine really paid off for Corona.


Scene management: the Director class 

What to say about the Director class. It’s the true shiny diamond of Corona’s contributions! Many thanks to Ricardo Rauber — don’t forget to donate a few dimes because, if you’re developing an app in Corona, you’ll most likely end up using his class.

It is extremely simple to manage different scenes, apply smooth transitions between them and clean up previous scenes’ objects from the memory.

Regarding the latter point, do make sure you use at least version 1.3. We ran into some issues with grouped graphics not properly being reset when starting a new game with v1.2. When testing on iPhone this behaviour occurred rarely but when we started to test the game on Android this would occur almost every time. All it took to resolve the issue was to update the Director class to 1.3. A real life saver!



The ability to support multiple languages is generally a must when developing an app for large corporations. Corona did not fall short in this area either. In the “Code Exchange” section of the Corona site, one can find the Rosetta module which is a great and ready to use utility.

But since Lua offers great flexibility, it was easy for us to create our own custom solution. We wanted the application to come up directly in the user’s preferred language, without the need of having to choose a language at the start – while still offering the option to switch.

By using the SDK command system.getPreference(“ui”, “language”) we were able to know which language the user had the phone set to. Consequently we loaded a specific language module to fill a global table with the language strings found in the module. Of course the app defaults to English if the user’s preferred language is not among the supported languages.

Noteworthy is the fact that, while the SDK command above is cross-platform, the returned values are not. For instance, iOS returns language codes (en for English) while Android returns the Locale ID in decimal format (2057 of British English, 1033 for American English). Just something to consider when dealing with languages. For a full reference of Locale Codes go here.


Track/Grass collision detection: triangles vs. Bézier curves
(Carlos loves those!)

Until tackling this task, the development had proceeded almost smoothly. But it did come to a halt when we started pondering the best way to determine if the car was on the track or out on the grass. Our objective was simple (so we thought): draw the track outline as a physical object, set it as a sensor and use collisions to determine if the car was either in or out.

There are many third-party tools that can be used to draw collision objects in Corona. Most of them are very reasonably priced and easy to use, but most of them are particularly geared around platform games/levels. The two that seemed most appropriate to our needs were PhysicsEditor and Corona SVG Level Builder.

PhysicsEditor’s simplicity was a breath of fresh air. The Autotrace functionality does exactly what it says: it traces the outlines of your sprites and lets you control the amount of vertices created. Above all, it solves Corona’s limitations (objects cannot have more than 8 vertices) by stitching together triangular shapes. This way one can generate a parent object with as many vertices as one needs.

Even though the generated shape was not pixel-perfect (not being curved) we were happy enough with it. The only problem was that the car generated collisions when crossing the boundaries of each of the child triangles and not only on the parent object’s boundaries.

That was not the desired effect but it did depend on how Corona deals with complex objects. It is indeed a handy feature to have collisions on each of the child objects, but it would be just as handy to be able to disable such behaviour (a feature request for Corona perhaps!). Therefore we moved onto the SVG Level Builder and never looked back!

Corona SVG Level Builder is, simply put, an amazing tool. It lets you create whatever shape you want by drawing in Inkscape (an Open Source vector graphics editor) and then setting the physics properties with the built-in Inkscape XML editor. We found InkScape incredibly easy to use in tracing Bézier curves and optimizing the points count.The SVG parser script did a great job by loading those curves seamlessly into the app and the collisions were truly pixel-perfect too!

All was left to do was to adjust the ground friction variable whenever the car was detected on the grass. This would have been pretty easy if the car shape was to be a circle rather than an 8-vertex shape, but by using two border lines rather than one we got the track/grass collision to work just perfectly!


iOS vs. Android

As you know, Corona delivers cross-platform apps. There are still few APIs that are slightly inconsistent, such as the video player, but generally one can assume that the exported app will behave identically on the two platforms (apart for native components of course).

Whether you are up against a mission-critical commercial deadline or not, it is important to allocate enough time for testing, squashing bugs and resolving unexpected crashes.

In our case for instance, we knew the game was very graphically intensive, so during the test phase we paid specific attention to the iPhone 3GS, having almost half of the hardware capabilities of an HTC Desire. To our surprise, the iPhone never crashed while it was the HTC Desire that caused major headaches — not being able to even run the app for more than one day! Reasons can range from texture memory limits to memory leeks or missing permissions on Android.

Specific reasons aside, if you know your app could push the boundaries of a device, always do your research and some testing ahead of delving into the development.


Share on Facebook0Share on Google+3Tweet about this on TwitterShare on LinkedIn0

This entry has 9 replies

  1. Thanks for the amazing words about Corona SVG Level Builder! I’m extremely pleased that it had an important role in your development process!

  2. Thy says:

    Wonderful post! There are some great tips in here – the best lessons are those from direct experience – and a wonderful look into how to handle the other side of coding – the project itself. Thanks!

  3. pdichone says:

    Thanks for sharing this! I have learned a few lessons from your post. There’s a lot I need to learn, but Corona SDK makes the process easier a thousand times!

  4. Awesome, except that AS2 was not fun to write, LOL. AS3 is a pretty solid OOP language.

  5. Adam says:

    Alfred – they didn’t use Corona SVG Level Builder, and the support for your product has been nothing less than appalling. In fact I’ve asked for help and simple answers several times over the past two months and am yet to have a single reply. Due to this I asked for a refund under the UK Sale of Goods Act, which you have also not replied to.

    Your ‘tool’ has been deleted, and I’m now using Physics Editor. I recommend everyone else does the same.

  6. Wooo, Rosetta got a shout out 🙂 Didn’t really think anyone even really knew about it.

    And as you say, Lua is so great it is easy to make something specific to what your project needs, which is exactly what Rosetta was to me 🙂

  7. Like Alfred R. Baudisch said, I am very pleased to know that Director had a very important contribution to your work! Thanks for the wonderful words.

  8. Nicholas G says:

    @Adam – I believe they did I mean it says this in the story :

    “Corona SVG Level Builder is, simply put, an amazing tool. It lets you create whatever shape you want by drawing in Inkscape (an Open Source vector graphics editor) and then setting the physics properties with the built-in Inkscape XML editor. We found InkScape incredibly easy to use in tracing Bézier curves and optimizing the points count.The SVG parser script did a great job by loading those curves seamlessly into the app and the collisions were truly pixel-perfect too!”

    Would you care to challenge why you think they would say that and NOT use it?

    Also, I use SVG level builder, 2 times I have written to Alfred (a few months back) and he helped me out.

    I will admit, his tool is a bit overpriced compared to the ULTRA VALUE of PhysicsEd (20 bucks!) but you get more pixel perfect results with SVG level editor. Although PhysicsEd he’s cooking up some cool new features so we shall see. Additionally, I think SVG Level builder should have come with samples and how to use it. Tools like LIME, and PhysicsED came with samples.

    With that said, I still think the tool is great. After I bought other tools, I realized the price was high. He’s thinking about raising it to the full price of 129 bucks or something like that. I already own it, but for those that don’t have it you should get it now as I would not pay that much for a tool like that.

    For director – yea this tool is great and it’s FREE (people should donate!). I’m still learning Director, but more focused on getting my games developed then integrating director later on.

    By the way, the game is cool I like it.


  9. @Adam: I have just seem your comment here. Could you contact me via e-mail? I’m sorry for any trouble, but I’m really not aware of your issue. I normally answer support requests in up to 2 hours! The maximum the support may take is a day.

    Today I released the 1.3 version which has so many new features that it is impossible to put here, anyway you should have received by e-mail. It also comes with dozens of examples.

    Also a video tutorial and a full game source code is being prepared now.

    @Nicholas: Thanks for the words! Actually PhysicsED is not an *opposite* tool to Corona SVG Level Builder. It is actually a tool to be used with Corona SVG Level Builder if you need to put very complex shapes: i.e. export complex shapes and use with SLB.