

Aroma - The Native Client game engine powered by Lua - newtonapple
http://leafo.net/aroma/

======
SomeCallMeTim
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.

~~~
kevingadd
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_
_> 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_One)
[http://getmoai.com/wiki/index.php?title=Moai_SDK_Basics_Part...](http://getmoai.com/wiki/index.php?title=Moai_SDK_Basics_Part_Two)

Annotations of the examples:
[http://getmoai.com/wiki/index.php?title=Moai_SDK_Samples_Gui...](http://getmoai.com/wiki/index.php?title=Moai_SDK_Samples_Guide)

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

------
moonboots
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.

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

~~~
tete
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.

~~~
afsina
I do not recall ActiveX running in MacOsX or Linux. I do not understand when
People are completely ok when a game is Windows only but when it is in Chrome
suddenly preaches multi-browser compatibility. To me, NACL is not a mistake,
it is future. Oh also it is damn open source.

~~~
hermanhermitage
I'm in two minds, I want a near native code execution environment in the
browser but wonder if something like Xax offers better room for performance of
dynamic generated code.

------
tferris
Why is Lua so popular among game devs?

~~~
kevingadd
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.

~~~
simonster
> 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>)

~~~
Derbasti
Lua tables are not an implementation detail. They are the one and only complex
data type in Lua and everything (including OO) is built on top of them.

~~~
simonster
Objects are the only complex data type in JavaScript (sans E4X). Arrays are
objects (typeof (new Array()) === "object"), and prototypical inheritance is
built on top of objects.

