Loom is a native mobile game engine. Loom supports live reload of code and assets; deploy your game once and tweak every part of it until you are happy with it. LoomScript is a great, AS3-inspired scripting language. LoomCLI gives you a powerful command line workflow. You can develop on Mac or Windows, and run Loom titles on Mac, Windows, iOS and Android (with more to come).
Loom is pragmatic - it is designed to provide a lot of useful services without imposing a strict development paradigm. We believe that every game has different needs and that it’s in everyone’s best interest to make it easy to embrace these differences, rather than dictating how work must be done.
That’s why Loom features sensible defaults, not rules set in stone. Nearly every part of Loom is modular and easily torn down, rebuilt, or replaced. Don’t like our UI choices? Whip up your own, or integrate a third party library. Hate LoomScript? Ignore it - or modify the compiler to add the language features you do like. Have a vital feature that requires native support? Grab the library and expose it to script, or add it to the C++ side of the codebase.
We leverage existing best of breed technology when we can. Why reinvent the wheel when there is a perfectly good one already out there? We use Cocos2DX for our rendering, Lua for our script VM, Sean Barrett’s excellent libraries for image loading, CMake and Rake to compile the native SDK, Ruby for LoomCLI, and InnoSetup for the LoomCLI Windows installer. We use a port of Smash/PushButton Engine for our gameplay framework. And we use familiar formats like XML, JSON, and CSS to drive our systems. Our goal is to use technology that is successful in the global game ecosystem.
Loom licensees receive full C++ source code. We give you all the pieces to build Loom, so you control your own destiny. If there’s a critical bug that has to be fixed today - you can fix it. If there is a feature you have to have to build your dream title - you can add it.
Of course, we listen actively to the community. When you post on the forums, a notification goes into our company chatroom within seconds - prompting our engineers to get right on your issue. We fix bugs and add features all the time, too. Most days we ship five or ten new Loom builds out to the community. And a new stable build goes out every week or two. We strongly believe in test-driven, continuous deployment, and we’ve invested in the build infrastructure and engineering discipline to make it a reality for Loom.
Our licensing also supports your freedom to choose. After your support period runs out, you can still use all the game code you’ve written, as well as all the code you’ve gotten from us, forever, in as many new games as you want. Of course, we hope that you’ll like Loom and find that updates and support are worth the money.
The best way to understand a new language is to take a look at it:
As you may have guessed, LoomScript is derived from ActionScript 3, with a couple of things borrowed from C#: delegates, implicit typing, and its reflection API. We’ve also added coroutines and the yield keyword.
LoomScript runs on the battle tested Lua VM. Instead of embedding a huge language runtime with megabytes of dependencies, we developed a custom compiler to target the leanest and most feature-rich virtual machine in the industry. Due to Lua’s dynamic nature, the VM gracefully handles reloading your codebase on demand.
Debugging the LoomScript in your project takes one command: `loom debug`. Our command line debugger, with a familiar GDB-esque interface, works on device or desktop with equal aplomb. LoomScript also features built-in profiling capabilities so you can always tune your code for maximum performance.
LoomScript is designed to work closely with existing C++ code, so bindings are a snap. Exposing a function or variable to LoomScript takes just one line of code. And the bindings are fully validated and typed to catch any typos or mistakes right away.
Last but not least, you get the full C++ source code for the LoomScript stack - from VM to compiler to debugger to profiler. The compiler is fast and well-architected, so adding language features or optimizations is easy. And if you do run into a bug, you’ll never be left in the cold waiting for a fix.
We don’t expect you to write your game in a vacuum. Loom comes with a selection of powerful libraries to help you build great interactive experiences. Included out of the box are:
Loom also ships with Chipmunk physics and Cocos2D for rendering.
Deploying adds friction to your development. That’s why Loom allows you to load new code, textures, CSS, LML, and other data into your game without a frustrating redeploy. When iteration time goes to zero, you are able to build better games faster and more cheaply.
The Loom asset agent runs on your desktop (LoomCLI does this for you!), and sends updated assets and console commands to your game, running on device or desktop. Your game sends back log output. Of course, this can all happen for as many devices as you care to connect.
Seeing your changes live makes multidevice development easy. Simply make a change and see how it plays out on all the devices you care about simultaneously. Check the logs from each to make sure everything works properly. Enjoy a fast and efficient development experience. What could be easier?
Loom has three parts: LoomCLI, the Script SDK, and the Native SDK.
LoomCLI is what provides the smooth command line workflow. Comparable to Heroku or Ruby on Rails, LoomCLI simplifies using different builds of the Loom Script SDK, creating new projects, running your game, using the debugger and asset streaming systems, and packaging/deploying your game onto mobile.
A Script SDK is a precompiled version of Loom and related tools which can be used with LoomCLI to develop with script. We provide prebuilt Script SDKs for you (typically releasing 5-10 updates per day). When you package a Loom game, you combine your script + assets with compiled binaries from a Script SDK.
The Native SDK includes the full C/C++ source code for Loom and related tools. It also includes all the infrastructure to compile and run Loom - primarily Rake and CMake scripts. The Native SDK lets you build your own Script SDK to use with LoomCLI. Or if you want, you can develop your game entirely from within the Native SDK without using LoomCLI or LoomScript at all.
If your game needs to fit over the air, download size is paramount. You may have a budget of only 25mb depending on what store you are using. Loom is designed to minimize its footprint for three reasons. First, a small codebase is a maintainable codebase. Second, smaller codebases tend to play nicer with CPUs. And third, every byte you save on code footprint is a byte you can spend on content that makes your game unique and valuable to your players.
To that end, let’s do a quick shootout. An empty Unity iOS project is ~10mb compressed (see http://stackoverflow.com/questions/10493507/unity-iphone-app-size-is-too-big). An empty Corona project is about 8.7mb (or 2.2mb if you pay for the pro version) (http://stackoverflow.com/questions/6517653/corona-sdk-produced-iphone-app-size). An empty Loom app comes in at just over 2mb, depending on platform, for all versions.
Finally, because C++ source is included, you can choose to drop features you aren’t using or tweak build settings to save more space. We’re also working on reducing our size even further.
Games are built by teams, and Loom is built for teams.
For the Coder, we provide a powerful Native SDK. Take all the covers off and tinker with the fundamental elements of the Loom Engine. Add native features and integrate 3rd party libraries. Go deep and build new script SDKs to share with your team.
For the Scripter, we provide the LoomCLI and Script SDKs. A convenient command line workflow keeps development focused, and live reload keeps it fast across all platforms and devices. Realtime debug consoles let you see what’s happening in your game and issue debug commands to move things along. The script debugger helps you troubleshoot, and integrated docs keep reference material handy.
For the technically minded Artist, live reload and easy deploy are key. Boot the game up on all your devices with a single command and start tweaking LML, CSS, textures, and other assets. Integrating art becomes easy and iterative instead of frustrating and slow.
Finally, QA can benefit, too. It is easy for them to deploy different builds of the game, and bidirectional communication means they have easy access to logs and other debug info to file helpful bug reports.