Loom: Native mobile game engine with live reload of code and assets

Are there any plans for compiling to anything browser based? That's just such a great platform to start deploying a game. Tweaking and iteration is fast—you can deploy multiple new versions a day and get feedback—and once you have a good enough game, you can deploy to these other platforms. It's a dealbreaker for me.

From someone who is writing a game in his spare time, this looks promising, but not something that I will consider using.

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

No idea about Android, but Ruby has been ported to iOS -- there is RubyMotion (commercial) and MobiRuby (open source, based on mruby), perhaps others.

We currently have a prototype of Loom running in HTML5 via WebGL and emscripten. We also have a much earlier version of Loom running under Flash Player using FlasCC. We could also potentially target NaCL in Chrome.

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

This is the first I've heard of Adobe dropping the Flash Tax, and I'm having trouble finding any confirmation of it. Where did you hear about it?