When did you start programming? What first piqued your interest? If it became a lifelong passion, as it has with me, then you almost certainly have an interesting story to tell when answering that question.

My own story is in many ways unique in that I was most definitely in the right place at the right time at a special point in human history when personal computers were just coming into existence and, more importantly, just starting to enter the public consciousness. Through a bit of luck, coupled with a drive to do something I found enthralling, I was propelled down a very specific road in life that I am happily still traveling.

You see, as David said in Prometheus, “Big things have small beginnings.” (Your opinion of that movie will determine whether you find that line the best thing about it or just one of many cool things!)

The Corona SDK is in a sense this same concept in microcosm: when you look at what it is, and especially at how easy it makes a great many otherwise complex things, it’s really kind of surprising, perhaps even shocking, that you can do such incredible things with it with so little effort.

This book, I hope, will provide you with the foundation you need to take your idea—however small the kernel of the idea may be—and, combined with the Corona SDK, grow it into something huge.

Before I get to the Corona SDK itself though, allow me to be a bit self-centered and talk a little bit about myself!

A Long Time Ago In a School (Perhaps) Far, Far Away . . .

When I was around nine years old, my school district introduced a new curriculum dealing with computers. It was only a trial program and they didn’t know if it would get any traction, so they asked six of the top students in the school if they’d like to participate. As you can guess, I was one of those students (my grades subsequently sank down to much more, umm, let’s go with modest levels . . . but at the time I was near the top). I had heard about computers on Star Trek and other television shows, but I had never seen one in person to that point in my life and I didn’t really have an appreciation for what they were and what they could really do. In any case, being a science and electronics geek even at that age I of course said, “Absolutely I want in!”

So, for about an hour once a week I got to leave my regular class and head down to a small room with a couple of computers and learn how to program (after learning what they really were and could do, of course). We six initial students did this for a few weeks, but seemingly with each class the number of students that showed up shrank (it was completely voluntary and we could quit at any time). Eventually, it was just me left.

One day, I had gone to the computer lab after school and I discovered to my surprise that I wasn’t alone, as had always been the case before. On this day, another student (also named Frank, coincidentally) was there. It turns out this other Frank was quite a bit more advanced than I was at programming. He had written a program that at the time amazed me beyond words. What it did was draw a man, like so:

 O /
 #/
  #
 / 
/   

I know, that barely looks like a man! However, you have to understand that until that point all I had seen in person on a computer screen was plain old text. I mean, I thought it was extremely cool that I could have text that asked for two numbers and text that told me what they were when multiplied by each other—that on its own was cool! An actual graphical man, though? That was a whole other level of cool!

The program that alter-Frank made also drew the man in another slightly different way:

  O
 /#
/ # 
 | |
 | |

It would draw that first version of the man, wait maybe a quarter second, then clear the screen and draw the other version. The program did this repeatedly and the effect, for anyone that has ever drawn some pictures in a notebook and then rapidly flipped the pages, was animation!

Believe me: I realize just how silly all of this sounds when compared to our modern Xbox games. However, you have to try to understand what it was like for me: this was just astounding! He had essentially replicated what you do with a notebook and some drawing on a computer screen! He took a very simple, basic technique and wrote a program to do it, yielding something that, really, most people at that point hadn’t seen computers do.

Now, it didn’t take long at all before I realized that this conceptually simple technique leads quite naturally to something much greater: video games! The basic notion of drawing something on the screen, clearing the screen, and then drawing it slightly differently is, to this day, the core concept behind how a video game works in terms of what you see on the screen. It’s all a much more complex affair now naturally, but the basic foundation is identical to what my doppelganger showed me that day.

Before that week was out, I had written my first very simple video game that had graphics. As I recall, it was nothing but a simple Pong-type game, but that was enough. I knew I would be programming games for the rest of my life.

Back to the Future

A big part of working in information technology, where I make my living, is keeping your skills sharp. As a longtime developer and author, others recognize me as someone who strives to keep his skill set current and his abilities honed. As such, I frequently am asked by less-experienced developers for advice on what they can and should do to improve their skills.

My answer for a great many years has been three simple words: write video games!

There are a number of key benefits to writing video games, some less obvious than others.

First, writing video games requires you to tackle problems that you wouldn’t otherwise encounter in typical “business” programming, and while the solutions to those problems aren’t necessarily applicable directly on the job, the mental processes that go into solving those problems are.

Second, some of what you have to deal with when writing video games is in fact directly applicable! AI, data structures, performance tuning, and much more—these are things that come into play all the time in the business world just as often as in game development.

