Seasoned game & game-engine developer Ben Garney has a new game development engine called Loom.
Ben demonstrates competency in a long series of projects. He worked on the Torque Game Engine with GarageGames at www.garagegames.com (Site No Longer Live), the PushButton Game Engine for Flash with PushButton Labs at www.pushbuttonlabs.com (Site No Longer Live). Support from PushButton (including its website, updates to its source code and forums) abruptly ended in 2012. PBE’s spiritual successor launched in 2012 as Smash Game Framework at www.smash.io (Project apparently dead after no updates since more than ‘a year ago’).
Now he and his team have Loom, The Loom Game Engine at www.theengine.co. The word ‘loom’ is used for a device used for weaving textile projects and Loom is also a popular 80′s computer game, both spiritually aligned with game development. However, I wish it had a more unique name to facilitate online searches.
Pros of Loom (Paraphrased from theengine.co);
- Pragmatic Development - Loom features a lean and fast workflow without strict development rules or required frameworks.
- Freedom Of Choice - Access and edit C++ core source code, access and edit LoomScript core source code, or simply add your own custom LoomScript. LoomScript sits atop C++ and can access any C++ library.
- LoomScript - LoomScript is an easy to use, new language modeled after AS3 with features inspired by C#. LoomScript is based on Lua which is concise, robust, proven, and supported by tools, debuggers, and community.
- Useful Libraries - CSS Styling, UI Markup, Tweening, Dependency injection, JSON/XML and more…
- Loom Architecture - Three parts; Call LoomCLI from your command line to create ‘new’ projects and ‘run’. The LoomSDK is precompiled LoomScript with powerful libraries. The NativeSDK is the raw C++.
- Built For Teams - Three tiers; Artists can create & integrate assets into the latest build without bothering others. Scripters use LoomScript for the bulk of development. Need extra power? Extra features? Coders can access the C++ layer.
When and where it is manageable, I am a huge fan of using and reusing the same project for multiple platforms. Loom 1.x currently exports to TV (Ouya), Desktop (Mac & Windows), and Mobile (iOS & Android). Future support for other platforms is in discussion on the loom forums.
- Save Time – Develop, iterate, QA simultaneously cross-platform
- Focus Marketing dollars – Instead of marketing the game on two platforms separately, we can do it at the same time
- Momentum – Word of mouth dictates that downloads on one platform will possibly translate into downloads on the other
- Maintenance - We’d rather be working on the next game, than debugging separate platforms
What is Loom?
With cheap, powerful tools and massive exposure to new game players, there has never been a better time for indie game developers. – Me
There are many available tools for indie game development. Loom is a powerful 2D game engine with live reloading of code and assets, a friendly scripting language, and an efficient command-line workflow.
Loom’s competitors include 2D-capable gpu-accelerated cross-platform mobile game development platforms such as Adobe AIR, Corona & Unity3D as well as the newcomer Stencyl. The approach each platform takes is diverse. Where-as Stencyl is the a complete IDE for project setup, art & development which requires no coding, Loom is a raw platform without even a GUI.
Checkout the screenshots of Loom’s Workflow;
- Create a new project via command line.
- Create your raster assets using your favorite creative programs.
- Create your LoomScript code using any text editor. While a Loom IDE is a top feature request which is in active discussion, SublimeText is the current free, recommendation.
- Compile (run) the project via command line.
We believe that fast iteration times across multiple devices simultaneously lead to better, faster, cheaper game development. – Loom Documentation
Loom‘s design goal is to keep you on the fast development path as much as possible, while still preserving access to slower, more difficult, but still essential development paths. This gives a substantial benefit to development teams without blocking them.
The Loom GameFramework
Loom offers a powerful (optional) Loom GameFramework (LGF). A game framework is a system to organize your code specific for game projects.
LGF is made of three general types of classes. There may be many of each type in each game project:
- Manager – Managers are the brains of the operation — each one has a unique task; for instance one focuses on the spatial area of the screen and the objects within it and one on graphics rendering of visible objects. Depending on its role in the game, a manager may or may not relate to entities and components directly.
- Entity – Each visual element in your game is represented by an entity. This could be anything; your player, the enemies, collectible items, etc…. Entities can be non-visual too.
- Component — Each entity contains components. This is where the bulk of your game code lies. Each components handle a specific responsibility. For instance perhaps one component handles rendering the entity in which it resides.
Developers can extend existing managers and create new managers too. LGF ships with managers for our most common needs. Here is a partial list of the managers packaged with the core Loom.GameFramework package:
- TimeManager – Manages all time related functionality in the engine. It provides mechanisms for performing actions every frame, every tick, or at a specific time in the future. A tick happens at a set interval defined by the TICKS_PER_SECOND constant. Using ticks for various tasks that need to happen repeatedly instead of performing those tasks every frame results in much more consistent output. However, for animation related tasks, frame events should be used so the display remains smooth. You can pause/play your game easily here too.
- ConsoleCommandManager – Process and dispatch commands issued via the asset agent.
- PropertyManager – Properties are like public variables; set/get manually or bind automatically.
Entities are essentially empty shells. As a developer you fill them with the core components &custom components needed. Each component has access to any Loom API desired and responds to custom events as well as the following built-in Loom events:
- onFrame – Best used for graphics rendering-routines; this occurs once per frame-rate (e.g. 60 times per second for 60 FPS). Included for AnimatedComponent
- onTick – Ticks are guaranteed to happen at a fixed interval. If the frame-rate slows down due to some number-crunching or heavy rendering, Loom will attempt to ‘catch up’ by calling more ticks. It balances the run-time experience well. Included for TickedComponent.
- onThink – Based on an arbitrary, per-use timer. This is ideal for AI code which can be processed slowly (e.g. every 1–5 seconds). Included for QueuedComponent.
If you have setup a programming environment before (Flash, Java, HTML5), then you should find Loom easy to setup and use.
Here are the links and tips;
- Download Loom (CLI & SDK Together) – Visit the Loom downloads page.
- Download examples - See the list of examples or download and view the source-code from the Loom downloads page.
- Learn to run code with the examples and create new projects – Visit Loom getting started page and the Loom documentation page. Curiously, the class-by-class documentation is not available online, but is indeed downloadable.
Creating My ‘FlyerGame’
To learn Loom, I followed my own ‘Getting Started’ steps above and then created my own complete game. I used assets and game logic from “FlyerGame”, a game that I have recoded many, many times using game frameworks. The HD Video Screencast and source assets are available (See ‘Member Resources’ below).
I have limited experience with Loom, but from reading the Loom forums and reviewing the Loom example code I understand that optimizing a project – especially rendering with a constant frame-rate on a variety of devices takes time.
I like what Loom does well; LoomScript is light and powerful, the workflow is VERY fast. I haven’t tapped into the full strengths of device-specific CSS (e.g. to size a button uniquely on iPad vs iPhone) yet, but it looks really compelling.
Library of Libraries
The product is both at “1.0″ and costs money which to me means The Engine Co is positioning it as a finished product. However a look at the feature requests from the community and bug reports/omission from the forums, which include countless bare essentials (e.g. complete code documentation & incomplete method override support) is a sign it is not yet ready to stand against full realized competitive cross-platform mobile engine.
The engine also misses many device-specific features and most every OS-specific integration features (e.g. in-app purchase, social network integration, ad monetizations) which the forum promises are coming soon.
When the docs & wiki are complete and describe features which are implemented bug free the product can be recommended with more confidence. The team is working fast and communicates so frequently, that we may see that level of completeness very soon. A dedicated IDE (currently the #1 feature request) with auto-complete and more will help seal the deal.
The license pricing;
- 1. Starter- Target desktop 0nly – Free!
- 2. Indie – Target mobile too
- 3. Pro – Includes support
- 4. Enterprise – Includes more support
Loom is very new and is changing rapidly. I reached out to Loom developers to get a reactions based on Loom CLI v#1.0.506 and Loom SDK v#sprint27.
- Live Reloading – Greatly accelerates development
- LoomScript – Easy to learn (especially from AS3) and powerful
- Support – Loom dev team is open, responsive, and productive
I find the component-based architecture suggested in the Loom API to be powerful and a distinguishing feature among competitors.
- Young platform – Has many bugs, missing basic implementations (“lots of loose ends”), and lacks must-have features of competitors
- Lack of documentation, tutorials, & examples.
- Rendering – The “CSS layout is pixel [dependent and] has little practical use”, and overall the “performance is not amazing”.
- No full-featured IDE – Although a 3 code editors already provide partial support.
The lack of IDE is an obstacle for me. And the creator’s conscious choice to use existing 3rd party APIs to solve basic implementation needs is wise (provides functionality) but weakens the platform tremendously as it becomes a ‘bag of APIs’ which hurts the learning curve.
Gotchas & Advice
- Read the docs
- Download, read, and run the examples
- Just “Dive into it!” and remake a basic game from scratch
“Is Loom ready for professional development?”
- No, It is the “early days for the platform so there’s not so much”.
- No, “standard mobile features like reading/writing to camera roll are not exposed yet (as far as I know)”.
- Yes, I think its ready for professional deployment, If you can get over the bugs and [missing] features”.
- No, we’d have to “spend a lot of time working on supplementing the engine, and less on making our games”.
- And as one developer said – I am “not sure. I’d have to make a game with it!”
For me, Loom is absolutely ready for production in a vacuum. However there are many compelling alternatives to use which are more robust.
After ‘Getting Started’ and following my HD Video Tutorials, here are more resources to fuel your Loom savvy.
- VIDEO: Welcome To Loom – Watch the HD Screencast Video Tutorial*
- VIDEO: FlyerGame With Loom – Watch the HD Screencast Video Tutorial*
- SOURCE CODE: FlyerGame With Loom – Download, view, and run the code.
- Find common answers on the Loom forums page
- Post your comments on Loom below on this blog page.
*See ‘Member Resources’ below.
NOTE: Source code is available, but videos are NOT yet available.