Aroma - The Native Client game engine powered by Lua

by newtonapple • 14 years ago

45 34 14 years ago

moonboots• 14 years ago

While I'm concerned that Chrome is the only browser supporting native client (Mozilla outright rejected it), it's still awesome to see lua in the browser.

oblique63• 14 years ago

> Chrome is the only browser supporting native client (Mozilla outright rejected it)

Do you have any sources explaining Mozilla's decision on this? I'm curious as to why they would reject it...

Jimmie4• 14 years ago

Publicly they have stated that it's because they think JS is fast enough.

I think that they have some private issues regarding a plugin controlled solely by their browser competitor who wants NaCl apps to be purchased through the Chrome Webstore.

Arelius• 14 years ago

It seems that Brendon has commented on this: http://news.ycombinator.com/item?id=2983157

tldr: Nacl cannot be standardized, and the relevant API's are too strongly tied to chrome/webkit details to provide a first-class port to Mozilla.

afsina2• 14 years ago

It is Mozilla's failure. Nacl may potentially be the best and widest deployment environment for native code and games ever.

zobzu• 14 years ago

It doesn't matter, if Firefox supported NaCl none of these games would work in Firefox. They're all Chrome-store only.

Besides IE, Opera, etc all rejected it as well.

tete• 14 years ago

Because what we need is another Active X?

The fact that this time it is from Google doesn't make it better.

We slowly rid ourselves from stuff like Flash and Java on web pages and now we want to make the same mistakes again?

I know, it isn't bad in first place (Flash, Java, Active X weren't either), but I'm pretty sure we'll see better approaches.

SomeCallMeTim4• 14 years ago

Moai supports Chrome...and iOS and Android and Windows and Mac:

http://getmoai.com/

It's cool to see Lua in the browser, yes, but it's been there for a while already.

I also am skeptical about LÖVE (what Aroma's based on) being ready for commercial games. I've asked LÖVE supporters what commercial games were built on that platform, and they came up completely empty. Bringing a game to release quality tends to find all of the corners of a library that are not production-ready.

Moai has a number of serious users, though, including Double Fine.

kevingadd2• 14 years ago

I don't think it makes sense to attribute any special amount of quality to Moai; IIRC only one commercial-quality game (Crimson Steam Pirates) has been released in it. DFA will count once it's out, I guess, but that's a ways away.

Having used Moai myself I wouldn't really call it commercial quality. The documentation is poor, the code is cryptic, and it tends to crash or do strange things instead of report errors. It also fails to abstract out hardware limitations or notify you of them (for example, it'll let you use 4Kx4K textures and then when you run on a machine with a 2Kx2K limit, Moai just falls over instead of providing clear error feedback or scaling-down the texture.)

pygy_2• 14 years ago

> only one commercial-quality game (Crimson Steam Pirates) has been released in it. DFA will count once it's out, I guess, but that's a ways away.

Add Wolf Toss, and the WIP Shadowrun Returns. Both DFA [Doublefine Adventure] and Shadowrun should be done by the end of the year.

Regarding the bugs, I'm sure tat they'd be happy to discuss them, but it's night time in Seattle now. You can drop a line at their forums (http://getmoai.com/forums) or the Github bug tracker (https://github.com/moai/moai-dev/issues).

For the documentation, it is constantly improving. The API docs still have weak points, but the high level overview and the (now partly annotated) examples go a long way. You may want to check these pages:

Overview of the runtime: http://getmoai.com/wiki/index.php?title=The_Moai_Runtime

More details: http://getmoai.com/wiki/index.php?title=Moai_SDK_Basics_Part... http://getmoai.com/wiki/index.php?title=Moai_SDK_Basics_Part...

Annotations of the examples: http://getmoai.com/wiki/index.php?title=Moai_SDK_Samples_Gui...

TOC: http://getmoai.com/wiki/index.php?title=MoaiSDK

seclorum2• 14 years ago

I'm using MOAI professionally, and none of your points are of any concern so far .. we've definitely been very productive with MOAI, and sure - the documentation needs work, but for a 1.0 release, MOAI packs an immensely powerful punch. If you're a pro mobile developer, you can't afford to not investigate MOAI - its an extremely powerful tool that is going to be used for more and more releases .. (and yes it already has NaCL support - as well as Windows, Mac OSX, iOS, Android .. and LINUX host support too..)

SomeCallMeTim4• 14 years ago

I haven't used Moai myself; that's good information. Thanks.

By the time Moai was released, I had already created my own Moai-equivalent C/C++/Lua framework. I've written a game on it already, and one other developer (a company I used to work with who asked for access) is using it, but I haven't released it to the public.

When I discovered Moai I was a bit skeptical about it; they've written all their Lua bindings by hand, which isn't terrible, but they're bound to Lua 5.0...meaning that you can't drop in LuaJIT and have scripts run 3x-100x faster. Since I had my own library already, I decided not to switch.

And their model seems to be (like löve) that you have a monolithic build that just runs Lua code, whereas I prefer keeping the C++ build process around so I can drop into C or C++ easily, adding or removing modules as I need them. For instance it appears they have TWO 2d physics engines as part of the build, along with lots of other libraries that I may or may not need, resulting in 6+ megabytes of binary, while mine comes in comfortably under 2Mb.

