| Comments

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!

Joking aside, after working with the Corona APIs and after my previous post I began to wonder what it would take to reproduce some of the functionality provided by the Corona APIs. Sometimes naivety is a great thing – it let’s you tackle challenging things without worrying about details like “how realistic is this idea?” O.K., maybe not all joking aside.

I don’t have a current project going (although I have lots of ideas – always ideas), so I have decided to spend some time cleaning up some code from earlier projects and to put some of it into libraries for easier reuse. This seems like a good time to try to exose some of those APIs to make them scriptable. And since I’m not facing any deadline pressures (well, not for my stuff), why not go the whole shebang and try to produce a usable scripting framework on which I could base future games? And hopefully I can learn a lot about embedding a scripting language along the way.

So, if anyone is reading this and still interested, I am starting work on an embedded Lua library for iOS. The github project is publicly available to anyone that would like to follow along or better yet contribute. I hope to get something practical out of this that can be used for iOS game development. Still, I am treating this largely as a learning project, so if I am doing anything stupid, feel free to correct me. Just be nice.

These are the core principles I want to maintain in the development of this libary:

  1. This is a library, not a full development environment like Corona.
  2. This libary is iOS specific; I have no plans to port it to any other system.
  3. This libary will provide access to iOS features such as graphics rendering and sound, but an application will still be able to access these things outside of Lua scripts.
  4. This library will implement the Corona SDK API where prudent. In particular, the sprite API will follow the Corona sprite API in an attempt to allow third party libs and tools that work with Corona to work with Gemini.
  5. This library will implement a game loop to simplify game development with hooks to allow user code (Objective C/C++) to be called prior to and following the render phase.
  6. This library will be open source to allow the user to extend it by implementing additonal C libraries that can be called from Lua scripts.

I’m sure I will think of others, but for now this is what I think is important. I have started implementing some easy stuff first. I will try to cover each addition in a blog post in case anyone is interested.