This has been a long time coming. I owe all of our developers a brain dump on what the future holds for Moai. In no particular order, here’s what’s on our radar both around features and our own internal process maturity. More after the fold...


This is the number one ask from just about everybody. We’re planning on spending this coming week writing (mostly) reference and hitting our goal by the weekend. We’ll do a bit of additional feature work and bug fixes too, but I think everyone can agree that docs take priority.

Testing and Support

Dana Drew joined our team in a testing and support role and has been doing a great job. Even with Dana’s help, getting to 100% code coverage and building a comprehensive suite of regression tests for Moai SDK is going to take a while.

We’re also going to formalize two or three public repositories for Moai SDK that represent various stages of the development/release cycle and will generate reference docs for each (instead of just the official release). We already have clients using moai-dev/integration (my branch) and moai-dev/master (our ‘studio’ branch) in addition to the official release; we will clean up the naming of those and make it clear which repositories are tested and which aren’t.

I also want to call on the community to be proactive in sending us not just bug reports but repro cases. If you post bugs in the forum, ideally with a page of code to repro them, Dana will verify the glitch and add it to our issue tracker.


We’ve had some organic interest in tools support from a number of vendors and clients. Case in point, support for Texture Packer was generously provided by its author. You can also expect to support for 71Squared’s Particle Designer and Glyph Designer in the next release or two. This was contributed by our friend Chris Kohnert (of Go Go Kiddo/HareBrained Schemes fame).

I also think it would be great for someone to put together a commercial offering based on Moai consisting of an IDE (or authoring tool), a simulator and an app packager. That’s not something we’re planning to do, but I think it could turn into a decent business for someone.

We’ll continue to look for tools vendors we think would be a good fit for Moai and we urge you to do the same. Please reach out to your favorite tools vendors and ask them to add Lua export. We’re happy to feature them on our site if they do. Lua is easy to output, so between Moai and other Lua based solutions there’s no reason that more tools shouldn’t support it.

Moai Cloud

Programmable web services are a big, big deal. There are plenty of services offering fixed function web APIs, but if you want to really differentiate your game there’s nothing like being able to code the back end yourself. With Moai Cloud you can have all of your data in one place, ready to access any time you need it. That’s just not possible if you go with a random assortment of web services. What happens when your game needs to do something their API doesn’t support? Or you want to aggregate information across multiple services?

Of course, nobody wants to write everything from scratch, so with the Moai 1.0 launch we’ve included a great set of fixed function APIs that you can use without writing a single line of server code. Data storage, leaderboards, acheivements, push notifications and news tickers are all available now.

In the near future you can expect to see persistent processes and sockets (for turn-based and multiplayer games), more language options, more fixed function services and a marketplace for you to monetize the services and processes you write by sharing them with other developers.

I firmly believe a custom cloud back-end is going to be a must-have feature for every successful modern mobile game. With Moai 1.0 it’s time to start writing cloud code, no matter what your project is.

UI Widget Framework

This has been a feature ask from almost every user of Moai. Moai does a pretty good job of solving graphics and animation issues, but to date developers needing UI have had to roll their own using an ad hoc mix of props and text boxes.

With 1.0 we’ve expanded the capabilities of MOAIFont and MOAITextBox. The new architecture gives us a solid footing to go further with text and styling features. We’re also going to be looking at ways to provide a solid set of UI layout and widget objects to efficiently render Lua-based UI across multiple screen sizes and resolutions. These will be skinnable components rendered with OpenGL for seamless integration with your game content.

There are also a few things (like software keyboards and alerts) that really should be handled natively, so we’ll be giving you wrappers for those as well.

API Consolidation

Moai SDK 1.0 supports a lot of APIs for platform specific functionality now. In many cases there’s a separate API on each platform for what is essentially the same functionality. Case in point: MOAIBillingIOS and MOAIBillingAndroid. Same for MOAIAppIOS, MOAIAppAndroid, MOAIDialogIOS, MOAIDialogAndroid, etc.

A big goal for the next release or two is to consolidate these divergent APIs into single objects with as much cross-platform abstraction as makes sense. We’d much prefer to offer MOAIBilling, MOAIApp, etc. instead of two code paths for everything.

I’m not sure if this will come in the form of a new engine-side implementation of these APIs or a Lua wrapper, but either way it’s something we want to get done sooner rather than later, so expect big steps around unification in the very near future.

Engine Internals: Comments and Documentation

While the immediate focus is on getting a complete reference in place for Moai’s Lua API, there’s long term value in documenting the engine internals. The decision to go open-source has been a big help in getting adoption from serious developers, but there are a lot of moving parts under the hood. Finding time to comment the implementation and write some updated extension guides is important.

