The past several days I’ve been looking at the Loom Game Engine, which as of writing is still available for free, but for a limited time only. Loom is an ActionScript based game development system with a bit of C# mashed in, built over top of the Cocos2D library, driven by a handy command line interface that supports live reloading of code as well as easy deployment to iOS and Android devices.
The series was a combination of tutorial, diary and review, documenting my experiences working with Loom. The parts are:
Keep in mind, this is only my experiences after spending about 40 or so hours with the SDK. I have pretty much zero prior ActionScript experiences and not a ton of experience with Cocos2D coming in. This isn’t strictly a review, there will be no score at the end, instead its my first impressions and nothing more. Hopefully my time evaluating will make your own evaluation quicker.
So… shall we jump in with the good, or the bad first? Well, let’s hit the good first.
Quick to download, install, configure and run. Server side processing and CLI make it easy to get things up and running. No need to set up a complicated toolchain, including Android and iOS dev environments. Learn a few commands and you’ve got a project up and running on your device of choice.
Cocos2D. If you know it and like it, you will like Loom. In many ways you can think of Loom as Cocos2D++, powered by a slightly improved ActionScript.
Support. It’s stellar, seriously AAA stellar. Most of the times I ran into a problem, the forums had my solution, which is pretty impressive for a new game engine. The developers are very active on their forums and are willing to go a step beyond, it’s very impressive. My one support inquiry was answered, not just by someone from TheEngine.co, but also from someone in the community.
It’s free right now. That’s always nice. However, 7 days from today, it no longer will be.
LoomScript. It’s ActionScript. Plus delegates from C#, plus the by value Struct type, plus type inference, plus reflection, plus being strongly typed. In my experiences with the language, I enjoyed it, with a but*.
Development is rapid. They release sprints, rapid iterations with well defined purposes. Coupled with a very clear bug tracking/priority system. This is good, I wish other projects *cough*Moai*cough* would adopt this attitude!
Documentation and samples. There is a good amount of documentation, but far too much of its stubs, and a good 15 or more examples. These are the key to learning, much more so than the documentation.
Source code is available. If you are the C++ type, it’s all there. I only looked briefly, but it is clean enough. I would hesitate to commit a serious project to a library I didn’t have the source code for. It’s not a deal breaker by any means, but it buys a whole lot of peace of mind having source access.
Cocos2D. Every single time I ran into confusion or frustration, at the end of the day, Cocos2D was to blame. The library is large, some might say bloated, and not entirely intuitive. It often does things in a manner you wouldnt expect, and provides three ways to do things, even if one way is better. At times it’s over-engineered and other times, it just sloppy. Naming conventions can be pretty inconsistent, parts have been deprecated. Then again, this is a Python library, ported to ObjectiveC, then C++ and now wrapped again so expect a certain number of warts. Simply put though, if you hate Cocos2D, you will hate Loom. If you’ve never used Cocos2D, expect a bit of a learning curve.
Documentation isn’t as extensive as I would like. LoomScript specifics are under documented, you need to glean what you can from the forums and examples, because the documentation isn’t that extensive. At the same time, when trying to puzzle out parameters for delegates (which Loomscript add over ActionScript), I had to drop down to the C++ source code level to figure things out.
Requires an internet connection. You need to log in to build your app. In this day and age, this generally isn’t a huge problem, and you’ve got full source code if this really bothers you, but it can be an annoyance. While evaluating I found my password was inexplicably reset and there was a DNS error one day that prevented the tools from working, so obviously there are downsides to requiring a server connection. On the other side of this code, the simplicity of building for Android and iOS is enabled by the server based nature of Loom.
LoomScript extensions are nice, but confusing. This is an area that really needs more documentation and focus in the examples. The LoomScript changes can on occasion make existing Cocos2d-x wrong, these are the kinds of things they need to point out.
The Things I Would Change
There are two things I found… annoying I suppose is the word, while working with Loom. Both things that can be easily fixed, and both wholly related to each other.
The first thing… in order to access the forums, you need to register. Second, in order to access the documentation ( which is pretty good, but flawed as you can see above ), you need to run it locally, even though it’s HTML based.
Why do these two things suck? You handicap Google. My workflow generally starts with going to Google, and I can’t with Loom. As a result of hiding your forums behind a password and your documentation being locally installed, I completely lose the ability to use Google. Yes, the local help has search functionality, but it doesn’t even approach what I can do with Google queries.
This is pretty simply summarized… If you don’t like Cocos2D, you won’t like Loom, it’s that simple.
On the other hand, I am highly considering using Loom for my own upcoming game project, even though I have zero ActionScript background. So, the fact I am willing to use it for my own project is probably as good of an endorsement as I can give.
Loom is certainly an interesting project, be sure to sign up before the price tag rises!