A third important benefit is that writing games is fun! This matters and shouldn’t be discounted, because programming for a living in nearly any environment—unless you happen to have the perfect job, I suppose—isn’t always as fun as you’d like it to be. Sure, for most of us developers, simply solving problems brings us joy, so we can derive happiness in our jobs where others sometimes can’t in theirs. Nevertheless, there are always periods that drag, always projects that you’d rather not be doing. Of course, it’s your job, so you do them anyway. Sometimes it’s also just very hard work that can be very stressful.

Writing video games is different, though, the very nature of what you’re programming is intended to be fun! The process of creating it is similarly fun!

Ultimately though, writing video games is a challenge, one that sharpens your skills and makes you a better overall programmer, and that’s why I always counsel developers to write games in their spare time.

The point of course being that whatever your goals for the games you write, whether it’s to make a million bucks or just to hone your skills, it’s one of the very best programming exercises you can do for yourself.

Hey, Wait, Isn’t This Book about the Corona SDK?!

All of that being said, programming games can also be hard. Especially when we’re talking about mobile game development, that can be very true. In the mobile space, you have an additional challenge of dealing with the multitude of platforms out there in consumers’ hands. Do you write your game for iOS? Do you write it for Android? What about Windows Phone? Or BlackBerry? Or webOS? And on and on and on in this ever-changing environment.

Of course, if you want to try to sell your work you’ll want to hit as many of those platforms as you possibly can to give yourself as much of a chance as possible at success, so now you’re talking about cross-platform development. That’s where it gets really hard! They all have different technological underpinnings, different ways of writing code, different languages, integrated development environment (IDEs), deployment models, et cetera. How do you pull that trick off?

There’s definitely multiple ways to go about it, some better than others. One way that has become very popular these days, and the way this book focuses on, is to find some third-party cross-platform library that solves the multiplatform problem for you. When you do that, in a sense you take a virtual-machine approach: the library presents an application programming interface (API) to you that it guarantees will work the same (mostly, anyway, as we’ll see in later chapters) across all the platforms it supports. You write your application to that API, which represents a virtualized machine, instead of targeting the physical platform natively. The library acts as an abstraction layer for you, keeping all the platform differences hidden for the most part. It’s not a true virtual machine in the case of Java, for example, but conceptually from your programmer’s point of view, it’s very similar.

That’s precisely what the Corona SDK is, or simply Corona for short from here on out.

Corona: History at a Glance

Corona is a product of Corona Labs, Inc., formerly Ansca Mobile. It was originally created by Walter Luh and Carlos Icaza, former employees of Adobe. Corona saw its first release in December 2009 supporting a single platform: Apple’s iOS, the iPhone more specifically, since this was before the iPad arrived (and the iPod Touch, for the purposes of this discussion, isn’t really any different than the iPhone). New versions with new features came fairly quickly following the initial release.

In April 2010 the 2.0 version of Corona was released, and this is when things really started to pick up as this was the first cross-platform release, now supporting not only the iPhone but now the iPad and, more importantly in a sense, Android. I don’t say “more importantly” in any way to belittle iOS but only to say that Android represents the first true cross-platform release (after all, the iPad still runs iOS).

January 2011 saw another big feature released: the ability to develop on Windows. Up until that point only Unix-based platforms, MacOS more specifically, could run the Corona toolset (which I’ll get to shortly).

April 2011 introduced another new target platform to Corona: Barnes and Noble’s NOOK Color tablet.

Over this whole timeline, Corona’s popularity began to grow. Many apps and games atop the charts of all the popular app stores were created with Corona, among them Bubble Ball (see Figure 1-1), the product of eighth-grader Robert Nay, which managed to reach the very top of the free-game chart in the iTunes Store!

Many other games have ridden Corona to high places on the charts and have brought in good money for their developers, and this is on all platforms Corona supports. Some other great examples of Corona include Engineer by Etherient, as seen in Figure 1-2.

In the interest of full disclosure, Engineer is actually my own game. However, another one that isn’t is The Secret of Grisly Manor, from developer Fire Maple Games, as seen in Figure 1-3.

As you can see, Corona is a horse you can most definitely ride to a win in mobile application development, most especially if you’re developing games. But, none of this really answers what Corona is and what it can really do, so let’s get into those details now.

A Tool That Works for You

Corona is a software development kit (SDK) that uses the Lua scripting language layered on top of C++ and OpenGL. It uses a proprietary OpenGL ES rendering engine that provides applications written with it automatic hardware acceleration. This includes sprites, a concept that we’ll get into starting in chapter 5, which are animated using the device’s graphics processing unit, or GPU. What this means in short is that without doing very much optimization on your part, the games (and nongame apps) that you build with Corona should be quite fast on most devices.

