Loom: Native mobile game engine with live reload of code and assets
theengine.co
theengine.co
For live code-reloading, I simply use MOAI Remote when needed:
https://github.com/seclorum/metalab_sessions/tree/master/MOA...
But the whole point of having a native build environment for my dev machine, in the first place, is not really having to do much live-redeploy to mobile environments .. I easily spend 95% of my time developing MOAI code on Linux, running it on Linux, and then a little time spent just testing the build on all the target platforms. For the most part, it works extremely well ..
LOOM uses a dialect of AS3/ES4+(hint of C#) but compile to LuaVM bytecode. The runtime uses Lua/LuaJit(where allowed) and has a 2Mb footprint but this can be optimized in the native sdk.
Since early alpha the sdk has been very solid and as @bengarney's 3rd development platform, it has it where it counts.
Ted :)
* First, I am put off by the choice of a proprietary language. I can tell you right away that I am not going to use it, not ever. A proprietary language just won't cut it these days. Sure, Lua has its problems, but they are not big enough to warrant inventing your own ActionScript clone, in my opinion.
* Secondly, the front page says I can ignore LoomScript if I like, but it doesn't suggest what the alternative would be. I assume that it means writing directly to the C++ framework? If so, that's a crappy alternative. The attraction of engines like Moai is precisely that the scripting experience should so good that you could, up to a certain threshold of complexity, write an entire game without ever dipping into C++.
* Thirdly, I tried to find the API documentation, but apparently this requires me to not only download Loom, but install it. It's really important for me to have online docs I can browse anywhere without jumping through hoops to get it.
* Fourthly, the web site is very light on details. The Features page is very vague. It has a "gameplay framework", which I don't know what is. From the descriptions it's unclear exactly what Loom brings to the table; does it have support isometric games? Is it a scene graph engine? What about building 2D meshes, layers, asset loading, custom shaders, file formats, sound/audio?
From the vague description it looks like Loom is "just" some glue for tying various libraries together, centered on Cocos2Dx with LoomScript bindings -- unlike, say, Moai, which is an engine written from scratch that integrates some external libraries (Box2D and so on), but all abstracted through its own native API.
* Lastly, I didn't download it because the web site requires me to sign up. I just wanted to explore the code, not sign up for a license, so that's off the table.
I am currently on Moai. I don't love the APIs, I'm not a fan of Lua, and I was forced into writing C++ code way sooner than I expected (not a problem, but it's for fairly trivial stuff that Moai should have provided in the first place, and only because Lua is too slow at maths/vector stuff). On the other hand, Moai is free, open source, well-documented (with online docs), fairly mature, fast, has good APIs, an active community, and Moai Cloud (the hosted backend system) is reasonably priced.
In other words, I like Moai but I'm only something like 80% happy with it; it would not be terribly hard to entice me to switch to something better. If someone hacked up an engine on par with Moai, with slightly richer 2D features and a better language (Ruby! JavaScript/CoffeeScript with a JIT-based VM like V8 would also work) and a better physics engine, I would probably switch in a heartbeat. Superficial things like live reload I don't care much about.
Just my thoughts. I don't expect they are representative of game devs in general, although I suspect you will find that the choice of language will be a point of contention among more experienced devs.
All in all, this looks like a good toolset, particularly for those techie/creative hybrids who liked making games in Flash.
For instance, would I be able to do a simple fluid simulation, particle gelling etc with loom?
var f = function():void { Console.print("Hello world!"); }; f.call();
Not sure how much more first class it gets, but I'm open to your suggestions!
That said, we went with LoomScript over Lua because we did not want to use a language where OOP is an idiom. And we support one development path because, in our opinion, it is the best option - and because, in our experience, great platforms choose a "right way" to do things and run with it.
You do get the full source code, so if it really bothered you it would not be hard to "fall back" to plain old Lua. But I think that would be overlooking a lot of benefits.
* Simple yet powerful
* Supports multiple paradigms
* Fairly concise
* DSL friendly
* Very robust
* Small footprint
* About as quick as they come in this language space, even without LuaJIT
* Supported by tools, debuggers and a community
If I were contemplating building my own dynamic language to support something like a game engine there would have to be some pretty compelling arguments not to just use Lua. I'm sure you've thought about it - so what's the reasoning?
However I hope the $500/license doesn't show that they are planning to emulate Adobe too closely...
We feel our licensing terms are very fair: http://theengine.co/license
> Loom licensees receive full C++ source code (and did we mention that Loom licenses are FREE right now? (link to signup page)).
I think there "link to signup page" is a placeholder that made it on the webpage :)
Cheers!
Incredible effort though, I'm particularly impressed that it works over Wi-Fi, and the technology choices look sound. Anyone given it a try yet?
Each option has its positives and negatives.
With Adobe dropping the 'Flash Tax', it makes targeting Flash a much more desirable option, however there is a ton of merit to having things run in HTML5 (either WebGL or Canvas).
The long story short is, browser support is on the roadmap, but which path to take is unclear. So we're open to input from the community on this.
Cheers, Nate
What about native calls? (Like web popups or sharing/receiving files.) Is it necessary to enter the NDK nightmare? Are they possible?