 |
lua-l archive |
|
|
||
|
|
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. |