Auto-generating Lua bindings makes this easier as well -- if I need to add another library, I just drop it in and run my binding generation script; other than adding any new source files to the various projects, that's it.

But strictly considering löve vs. Moai, I still have to advise people to lean toward Moai.

Jimmie4• 14 years ago

Although it's freeware, mari0 was made with LÖVE and it is pretty solid. http://stabyourself.net/mari0/

It made HN a while ago, link to discussion: https://news.ycombinator.com/item?id=3665859

SomeCallMeTim4• 14 years ago

Looks nice.

The problem is, while a high-quality freeware game like mari0 does mean that LÖVE does meet the minimum feature set you'd need for a game, it doesn't mean it has the tools or widgets or features you'd need in a commercial game.

For example, does the game render and perform well on all target platforms? For a freeware game, if it doesn't work on some video card, so what. For a commercial game, it means support headaches, lost revenues, and bad reviews and/or user comments.

For more examples, see this thread:

http://www.reddit.com/r/love2d/comments/q0oc1/where_has_love...

seclorum2• 14 years ago

MOAI also (now) supports Linux. So, you have exactly one set of code to run on MacOSX, Windows, Linux, Android and iOS.

ernesth• 14 years ago

Why do all löve articles get spammed about moai here?

Apart from lua, they have nothing in common, different target, different goal. Both can be successful in their own niche.

I use löve for teaching, there is no way I would have considered moai for a first application of my algorithmic course! And frankly, I do not care about "serious users".

SomeCallMeTim4• 14 years ago

The hook was that it was a "Native Game Client Powered by Lua".

If you don't care about serious users, then you're free to choose appropriately. A lot of people do use löve; they must all have their reasons. I don't see how Moai is not relevant to this discussion, though.

People clicking on the comments may be considering writing a serious game; if not, they can play with löve and have fun, but if they are, I wanted to warn them about what I'd found.

tferris• 14 years ago

Why is Lua so popular among game devs?

Jimmie4• 14 years ago

It's fast, dynamic and easy to embed in a C/C++ game for scripting.

The language itself is very simple to learn too.

kevingadd2• 14 years ago

It has most of the positive traits of JavaScript with less of the negative traits.

A few examples:

Strings in Lua are interned, which makes it possible to efficiently use string keys in all sorts of places instead of numeric enumerations.

Lua's garbage collector has support for running incrementally with a configurable pause time, so you can run it in the background every frame to avoid those nasty GC pauses you still get in most modern browser games from stop-the-world collections.

Debugging is built into the language with a user-accessible API that lets you write your own debugger or diagnostic tool, in addition to using third-party ones, instead of having to rely on the vendor to provide one.

Lua uses a single container type for storing data, with an efficient representation (densely packed elements are stored in an actual array; sparsely packed elements and elements with non-integral keys are stored in a hashmap). As a result, operations on sequences/containers only ever have to think about one data type, and you still get the near-optimal performance you would in JS if you manually used Array/Object where most appropriate.

lucian1900• 14 years ago

Actually, JS Arrays are implemented as hashmaps as well.

simonster4• 14 years ago

> Strings in Lua are interned, which makes it possible to efficiently use string keys in all sorts of places instead of numeric enumerations.

Interning is an implementation detail. I don't know how they are implemented off the top of my head, but string keys are pretty damn fast in most JS JITs, since they're used to get e.g. methods of objects.

> Lua's garbage collector has support for running incrementally with a configurable pause time, so you can run it in the background every frame to avoid those nasty GC pauses you still get in most modern browser games from stop-the-world collections.

Again, this is an implementation detail. Firefox is about to get incremental GC. While the pause time isn't configurable, it doesn't really matter as long as it's short by default.

> Debugging is built into the language with a user-accessible API that lets you write your own debugger or diagnostic tool, in addition to using third-party ones, instead of having to rely on the vendor to provide one.

Gecko and WebKit both have debugging APIs. I will concede that it's a PITA that they're different.

> Lua uses a single container type for storing data, with an efficient representation (densely packed elements are stored in an actual array; sparsely packed elements and elements with non-integral keys are stored in a hashmap). As a result, operations on sequences/containers only ever have to think about one data type, and you still get the near-optimal performance you would in JS if you manually used Array/Object where most appropriate.

Again, this is an implementation detail. In JS, Array is a subclass of Object and in most JITs I think it's implemented the same way. The only difference is how they serialize to JSON and that Array has a length property. Lua has an advantage in that it gives arrays both sparse and dense slots, but this isn't necessarily impossible to do in JS either (https://bugzilla.mozilla.org/show_bug.cgi?id=586842)

zura• 14 years ago

Agree, Lua has its pearls, but I think, today it is used in larger scale projects than it was initially intended. Language-wise, I prefer UnrealScript or similar, with a "classic" OO and preferably with a static typing.

hermanhermitage2• 14 years ago

Very easy to embed and small footprint.

Language evolution has been implementation driven more so than say Javascript. As such its been able to reshape itself continually.

Mike's LuaJit is an incredible piece of work.

Its easily extended.

Aroma - The Native Client game engine powered by Lua

Related Stories