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

by ryanstewart • 13 years ago

64 38 13 years ago

davedx• 13 years ago

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?

lukifer• 13 years ago

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.

bengarney5• 13 years ago

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

felixr• 13 years ago

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)

bengarney5• 13 years ago

I love me my old school adventure games but we got to the name in a wholly different way. :) Technically it is the "Loom Game Engine."

Svip• 13 years ago

Ask me about Loom.

skore2• 13 years ago

Well? What about Loom?

michaelmior• 13 years ago

I was thinking the exact same thing…

facorreia• 13 years ago

So was I! Great game.

primitur2• 13 years ago

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

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

diverted2• 13 years ago

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

primitur2• 13 years ago

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

diverted2• 13 years ago

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

goldfeld2• 13 years ago

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.

bengarney5• 13 years ago

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!

goldfeld2• 13 years ago

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

rb2k_• 13 years ago

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

bengarney5• 13 years ago

What URL do you see that? We'll fix it right away. :)

knaught3• 13 years ago

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

Cheers!

wildmXranat• 13 years ago

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?

grahammather• 13 years ago

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.

altuzar• 13 years ago

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?

sodiumphosphate• 13 years ago

Here are my first impressions from a brief test drive.

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

jeremysaenz• 13 years ago

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!

bajsejohannes• 13 years ago

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.

knaught3• 13 years ago

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• 13 years ago

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?

lobster_johnson3• 13 years ago

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• 13 years ago

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

lobster_johnson3• 13 years ago

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

tekromancr• 13 years ago

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

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

Related Stories