The Moai Runtime - An Object-Oriented Reactive System
getmoai.com
getmoai.com
I don't want to bag lua scripting in games, because I fully support that; supreme commander was a pretty good example of how you can do this right.
...but I can't help but think moai isn't it.
I've seen the code of three groups who are working on games using this engine (primarily because it's cross platform), and their code all makes me shudder. It's rubbish (no offence guys).
lobsterGfx = MOAIGfxQuad2D.new ()
lobsterGfx:setTexture ( "openlobster.png" )
lobsterGfx:setRect ( -128, -128, 128, 128 )
explosionGfx = MOAIGfxQuad2D.new ()
explosionGfx:setTexture ( "fire.png" )
explosionGfx:setRect ( -32, -32, 32, 32 )
All the code I've seen using this engine suffers from the same thing I've seen a dozen or more times in unity projects, but worse: 1) no unit tests, 2) spagetti code, 3) no interfaces or dynamically replaceable behaviour, 4) no documentation, 5) no workflow for artists.
It's a game engine by programmers for programmers to hack with; and I'll give it that; it _is_ fun to hack with, and it's nice to be able to shift the behaviour of things a little bit and see the results immediately... but that alone doesn't make it a good choice for serious projects.
To be fair, they call it a "minimalist game client framework" in the FAQ and a "minimalist cross platform C++ game engine with a Lua-based scripting interface" in the SDK's page in the wiki, so they aren't billing it as a high level API.
Having done 5 projects in MOAI so far, I can tell you this: what you are isolating as a fault is actually a very big strength. If I need it, I can drill down and have absolute control over the Quads. If I don't need it -big deal, I isolate into higher-level abstract API's, and away we go.
I really don't think you're looking at it fairly, or professionally. If you want a higher-level API, choose Corona or something else. If you want serious power, there is nothing out there better than MOAI.
If you're writing good software you should have a nice Model, and a nice clean high performance visualization core that renders that model.
Scripting engines should be an easy and quick way to modify the state of the Model, not something you _write the model in_.
There is everything from speed to memory usage to testing and verifiability wrong with writing your model in your scripting language. Don't deny it; it's absolutely true. The only possible benefit is flexibility, which you take at the cost of all the other things I've mentioned.
Arguably MOAI actually provides you the tools to do this properly with its C++ api, and a real project would implement the state model and rendering code in C++ and build it as part of the moai binary, correctly using the scripting engine to modify only the state of the game model itself.
I can see some use for the low level operations as part of the scripting language for doing _clever things_ in a game, like cut scenes, where one-time-non-state-based operations take place.
...but writing the whole game in it? No.
On the other hand, people seem happy to 'hack away' with it and have fun, and I approve of that. Would seriously hesitate to recommend it for a professional project.
Its such a great game engine that in fact you can even build a real GUI with it, quickly and efficiently, without much fuss.
I wrote a physics game, which consisted of a single Game Logic thread, just doing the level-switching and score-keeping, while the physics engine was being driven by Lua tables. This .. 200 lines of code .. can be fed 3 Lua tables of information, per-Level, and its a functioning game.
Speed? MOAI has great speed. Really, honestly. Memory usage .. umm .. it was designed to make rendering on the GL/ES pipeline extremely memory efficient. Need to choose your strategy for glyph caching, based on the size of your data-set? Guess what, MOAI can offer you hardware-accelerated font rendering with optimal texture strategies. It can offer multiple strategies, according to the limitations of your game - need lots and lots of textures, as soon as possible? MOAI can scale, from thick to thin.
Writing the whole game in it? Well actually, you use MOAI but write the game in Lua, and actually: Yes, its great. The whole game in MOAI is .. much, much less code, than it is in many competing API's, and its hell fun to boot.
>Would seriously hesitate to recommend it for a professional project.
I'm professionally recommending that you take a closer look at it. There is much, much power, and it seems you have missed it.
I suspect you'll discover that as the magnitude of the project approaches anything useful, the complexity and issues I've raised will increasingly become apparent.
Like I said; it's a great toy to hack away with. If you're writing something less than a few k-loc, go for it! :)
I've just told you: the game is done, it works, levels are designed with 3 lua tables, and its a done deal. This is not trivial in any sense other than your hardwired computation that "200 lines must be trivial, thats not nearly enough"... alas, it seems you're missing the point, entirely.
Its not a toy if it consumes less LOC than some alternative and yet gets the same job done.
I could argue printf("hello world") is a trivial piece of code, and you could argue that no, the libc behind it that runs that code, the terminal, the os, is all a massively non-trivial piece of work.
Triviality in this case is measured by not _what the code achieves_ but by _how much human work_ is required to achieve it.
If one person can write say, 200 lines of lua and make a game, that's great. It's also easy. That means that a _real project_ will have 10 people each writing, say, 200 lines _a day_ on that real, non trivial project.
At _that_ point, complexity become an issue. Testing becomes an issue.
If all you have to worry about is one person hacking away over weekend, go for it~ enjoy~
No offense, but taken in the context of your previous statements that's an nice bit of circularity. ;)
But I am curious about seclorum's game ...
I think in the near future as the project matures, it will become far more solid. It already has a big advantage of being open source and cross platform. Other such engines like Corona and Gideros for lua are closed and also have some limitations on how you can extend and use them at the code level.
I tried Moai for a few weeks for prototyping (after already trying Corona and Gideros before). I decided it would just be better to do the actual game in a native code framework on whatever platform (something like libgdx for android or cocos2d for iOS).
* Mac OSX * Linux * Windows * iOS * Android
Please note: MOAI targets BOTH mobile and desktop markets, and in that respect is much more powerful than a lot of competing frameworks.
The app looks the same on each platform, in fact its indistinguishable wherever you run it. Such a powerful framework, and many who look at it seem like they want to be hand-fed their apps, pre-developed for them ..
On the other hand, I consider some of the more established Lua game frameworks to be too limited to use for anything really good (such as Corona or Gideros) and I have some years of development experience in native app and web development.
Moai is probably the best Lua framework for games out there, it's just lagging a bit for documentation still (though it looks like they're updating some as of now, like the cloud stuff, which is nice). There's even a post in the developer's forum (http://getmoai.com/forums/post3503.html#p3503) for it where the maintainers of it admit their API documentation needs some help for version 1.0 as the functionality of some classes changed. Having to actually dig through the C++ source to find undocumented features of a Lua based framework is just where I say I can wait a bit and check back on Moai's progress later. I do regularly check on it out of curiosity every few weeks to see if there's much in the way of updates.
Sure. So, wait until MOAI 1.0 is released (its currently in beta status).
Be grateful, however, that its been released without documentation already so that those of us who can get along just fine by reading the open source code can use it. If we had to wait for docs, we wouldn't be talking about MOAI now at all .. maybe in a couple more weeks.