It’s a big undertaking and is going to come gradually. I will make a point to get an updated ‘Extending Moai’ document in the wiki with the current documentation push, but the timeframe for starting on more detailed engine docs (and doxygen reference) is mid to late summer.

Continuous Integration, Process Maturity

Re-implementing our build server is our biggest item of technical debt. We’re planning to get started on it early next month, most likely moving to Jenkins. The new server will need to support iOS, OSX, Android, Windows, NaCl and... yes, Linux. It’s been the time investment of extending our build server that’s prevented us from maintaining the Linux build so far. That’s been a big ask from the community and probably our most-viewed thread, so I’m looking forward to checking it off the list.

The new server will also need to auto-generate and deploy reference documentation for each public-facing repository, not just the release.

Automated testing and per-pixel output checking are important as well. While I don’t know if we’re going to be able to run automated tests on every platform, getting at least a baseline set of tests on the desktop platforms (and testing the samples) will be a big step toward maturity. And it’s not far off: we already support rendering to an off-screen buffer. We need to add the ability to pull texture contents back into a MOAIImage and to do a pixel comparison there. We also need to add a way for test scripts to record and play back events from the input queue. These features are all straightforward; implementing them will let us use Moai itself as our test harness and give you some powerful tools to test your own games as well.

Simple Collision Detection Framework

Box2D and Chipmunk are great, but for a lot of projects they can be overkill. In addition, neither library provides instancing, which for large scrolling games based on tilemaps can make a big difference in performance and memory use.

We’ve had an alternative ‘quick and dirty’ collision system on the drawing board for a while now and are looking forward to getting it in. This will give you a high-speed, easy to use alternative for overlap detection in your scenes. The initial implementation will use geometric primitives and shapes, but we’ll extend it to support bitmaps as well. That will also enable per-pixel hit testing for your hidden object and adventure games.

The main function of the collision library will be overlap detection, but we’ll also provide a basic set of ‘body-like’ primitives that can be used to prevent overlaps and manage response (such as sliding along terrain). You can use these for old-school arcade and adventure games when you need a different ‘feel’ than what’s possible with a more traditional model.


Moai SDK 1.0 provides a no-frills 3D rendering framework. The new object model is natively 3D, even if you use the MOAIProp2D and MOAILayer2D backward compatibility wrapper. You can attach your own shaders to any object, create geometry using MOAIMesh and also use multi-texturing with MOAIMultiTexture. You won’t be making games that compete with Infinity Blade using this technology, but it should be more than suitable for simple 3D effects or 3D pop-out objects rendered over your 2D scenes.

For a number of reasons, we don’t see big 3D as being the right strategic path for us. While we are committed to extending Moai SDK to better support 3D, implementing the kind of tool chain and authoring environment that would make for a competitive engine is just too costly - and there are already some great engines out there. If you have the budget for a 3D title, use Unity. You can still use Moai Cloud as your back-end.

Of course, there are still a few things on the 3D roadmap we plan to provide regardless. We’ll support skinning with matrix palettes as well as blend shapes for per-vertex animation. We’ll also add simple 3D culling based on additive volumes. There’s more on the list, but until we’re closer to having time to implement it, I don’t want to go into too much detail.

If you’re interested in 3D, stay tuned, but it will not be until later in the year that we are ready to roll out new 3D features. We have a lot of other features to finish out before we can get back to 3D.


First class support for isometric games has been on the list for a while and continues to be a fairly high priority for us. Higher than 3D, even.

We support basic isometry today. You can use MOAIGrid with non-square deck items to render diamond shaped and hexagonal grids. You can also flag props drawing with grids to emit a unique render call for each tile. This allows the layer to sort your map tiles against each other (and any other props in the layer) along any axis (or combination of axes) of your choosing. This is way more efficient than using individual props for each tile.

There are a few shortcomings with our current implementation. The first is that axis sorting means your isometric scenes need to be made up of more or less symmetrical objects. If you want to render elongated objects, you’ll have to break them up into tiles. To fix this we’ll need to implement the Filmation algorithm, which is a more sophisticated sort that uses the relative positions of objects in 3D space to deduce their draw order.

The second is that there’s no official support or spatial model for mapping between a 3D coordinate system and an isometric tile map. This is mainly a problem for games that need multiple levels of terrain. It’s probably something that can be worked around, but we’d like for ‘deep’ isometric scenes to work right out of the box in a more intuitive way.

Finally, we need to provide isometric collision and response. There’s an argument to just use a 3D model with an isometric projection, and that may be the way we go, but given the deeply grid-based nature of most isometric games (and the lack of 3D tools in the isometric workflow) we’ll need to provide a grid-based alternative to the partitioned ‘polygon soup’ we’d usually use to represent the terrain of a 3D scene.

