Why We Built Loom

Loom exists because we couldn’t find the game technology that we wanted to use.

We wanted a game engine that was great for building casual 2D and 3D games quickly. But the most mature and solid engines, like Unity and Unreal, are focused on high end 3D.

We wanted a game engine with a developer focused workflow, but couldn’t find one. We have become used to great developer tools like Git, Heroku, Ruby on Rails, make, and bash - that are command-line driven, extensible, self contained, and used on a daily basis.

We wanted a game engine that was lean, because download size is crucial in mobile and web games. But it’s hard to find a desirable engine that also has a small footprint. Unity clocks in around 8mb, while AIR is closer to 12mb! Loom is a svelte 2-4 megs compressed based on features YOU decide to compile in.

We wanted a game engine that would let us take off the hood and dig inside, but it is hard to find good tech that includes full C++ source code access. AIR, Unity, and Corona all expect you to ship a game without ever encountering a bug or missing feature.

We wanted a game engine that brought something innovative to the table. A lot of the current crop of mobile engines are YALEs - Yet Another Lua Engine. Engines like Moai, Corona, and LOVE take Lua, integrate some 2D rendering, sound playback, write some tutorials, and call it good. There’s nothing bad about them, but they aren’t particularly exciting - the oatmeal of game technology!

We wanted a game engine that had a powerful and familiar scripting language with a tiny footprint. We needed great profiling and debugging, and excellent bindings to C++. We wanted something more effective than Lua, so we invented LoomScript.

We wanted a game engine that wasn’t carrying over a decade of technical cruft, but a lot of the players in this space are products that were around when I started with GarageGames in 2002! Marmalade, Unreal, Source, and Torque have been around for a long time and they are set in their ways.

We wanted a game engine that leveraged genuinely useful technology. There are great libraries out there like TinyXML2, Sean Barrett’s stb_image, Cocos2DX, and the Lua virtual machine. But we saw most engines going with bigger, bloated options.

We wanted a game engine that was a good deal, especially for smaller studios (like us and our friends!). We don’t have guarantees of huge profits on our games, so even a 10% revenue share is a big deal - never mind something higher like 25%. Never mind the auditing and book-keeping that that implies! We also didn’t have tens of thousands of dollars to spend on licensing for our team. That said, we also wanted whoever we bought from to have a good business model so we wouldn’t be stuck with an orphaned product.

In the end, we decided that the only thing for it was to make it ourselves. Which we did. And we called it Loom.

Loom has an awesome workflow with live reload and great command line integration. It’s lean and small with low technical debt, so it has a small footprint (2-4mb depending on platform). It’s at an indie-friendly price. It uses good libraries but innovates when it has something worth adding. Get Loom from our website now.