Corona also includes a transition library that allows you to do tween-based animations on sprites and other objects with a single line of code in most cases. If you’ve ever hand-coded animations before, then you realize how fantastic something like the following actually is:

transition.to(player, {
  time = 500, delay = 1000, alpha = 0,
  onComplete = function()
    print("Done");
  end
});

That’s a single line of code (albeit formatted across a couple of physical lines in a text editor) that fades an object referenced by the variable player after waiting one second after its execution over the course of half a second, and then displays a message in the console window (which you can open alongside the simulator for debugging purposes). The best part is that this goes off and happens without any intervention on your part. You don’t need to continually update the alpha property of the object over time, don’t need to update anything on the screen manually, none of that sort of stuff that is typical in most graphics-related programming. You can animate a great many properties of an object, all at once or separately, yielding some impressively complex animations—again, with very little code, and no ongoing work on your part.

In fact, it’s this notion of doing the complex with simple code that is a key concept of Corona, and you’ll be seeing plenty of that as you progress through this book. But for now, let’s get back to describing Corona at a fairly high level.

The Corona API is rich and extensive and provides a great many capabilities. As I’ve mentioned, sprites and tween-based animations are a big part of it. You also get native UI integration; audio API functions; the ability to interact with native device components such as camera, GPS, various sensors, and multimedia playback; fonts and text functions; and a highly robust built-in physics engine. You also get things like integration with online scorekeeping systems, database functionality, direct file system I/O, and analytics. You of course also get some of the more primitive types of APIs you’d expect such as math utilities, collections, cryptographical functions, and network access.

In other words, virtually everything you might need to build any type of application is almost certainly present in Corona, and if they’re not you can roll in any of a number of third-party libraries to augment your needs (I’ll talk about third-party add-ons in chapter 10).

You can run Corona on either Windows or OS X machines to do your development work, and it installs like any other application you’ve ever installed for either platform. You can download a completely 100% functional SDK from the Corona web site at http://coronalabs.com. In fact, now would be as good a time as any to go ahead and do that if you haven’t already. Go ahead, I’ll wait patiently for you!

The Corona SDK includes the usual SDK components including the API libraries, documentation, and examples.

More important, though, it also includes the Corona Simulator. The simulator is a cross-platform application that, as the name implies, allows you to simulate a target platform. It doesn’t simulate an iOS device or an Android device; what it does essentially is simulate an idealized device that supports the Corona API. You write your application to that API, not to the underlying platform you intend to target. The simulator then runs your code at more or less full speed. What this means to you as a developer is that what you see in the simulator is, 9 times out of 10, what you’ll see on a real device. As with all simulator/emulator applications, there’s sometimes some imperfection that sneaks through, but by and large you should run into very few differences between simulator and real device.

The simulator is actually a very simple application to use and looks like what you see in Figure 1-4.

You can run the simulator in portrait or landscape mode, whichever is appropriate to the application you’re building, and you can select from a number of different skins to give the simulator the appearance of a physical device. In the screenshot in Figure 1-4 I’m using the Android Nexus One skin. Selecting a skin not only changes the outwards appearance of the simulated device, but also changes the virtual screen size, allowing you to test your application across a range of screen variants.

You also have the ability to zoom the simulator to let you see details a bit closer. This can be especially useful when you’re doing your final round or two of tweaks to make sure everything is lining up exactly right. In addition to zooming, you also have the ability with the simulator to rotate the device various ways and to shake the device to exercise gyroscope functionality.

The very first time you start the simulator you will actually be greeted with the Welcome screen, as seen in Figure 1-5. From here you can do a number of interesting things. First, you can create a new project. This will create a template for you with all the basic files you need to have a working Corona application. You can do that and immediately run the application in the simulator. Naturally, you can launch the simulator itself and run an application you select in it. You can also access a collection of demos and examples that show you how to do all sorts of things with Corona. Interestingly, I had never noticed the Demos section before writing this very paragraph! Just goes to show that even when you’ve been using Corona a while you’ll still find new, interesting things that it can do that you didn’t know before, even aside from the new features that show up frequently.

Last, assuming you’ve ponied up the subscription cost, you can also access your online dashboard. Here you can get all sorts of useful information about Corona and the applications you’ve published. This uses the analytics capabilities in Corona to tell you things like how many people are playing a game you’ve published. You can also get information about programs from third parties that have partnered with Corona Labs to provide you with additional services for things like promoting your game.

