

Loom: Native mobile game engine with live reload of code and assets - ryanstewart
http://theengine.co/loom

======
felixr
When I read the headline I was somehow expecting a native port of the Loom
adventure game ...

<https://en.wikipedia.org/wiki/Loom_(video_game)>

~~~
Svip
Ask me about Loom.

~~~
skore
Well? What about Loom?

~~~
lobster_johnson
It's a Monkey Island reference:
[http://en.wikipedia.org/wiki/Loom_(video_game)#Appearance_in...](http://en.wikipedia.org/wiki/Loom_\(video_game\)#Appearance_in_other_media).

~~~
skore
Ouch, right in what I assumed to be pitch perfect geekdom. I had that coming.

------
primitur
I've got the same development capabilities with my current MOAI environment -
dev on Linux or OSX, deploy to repo, get app for any of the architectures
built by my build server: linux-amd64, linux-x86, linux-arm, osx app bundle,
ios appbundle, android, windows, NaCL ..

For live code-reloading, I simply use MOAI Remote when needed:

[https://github.com/seclorum/metalab_sessions/tree/master/MOA...](https://github.com/seclorum/metalab_sessions/tree/master/MOAI/MoaiRemote)

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

~~~
diverted
In LOOM arrays start properly at 0 and @primitur your MOAI is showing...
<https://www.google.com/search?q=primitur+moai>

~~~
primitur
Never had a problem with 1-based arrays in Lua, and diverted: thanks thanks,
in fact I am a huge MOAI fanboix, so .. yeah ..

------
diverted
I have been using LOOM for the past few months in beta. The live-workflow
really streamlines development and changes how you build apps and games. The
live-reload feature is development-time only. With -live-reload enabled, you
simply press save and new bytecode and game assets are pushed to running apps
over wifi. The edit/run cycle is very fast and provides for great team
iteration on gameplay and graphics.

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 :)

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

~~~
dman
Which platform are you developing on? Wouldnt Ruby break your ability to ship
on ios / android?

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

------
lukifer
I doubt that Apple will let Loom-based games into the App Store if live reload
is enabled; my understanding is that scripting languages are only acceptable
if all code is bundled and not loaded remotely. (As a web guy, the concept of
waiting days to push a fix is crazy, but it's their Garden.)

All in all, this looks like a good toolset, particularly for those
techie/creative hybrids who liked making games in Flash.

~~~
bengarney
Loom's live reload is mostly for development purposes. You could try using it
in deployed games but obviously it presents issues (for instance with Apple).
Some game studios do ship bytecode on the fly to their iOS games, but they
understand the risks they are taking...

------
wildmXranat
Ok, you have my attention. Coming from experience with other layered engines,
Lua based ones as well, tell me about its limitations and performance
characteristics. Does the the engine have any limiting edge cases where using
some aspects like direct pixel addressing, large tiles or many tiles, world
boundary optimizations, # of physics objects can spiral the upper fps down.
Previous guesses are just examples and may not representan issue present in
Loom, but feel free add to the list if its worth mentioning.

For instance, would I be able to do a simple fluid simulation, particle
gelling etc with loom?

------
goldfeld
Why the hell force me into LoomScript when Lua would have given a readily
available source of learned game developers? Delegates, are you kidding me? I
refuse to program in a language that doesn't treat functions as first class
citizens.

~~~
bengarney
Valid LoomScript:

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!

~~~
goldfeld
The only examples readily available in the linked page are with onSomeEvent,
which may have been of a special function accepting type, so that you could do
what you did above was not immediately clear. "Delegates" and "C#" also strike
the wrong chord with me. And if you run on the LuaVM, why would you not allow
Lua interspersed or replacing LoomScript? I'd be that much likely to look into
this framework, as I'm always looking for more reasons to use Lua, and less
reasons to learn new languages (currently I already have VimScript, R, Awk and
possibly Rust on the pipeline.)

~~~
bengarney
If using Lua is the primary factor in your technology choices, you may want to
use Corona, Love, MOAI, or another high quality Lua-based game engine product.

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.

~~~
tomlu
What are the benefits though? I wouldn't say using Lua is a "primary factor",
but Lua is:

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

~~~
EwanG
The main benefit I see (though I am amused not to see it mentioned here or on
their site) is that a lot of Flash programmers will see it's almost like AS3,
and be willing and able to get comfortable with this since they "know" how it
works.

However I hope the $500/license doesn't show that they are planning to emulate
Adobe too closely...

~~~
knaught
The Engine Company is a small company (5 of us) based in Eugene, OR. We are
self funded so we don't have any VCs that we have to please.

We feel our licensing terms are very fair: <http://theengine.co/license>

~~~
seanmcdirmid
There is a tech scene in Eugene? Neat!

------
sodiumphosphate
Here are my first impressions from a brief test drive.

<http://luciangames.com/blog/2013/2/26/the-loom-game-engine>

~~~
jeremysaenz
One of the Loom engineers here. Nice writeup, lots of great feedback here, I
filed a Story specifically for the route you took and how to optimize it. It's
fun to have "As a sodiumphosphate..." stories, keep em coming!

------
rb2k_
Just in case anybody from the Loom project reads this:

> 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 :)

~~~
knaught
Haha.. good catch. Already have submitted a pull request with the fix for it.

Cheers!

------
davedx
This looks pretty nice, and the live reload is great - though I have to say
I've needed live reload more when working with native apps than with games.
That's probably because I always use cross platform engines for mobile game
development (libgdx and Unity).

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?

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

~~~
knaught
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

~~~
rdw
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?

------
altuzar
Don't know if there are big advantages over Moai or Cocos2dx-javascript, and
not sure about yet-another-language-to-learn, but looks very interesting.

What about native calls? (Like web popups or sharing/receiving files.) Is it
necessary to enter the NDK nightmare? Are they possible?

------
grahammather
Are there any games already out there using this technology? In the apple app
store would be especially useful to see, since I share the concern that this
tech might be rejected by apple.

------
tekromancr
Really excited to see a platform that works on Linux... eventually.

