Hacker News new | comments | show | ask | jobs | submit login
Loom: Native mobile game engine with live reload of code and assets (theengine.co)
64 points by ryanstewart 1609 days ago | hide | past | web | 38 comments | favorite



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)


Ask me about Loom.


Well? What about Loom?



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


I was thinking the exact same thing…


So was I! Great game.


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


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


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


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


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


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.


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


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?


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.


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!


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


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.


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?


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


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


There is a tech scene in Eugene? Neat!


Here are my first impressions from a brief test drive.

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


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!


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


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

Cheers!


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


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?


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.


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?


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?


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.


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


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.


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


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




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: