As I mentioned in my earlier posts, I have spent some time trying out Ansca Mobile’s Corona SDK and I think it is great. It allows a developer to rapdily put together very impressive stuff. Plus there are third party libraries and tools that are cheap and make things even easier. In particular I like Sprite Helper and Level Helper from Bogdan Vladu and Text Candy by X-Pressive.

That said, if you choose to work with Corona there are some limitations you must accept. There is no mechanism for adding C libraries; everything must be done in Lua. Access to the system is completely controlled by the SDK; there is no way to do your own rendering or to access other operating system APIs for sound, etc. This is by design; Corona is a multiplatform SDK and abstracting the APIs provided by various operating systems to a common Lua API makes sense.

Still, I find this a bit constraining as I would like to be able to replace some of the rendering with my own. When experimenting with Corona I started building a game that incorporated line drawing elements and found the line drawing to be a bit slow. I would like to have been able to redo this myself and still use the sprite API for rendering sprites. Also, it would be good to be able to render some special effects and backgrounds myself instead of relying on Corona.

Another limitation of the Corona SDK and one I have a bit more trouble with is that Ansca Mobile requires project builds for release to be done on their servers. Initiating a build generates an archive for you on their servers that you can upload to iTunes Connect or whatever the Andoid, etc., equivalent is. This keeps things simple, but for me leaves a lot to be desired. No tweaking compiler optimization, etc.

So what is a part-time indie devloper with no budget and no free time to do? Roll my own, of course!

In part I of this post, we created a simple iOS game in which to embed Lua scripting. In part II we embedded the Lua interpreter and demonstrated calling Lua scripts from our game. We also added some simple interaction by enabling our Lua scripts to access the state of our player ship (x,y position).

In this final part, we are going to build on this functionality to expose the entire ship control to Lua so that our scripts can control our NPC ships.

In part I of this three part post, I introduced a simple game framework to which we are going to add Lua scripting. Now we are going to get right to it and cover all the steps necesary to get Lua scripting working. This will include embedding the Lua interpreter in the Xcode project, running Lua scripts from Objective C code, and accessing game state (ship position) in Lua scripts via a C function we will write and bind to Lua.

A while back @celsiusgs published a blog entry discussing using C++ polymorphism for pluggable AI in his upcoming game Drifter. In a nutshell, each ship in the game is controlled by a ShipObject that has the ship’s state as well as methods (“inputs”) to control the ship (throttle, steering, etc.). This class provies a process method that updates ship state (presumably based on some sort of physical model and the current state and inputs). For player controlled ships, the ShipObject inputs are driven by touch controls. For instance, when the player touches the throttle control the throttleControl method(s) would be called (presumably).

This separation of the physical controls that respond to user touches from the ship controller makes it easy to plug in AI code to control NPC ships. For NPC ships, the ShipController object is assigned an AI object that accesses the ShipController to control the ship’s state. This AI object implements a process method that is called from the ShipObject’s update method once per game loop.

To make this as flexible as possible, @celsiusgs has created a generic AI class that provides a virtual process method that is implemented by classes inheriting from this base class. This allows him to simply attache different AI implementations to each NPC ship to get different behaviour.

The decoupled nature of this approach provides another benefit that @celsiusgs mentions: it provides an easy entry point for replacing C++ code with a scripting system.

I won’t get into a discussion here of the pros and cons of using an embedded scripting system. I like to think that there are more reasons supporting using one than reasons against it. For this appliction, however, there is one huge benefit that definitely makes it worth doing.

Implementing even simple AI is nontrivial and often involves a lot of iterations as you try to weed out “dumb” behavior. An NPC ship repeatedly bumping it’s “head” into an asteroid tends to spoil a games immersiveness. Executing test runs over and over again is particular painful on the iOS platform if the code under test needs to be compiled every run.

If the code is run from a script, however, these scripts can be read from a webserver every time they are executed, so the main program does not need to be rebuilt every run. In fact, if the code is written to support it, it may not even need to be restarted, but merely reset. This allows the AI coder to make changes to his/her scripts and rapidly test the effects.

By far the most popular embedded scripting language for game development is Lua. I won’t describe Lua in much detail here, instead I’ll refer the reader to the main Lua site. Suffice it to say, it has three properties that make it a good choice for embedding scripting in a game:

• It was designed as an embedded language from the ground up
• It is based on standard C/C++ code and is therefore runs on many platforms
• It is lightweight and very fast

In this three part blog entry I am going to demonstrate how to embed Lua into an iOS app, with particular emphasis on a system like the one in Drifter, albeit using much simpler game mechanics. If you want to follow along in Xcode the project can be cloned from github at git@github.com:indiejames/TestLua.git.

I have been looking closely at the Corona SDK and so far I like most of what I see. It is very easy to put together simple 2D games using sprites and even game physics. Scripting in lua is an interesting alternative to Objective C and has the potential to allow for much more rapid game development.

There are, of course, some drawbacks. First among those is that Corona is strictly 2D (for now, at least). For most mobile games this is not a drawback, but it does limit the kinds of things you can do. Another drawback, for me, is that you currently cannot work with OpenGL ES 2.0 shaders. This makes it difficult to do some cool effects, but shaders are on the roadmap for Corona so hopefully they will be available soon.

