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.