Re: Lua for mobile development

[Pierre-Yves Gérardy <pygy79@...>]

I've recently joined Zipline (initially to improve the documentation).
There are a few errors in your comparison:

On Fri, Jun 22, 2012 at 1:46 AM, Tim Mensch <tim-lua-l@bitgems.com> wrote:
> * QC is based on Lua 5.1, so you can drop in LuaJIT (which is now supported
> on Android/iOS). (Moai is on 5.0.x, AFAIK).

Moai is also based on Lua 5.1.

> * QC uses a robust binding generator (Dub), so you can add your own C/C++
> objects trivially. For many objects, adding the name of the header file to a
> list, rebuilding bindings, and adding the new generated source file(s) to each
> project is all you need to do. (Moai has hand-made bindings for everything,
> so you'd be on your own to create new bindings.)

Correct, but writing bindings is fairly straightforward. We provide
macros to ease things out, and a dummy module as a model:
https://github.com/moai/moai-dev/blob/master/src/moaicore/MOAIFoo.h
https://github.com/moai/moai-dev/blob/master/src/moaicore/MOAIFoo.c

> * QC is designed to be modular. Moai has two (!!) 2d physics engines and
> lots of other code that not every game would need, but it seems to be set up
> to be monolithic. I'm sure you can take Moai apart -- it's open-source,
> after all -- but I tried to focus on making it easy to add and remove and
> rebuild modules. As a result the binary can be less than 2Mb compared to
> Moai's 6Mb+ (IIRC).

Moai is also designed with modularity in mind. The default binary is
intended for development, and includes everything for convenience. You
can easily disable modules for production if you want to.

> * QC currently has "light" Windows support (works well enough for
> development), and similar Mac/Linux support would be easy to add, but the
> primary targets are Android and iOS. In addition to Android/iOS, Moai
> supports Chrome, and fully supports Windows/Mac/Linux targets (AFAIK).

Yup :-).

> * QC is designed to be easily extended using native code on iOS or Android
> (or Windows). I use this to send Flurry events (analytics), bring up ads,
> etc., where the code to do each would differ on each platform. The *Lua*
> code is designed to be completely cross-platform, and once you've created a
> harness for an ad provider on each target, it would work in all future apps.
> Changing out the ad provider wouldn't require you to change your Lua code,
> either (as long as they were providing the same banner, for instance).

We use a similar approach:

https://github.com/moai/moai-dev/tree/master/src/moaiext-iphone
https://github.com/moai/moai-dev/tree/master/src/moaiext-android
https://github.com/moai/moai-dev/tree/master/ant/host-source/source/project/src/moai

The API is identical for both platforms

> * Moai has integration with custom cloud services and ZeroMQ, which is cool,
> but I am concerned about lock-in and what happens if the scaling doesn't
> work as well as they claim it will -- AND what happens if their business
> model fails and the servers all disappear? At the moment I'm not doing
> anything that's a complete replacement for this feature, though I do have
> easy networking-over-http set up, which works fine for the asynchronous game
> I'm currently writing.

Even though the Cloud and the SDK are marketed together, they can be
used independently.
* The Cloud services expose a RESTful API, accessible over HTTP from any client.
* The SDK is free to use and modify, provided that you give credit via
a splash screen or a note in the credits.

Remember that Zipline uses Moai for its own game titles, as well as
sharing the Moai tech with other devs. One of the reasons Patrick
released Moai SDK as open source in 2010 was because that's the best
way to build a product in this space, and most of the commercial
studios using Moai use it for exactly that reason. Trying to make
money from selling a similar SDK would be very tough as you pointed
out.

> * QC is designed so that C++ is a first-class language. When you create a
> game object in Lua, you can pass it to C++, hold it there for a while, and
> later pass it back to Lua, and the resulting object that Lua gets will:
>
>   a) Be identical to any reference that Lua has been holding, IF any such
> reference still exists. (Preventing an extra object from being
> created/tracked/garbage collected).
>
>   b) Still retain any custom parameters added on the Lua side, *even if the
> original Lua object was garbage collected.*

How is this different from using the Lua registry?

> What I haven't been able to figure out is what business model I should
> use. Moai's business model is based on selling their cloud services,
> but *as a client* I don't like that because of the lock-in.

There is no lock in... no more excuses not to use it ;-).

-- Pierre-Yves