Another feature that definitely needs to be mentioned is Corona’s build system. In short, when you build an application for distribution, whether that’s to an app store or to your own device for testing, that happens in the cloud, meaning on Corona Labs’ own servers. For example, for Android builds you do not need to have the Android SDK installed at all! You initiate a build from the simulator and it packages up your application code and assets, ships it all off the Corona Labs’ servers, and in a few seconds (normally) you get back a packaged application (an .apk file in the case of Android) that you can load up on a real device immediately. For iOS builds, the story is only marginally more complex; you do need Apple’s SDK installed in that case, and you must do the build on a Mac, because Windows machines cannot do iOS builds at this time. There’s also a little bit more involved when you’re doing a build for real distribution, as opposed to development, but that’s a story for chapter 11. For now it’s enough to know that Corona Labs has taken most of the pain out of device-specific application building, and that’s a Wonderful Thing™.

Although not directly supplied by Corona Labs, there are a number of add-ons available that extend Corona in exciting ways. Three of the most popular come from the same company, X-Pressive. They are Particle Candy, Widget Candy, and Text Candy. Particle Candy adds amazing particle effects such as smoke, explosions, electrical sparks, and fire. These are real-time rendered effects with all sorts of manipulations possible. Using Particle Candy can give your game that extra professional look. Text Candy provides a host of text rendering options including animations. Ever see a game title screen with the name of the game bouncing around, spinning, growing, and shrinking, that sort of thing? Well, Text Candy lets you do that sort of thing with ease! Last, Widget Candy provides a collection of graphical user interface (GUI) widgets to use in your apps such as buttons, sliders, progress bars, and grids.

Aside from these sorts of add-on libraries there are all sorts of tools, some free and some not, to make developing with Corona easier. From tools to create physics bodies from your graphical assets to tools for creating tile-based levels and tools for creating sprites from Flash assets, there’s always something available for virtually any need you may have that isn’t covered by Corona itself.

So now that you have at least a baseline concept of what Corona is and what it can do, how about you jump right in and put together a simple application, just to get your feet wet a little bit?

Baby-Steppin’ It

From here on out, I will assume that you have done the following:

• Downloaded and installed Corona on your chosen development platform
• Run it to confirm it works and have registered your copy (you’ll need to do that the first time you run it)
• Acquired at least some programming experience

While you do not need to be an expert programmer by any stretch to read this book, and I will be making an effort to assume as little preexisting knowledge as possible as I go on, you really do need to have a grasp of the basics of programming before going much further. You may be able to work your way through it by spending a lot of time with Google to get up to speed on the fly, but I’m making the assumption that you don’t need to do this and are good to go with the basics.

I’ll also assume you have a text editor to use throughout the book. You don’t need a proper IDE to do Corona work, a plain old text editor of your choice will suffice just fine, although at least finding one that specifically has Lua support, such as Notepad++ on Windows, is a better option, so you at least have basic syntax highlighting. That is in fact another benefit of Corona: there’s a very low barrier to entry. A text editor and the SDK is all it takes, initially at least; while you don’t need a proper IDE, it’s certainly not a bad thing!

To get started, simply create a directory somewhere convenient on your local file system. Just so you’re on the same page, call it corona_book. Under it, create a ch_01 directory. Then, open your text editor and in that file, paste or type the following content:

display.newRect(
  0, 0, display.contentWidth, display.contentHeight
):setFillColor(
  graphics.newGradient( { 255, 0, 0 }, { 0, 0, 0 } )
);

circle = display.newCircle(
  display.contentWidth / 2, display.contentHeight / 2, 32
);

function moveCircle()
  transition.to(circle, {
    x = math.random(32, display.contentWidth - 32),
    y = math.random(32, display.contentHeight - 32),
    onComplete = function()
      moveCircle();
    end
  });
end

moveCircle();

Save the file in the directory you created and then launch the Corona simulator. On the File menu select Open Project, navigate to the corona_book/ch_01 directory, and select that main.lua file. Your application should start up and you should see in the simulator what is shown in Figure 1-6.

Yes, I agree, it isn’t much to look at, but think about it: that’s a complete, working Corona app, in just a few short lines (four, technically) of code! You didn’t need any fancy tools to create it and, I suspect, the code was pretty self-explanatory on top of it all, even without your having seen Corona code before (presumably not in any great depth anyway).

What’s going on in the code? Well, I’ll briefly walk you through it. Naturally, there are many things that you will not know at this point, so rather than repeating, “you’ll get to this later” a bunch of times, I’ll just say it once here at the start: you’ll get to all the details later, and much more! Nevertheless, for now, just a quick, basic rundown will give you a nice flavor for Corona code.