My hope with all of these features is that we’ll find an elegant way to map our current 2D/3D scene and partitioning model into an isometric view so that we don’t have to double up on everything. It would be nice if setting up an isometric scene was as easy as calling a special initializer on the camera and maybe using a 3D alternative to MOAIGrid. It would also be nice if we could implement the Filmation algorithm using what we already have in MOAIPartition and MOAILayer without introducing a bunch of special cases.

At any rate, first class support for isometric games is a must have feature for the very near future.

Vector Shape Rendering

We’re familiar with other solutions that rely heavily on vector shapes and from our own experience (and from what we’ve heard) they are no magic bullet. Even so, it’s a request that comes up from time to time and it’s something we’d like to support.

We’ve looked at this a few times and have consistently managed to get busy with other features. I wish I could say there’s a great way to implement this feature, but there’s not. We have two basic approaches available to us: rip vector shapes to textures, either at load time or dynamically based on LOD, or triangulate the shapes and render them as meshes (which will also need LOD).

Neither approach is appealing. Ripping shapes to textures is going to spike performance as you animate and we’ll still need to fall back on triangulation if you scale up to the point where there’s not enough texture memory. There’s also going to be a lot of code and fuss around managing dynamic texture allocation. Glyphs for fonts are one thing as they are usually (more or less) regularly sized, but most vector images are built out of shapes that very wildly in size and will need to be swapped rapidly out of texture memory as they move and scale.

On the triangulation front, we did get a basic implementation working, but even simple shapes required a lot of triangles to render smoothly. So more work is needed there. It’s also going to be a lot of work to implement LOD without visible popping.

There are some vector shape rendering libraries out there. From my limited research, Cairo is the most mature, but I believe its renderer is based more on scan-conversion than triangle meshes. In any event, Cairo uses an LGPL/MPL license, which is a deal-breaker for us.

Vector shapes are definitely on the roadmap, but due to the technical investment required (and the fact that we’re unconvinced they will be as efficient as traditional bitmap or mesh-based assets) I’m not sure when we’ll get to them. The most likely way they’ll wind up being supported is if someone from the community can offer a solution for shape triangulation that doesn’t blow up the triangle count and is speedy enough for re-rendering as LOD changes.

Odds and Ends

There are a few small SDK additions that have been on my list for a while. We’ve been thinking about extending the animation system with waveforms, splines and Perlin noise. I have a slippy map implementation cooking I’ve been meaning to roll in. We could also use a 3D camera fitter and a suite of dampers to make things like springy-scrolling easier to implement. There’s a grab-bag of miscellaneous stuff that would be fun to add - little useful projects that could be finished in a couple of days. We’ll be peppering our releases with these as we have time between bug fixes and major features.

How you can help

If you want to support Moai and see us grow, use Moai Cloud. Write a nifty web service, user manager or back-end for your game. Use it to download customized data. Build cool social features that no one’s done before. Let your customers edit levels, draw pictures, take photos, write messages or compose music and upload their creations to the Cloud. Build a cool location based game where users can drop virtual game pieces in the real world. Send your users customized content and messages based on the day of the week or time of the year. Keep your in-game incentive and reward payouts in the cloud so you can tune them based on your Apsalar analytics.

Every modern game needs a Cloud back-end, so use Moai Cloud. Use our fixed function APIs or write your own in Lua. It’s a powerful platform and the price scales with your success. Moai SDK is free and open source. That’s not going to change. But if you are working on a commercial game for yourself or for a client, make a point to add a feature or two that uses Moai Cloud.

Use GameCenter and iCloud so you get featured, but double up your data for cross platform leaderboards, game state and customer accounts.

We need a few thousand developers on Moai Cloud and we need to be servicing around 10 million daily users. That might seem like a tall order, but remember that Moai games have already been downloaded millions of times. Crimson, The Moron Test, Go Go Kiddo are all heavy hitters - and of course your Moai SDK games can be, too. We’re proud of our million downloads for Wolf Toss, which started life as a tech demo. So the goal is feasible - we could do it this year. Just a few stand-out titles that use the cloud and we’re there.

So use Moai Cloud. The ability to write your own web services and deploy them in minutes without having to struggle with another language or web stack can be your secret weapon. And you can really push the limits of downloadable content, particularly on Android.

I’m going to be hard at work for the next few weeks writing docs and fixing bugs. While I do that, set aside a few days and write a web service for your game using Moai Cloud. Not just a test one, but something really good that will set you apart. There’s nothing that will move the needle for us faster than to see some serious adoption around the cloud offering.