Re: Lua for mobile development

[Paul K <paulclinger@...>]

Hi Tim,

> I have spent the past two years building my own 2d games library. It’s
> structured somewhat similarly to Moai, but with an emphasis on a light
> binary footprint and easy extensibility.

This sounds very interesting. I have also been developing a
cross-platform Lua-based solution to control robots from mobile
devices and have settled on using mosync (http://mosync.com) and their
MobileLua framework (https://github.com/divineprog/mobilelua). I like
their approach because it's C++-based, but runs natively on all
platforms they support (iOS, Android, WindowsPhone and more), and also
includes JavaScript and Lua layers that get access to mobile APIs
exposed by the core framework. The Lua part still needs some
polishing, but I got it working with my debugger
(https://github.com/pkulchenko/MobDebug) and the IDE
(https://github.com/pkulchenko/ZeroBraneStudio), which allows you to
run and debug remotely simple Lua applications running on various
devices (I tested on iPod, iPhone and couple of Android phones).

I'd be interested to see if your library can be integrated with
mosync, especially if you can also make it run on Windows, as this
would allow my users to develop and test locally and then run their
games on actual devices (or in the simulator that mosync provides).
This should work well for the educational market that I target with
the IDE we've been developing.

Do you have demos/documentation for your library? Is it similar to Playground?

In terms of the business model you can look at how Mosync operates:
they opensource all their software, but sell commercial licenses
(http://www.mosync.com/mosync-dual-licence-model) for those who want
to sell games based on their framework (mostly support-based). The
model makes sense based on what I know and also allows those who
develop for fun or release as open source to use it for free.

(I'm not affiliated with the company in any way, just like what they
are doing, use their products, and have been contributing to
MobileLua.)

Paul.

On Thu, Jun 21, 2012 at 4:46 PM, Tim Mensch <tim-lua-l@bitgems.com> wrote:
> On 6/21/2012 9:40 AM, Jose wrote:
>> 2) Moai (open-source) has been suggested on another thread
>
> I have spent the past two years building my own 2d games library. It’s
> structured somewhat similarly to Moai, but with an emphasis on a light
> binary footprint and easy extensibility. In both libraries, you define a
> bunch of objects in Lua, and they're drawn using OpenGL in C++. This
> approach supports things like particle systems that might otherwise have too
> much overhead if all the drawing and calculations happened in Lua. (Particle
> systems in particular can be specified in Lua with a few parameters and all
> the calculations can be handled at the C/C++ level.)
>
> The last game library I designed [1] ended up with over a hundred commercial
> games developed on it. Some of those developers have been asking me to share
> my current library, and so far I've shared it with a couple. One other
> developer has even completed an app based on it. I’m still working on what
> my business model should be; read below the bullet list for more on that.
>
> If I'd seen Moai before I started (impossible, since it wasn't released back
> then...), I would probably have just used it and not bothered reinventing
> the wheel. But, since I *have* reinvented it, let me tell you about it. It's
> called the QuickCharge SDK (QC). Here are some salient differences with
> Moai:
>
> * 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).
>
> * 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.) That includes
> either basic objects or first-class managed objects. It also utilizes some
> nice optimizations with respect to minimizing allocations and preventing the
> need for __gc calls for simple objects like a vector.
>
> * 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).
>
> * 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).
>
> * 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).
>
> * 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.
>
> * 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.*
>
> I don't know where Moai stands on this last point, but please someone
> correct me if I'm wrong about Moai concerning any of the above. I want to
> emphasize that I've NOT used Moai to do anything. There are a ton of
> specific features I'm not going into right now; suffice it to say that there
> are two completed projects and one mostly completed based on QuickCharge.
>
> 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. Corona's model is
> closed-source, and I don't like *that* for obvious reasons (at least with
> Moai you COULD extend it to bind to native libraries like Flurry or ad or
> social services).
>
> Mike Pall seems to make a living with the free-product-paid-consulting
> approach of LuaJIT, but there are *lot* more potential users of LuaJIT than
> there would be for a 2d game engine, and other people have created wildly
> successful free projects and then yet had trouble monetizing them through
> consulting (Zed Shaw's infamous Rails rant complained, in part, of the
> difficulty of being paid fairly for consulting work on his free software).
>
> One thought was to put up a KickStarter to pay to "productize" the library
> (make installers, add some new awesome features that have been floating
> around in my head, and generally make it easy to pick up and use) and to
> then go with the free+consulting model afterward. But I don't know that the
> interest would really be sufficient to fund a KickStarter.
>
> So...the short summary is that I have another library in this space, but
> haven't figured out what to do with it. I don't have enough free time and
> extra money to be comfortable just giving it away with no plan, especially
> since it would take some work before it's really ready for prime time, and
> at present it would require too much time answering questions to just
> release it as-is.
>
> Thoughts?
>
> Tim
>
> [1] https://developer.playfirst.com/ -- That library, Playground, is pretty
> much dead at this point since it's partly closed source and they're no
> longer supporting it, and they never released the iOS version so it's mostly
> moot to this discussion, but that's where it lived.