This is actually a special case of a larger tradeoff with Corona. Since Corona provides wrappers to basic APIs like OpenGL, OpenAL, etc., you are limited to the level of detail that Corona’s developers provide when accessing those APIs. If the Corona developers have chosen not to expose certain elements of an API to you (usually for sake of simplicity) then you are not able to access them.

Similarly, certain lua functions have been purposely left out of Corona due to limitations (usually security related) of mobile devices. In particular, methods like loadfile() and loadstring() that dynamically load and execute code are not implemented. This has big implications for the way certain things can be done.

I have been looking at Unity3D and some 2D add-ons that ostensibly make it easy to create 2D games. Every so often I take a look at Unity3D because it has a lot to offer - cross platform app generation, easy asset management, built in physics, the list goes on. Plus there is the whole asset market they have set up that looks just like the iOS App Store. You can buy 3D figures and animations and import them incredibly easily. If I were looking to make a 3D game I would give serious thought to using Unity3D.

There are, however, some things about Unity3D I’m not crazy about, although some of these things are probably failings of mine more than Unity’s. First and foremost, I can’t seem to find a tutorial that talks about high level workflow in Unity3D. Most of them seem to talk about the UI or specific functionality in a detailed way. The “this is how you do this in Unity3D tutorials”. I need one that says “this is the workflow (or one possible workflow) that you use to go from an empty project to a finished game”. Perhaps they exist and I just can’t find them.

There are books, of course. Several of them. I’ve taken a look inside via Amazon at one or two, but I haven’t found what I’m looking for yet. Besides, if I need an entire book to give me a high level overview of the Unity workflow, maybe it’s not for me.

The other limitation of Unity, if you can call it that, is that Unity 3D is made for, wait for it, making 3D games. There are what look like some good 2D plugins for it that take advantage of the 3D for things like parallax scrolling, but it seems a little kludgy to me. Since I haven’t actually used them I probably shouldn’t judge them, so take that for what it’s worth.

Finally, Unity 3D is expensive for a bitter, unrecognized genius like me. When your games sell in the hundreds, not hundreds of thousands, shelling out > $1K to develop an iOS game isn’t going to happen. For big time developers it’s probably a great investment, but it’s too steep for me right now.

So what to do if one isn’t (yet) interested in developing 3D games? There is the very good Cocos2D, but I decided against that a long time ago because it didn’t really buy me much that I hadn’t already created (sprites,texture atlases, fonts, etc.). Plus it didn’t use OpenGL ES 2.0, so no shaders (this is changing).

The main thing I have been looking for is the ability to script levels. I have recently developed an interest in using Lua for scripting my games. At first I considered rolling my own Lua bindings, but this looks like a lot of work and I am generally a very lazy person. So I am now taking a look at Corona and it looks very promising. It is strictly 2D and more of an SDK than an engine/application like Unity 3D. It’s also much cheaper (free until you want to deploy to the app store, then it’s < $400). Like Cocos2D it doesn’t support OpenGL shaders, but this is on their roadmap. Hopefully it gets added soon.

There are some third party tools that work with Corona for creating sprite maps (including defining collision boundaries) and even laying out levels. I will be taking a look at these in the coming weeks. In the mean time, I will be experimenting with Corona to see if it will work for me. If nothing else, it looks like a good platform with which to learn Lua.

So there you have it. If you were looking for a blow by blow comparison of Unity3D and Corona, sorry to disappoint you. Maybe when I have more time.

This is my first post for the new blog. I’m in the midst of moving everything from www.indiejames.com to here. Anyway, it’s been a long day and I’m tired, but i wanted to mention the new game (operating title ‘Celestial’) that I’m starting.

It combines elements of tower defense (more along the lines of Plants vs Zombies) with some other genres and, hopefully, some originality. I’m just in the design phase so it will be some time before that one sees the light of day, but I have been experimenting with some of the technology behind it, like procedurally generated planets (you heard me, planets!!!). Here is a very, very early sample image:

Notice the specular lighting. Mmmm hmmm. That’s what I’m talking about! OK, OK, but it’s wayyyyy early.

I’m also looking at incorporating Lua into this game for level scripting. Strange that just minutes after buying Programming in Lua I see a tweet from @louielouie saying he’s listening to a talk on Lua scripting for apps at MoDev East. Makes me wish I had gone to MoDev East. Or even heard about MoDev East.

By the way, this is my first time using Octopress for blogging, and so far I really like it. It feels very “developerish” and has tons of cool plugins. Things like pull quotes make me feel important. I really like writing posts in markdown and deploying it here using rake tasks and git. Reminds me of my grad school days using LaTeX and makefiles.

I heard from @kshepherd of Imangi that he is looking into using Unity3D for his next 2D game. His interest is in the cross-platform capabilities. I guess being wildly successful on iOS just isn’t enough for some people :).

I had looked at Unity a while back but was put off by the learning curve. Admittedly I didn’t look very closely, so it may not be that bad. Maybe I should take another look at it (Keith is a bright guy).

That’s it for now. I’m going to try to make some headway on Celestial which I’ll be talking about much more in the coming days.