The first line of code you see does two things.

display.newRect(
  0, 0, display.contentWidth, display.contentHeight
):setFillColor(
  graphics.newGradient( { 255, 0, 0 }, { 0, 0, 0 } )
);

First, it creates a rectangle. This rectangle covers the entire screen. This is simple to achieve by defining the upper left-hand corner at x/y coordinates (0,0) and by defining the width and height of the rectangle as equal to the width and height of the screen, respectively—two values that Corona supplies to us as properties of the display object, which you’ll be seeing a lot of throughout this book. This also means that no matter what device you run it on, it’ll always cover the entire screen (go ahead, change the view in the simulator to another device—say, iPad—and notice that it still works exactly as you’d expect it to).

Now, this line of code does something else: it fills that rectangle with a gradient that goes from pure red (RGB 255, 0, 0) to black (RGB 0, 0, 0). More precisely, it is creating a gradient object via the call to graphics.newGradient(), which Corona knows how to use to fill another object. By passing this object to the setFillColor() method of the rectangle object created by display.newRect(), you get what you see on the screen in the simulator.

At the risk of jumping ahead a bit I’ll tell you that the display.newRect() method isn’t actually returning any sort of special “rectangle” object but is in fact returning something called a DisplayObject. Virtually everything you do on the screen with Corona is a DisplayObject. A DisplayObject has a known set of methods and properties that you can manipulate. What this means is that almost anything you can put on the screen in a Corona app you can fill with a gradient like this, or manipulate in a host of other ways. It’s a very consistent and flexible API that provides you with a lot of power!

But, back to the program at hand . . . here is the next line of code.

circle = display.newCircle(
  display.contentWidth / 2, display.contentHeight / 2, 32
);

You can now probably figure out for yourself: it creates a circle, which again is a DisplayObject.  This circle is centered on the screen by taking the width and height of the screen, dividing each in half, and passing them as the first two arguments. The last argument is the radius of the circle. Note in this instance the reference to this circle is stored in the rather uncreatively named variable circle. In the case of the rectangle earlier, there was no need to do this because the program does not manipulate the rectangle after it’s created, but the circle is a different story so you need a reference to it.

Next, you get to the real meat of the program with line 3.

function moveCircle()
  transition.to(circle, {
    x = math.random(32, display.contentWidth - 32),
    y = math.random(32, display.contentHeight - 32),
    onComplete = function()
      moveCircle();
    end
  });
end

This may look somewhat complex if you have never seen syntax like this before, but it’s actually quite straightforward. A function named moveCircle() is defined. Within it you can make use of Corona’s transition library by calling the transition.to() method. This is an exceedingly powerful method that lets you tween almost any property of a DisplayObject. In this case, you are tweening a property of our circle object, so you pass that as the first argument. The second argument is an object that defines the tween parameters. In this case, you are manipulating the x and y coordinates of the circle (which are properties of a DisplayObject). It’s a simple random number somewhere on the screen, subtracting the radius of the circle so it never winds up partially or entirely off an edge of the screen.

The other property of this object that defines the tween is onComplete. This is a reference to a function to execute when the tween is finished. Here, I’ve defined that function inline. This is entirely a style choice, however; you can (and I’d say in many cases should) define this outside the call to transition.to(). But, since I specifically wanted to show you how much you can accomplish in as few lines of code as possible, I did it this way. (I’ll acknowledge that some of these lines of code are longer than how you might typically write them, but still, it’s technically true!)

The function that executes onComplete just calls our moveCircle() function again, so that every time the circle reaches its randomly chosen destination it moves somewhere else. The result is not a perfect bouncing ball, but is more of a circle that drank too much coffee and is going a little bananas!

The final line of code is a simple call to moveCircle(), which kicks the whole thing off. Without that, all we’d see on the screen is the gradient-filled rectangle with a white circle in the middle, but there would be no motion.

One thing that you may have noticed is that there is no special entry point to the program, no special functions you have to implement. Simply stated, Corona starts executing the Lua script file you name at the top, and you can begin drawing immediately! There is no special setup to do, either; you’re good to go right from the start. Notice too that the circle is on top of the rectangle. This isn’t by accident: the z-index of elements is determined (initially at least) by the order in which they are drawn. Reverse the first two lines of code and you won’t see the circle because it will be obscured by the rectangle. It sometimes takes planning to make sure things are layered properly on the screen, but those are details we’ll get to a bit later.

As I hope you will agree, Corona is very powerful, allowing you to do a lot with a little bit of code. There’s plenty more to come in this department, but hopefully this little program has whetted your appetite.