How Crimson: Steam Pirates (#1 game on iPad) Was Built in just 12 Weeks.

If you haven’t yet played Crimson: Steam Pirates, download it today and give it a try.  Crimson is a turn-based strategy game and swashbuckling adventure that takes place on, above, and below the Caribbean Sea.  It’s the first game developed by Harebrained Schemes, the first game published by Bungie Aerospace, and it’s what I personally spent my summer days and nights working on along with the rest of the team at Harebrained Schemes.

Crimson: Steam Pirates and the first 8 missions were released free to play for iPad on September 1^st, 2011, with additional mission packs available via in-app purchase for $1.99 that continue the original storyline.  The game quickly gained the #1 position in the Free App category on iPad in 8 countries.  It held the #1 Free App slot in the United States for 5 days.  It’s still a top 5 iPad Strategy Game in 38 countries.

The Crimson team at Harebrained Schemes is made up of 7 people at its peak, and we had a total development cycle of just 12 weeks.  We were able to pull this off due to a few key things:

Since the Moai game development platform is free to use with attribution, there’s no reason that other game studios or indy developers out there couldn’t use the same platform to build a great game in Lua on a tight timeline.

In writing this post, I’m hoping other developers will get a sense of some of the decisions we made in building Crimson, how we made use of the Moai platform, and whether similar decisions might make sense for your own games.  If you’d rather just watch a video though, I’ve got you covered there too.  There’s a video interview with Jordan Weisman (CEO, Harebrained Schemes), Patrick Meehan (Creator of Moai) and yours truly that’s worth checking out.

Working with Flash content:

The art team at Harebrained Schemes prefers to work in Flash, and one of the reasons we choose the Moai platform is that it supported our existing art pipeline.  Most of the animation effects in Crimson: Steam Pirates (turning paddle wheels on ships, explosions, fore ship wakes, etc.) were created as flipbook animations in Flash.  These were then exported via Flash Javascript plugins to texture atlases (as PNGs), with corresponding Lua files containing the time, rotation and the specific sprites to use for each frame of an animation.  The automation worked well for the team, allowing the Flash team to generally work in batches.  They’d start by working up prototype animations over a day or two and the programmers would integrate these into the game.  Once the integration was done, the artists could come back and iterate on the animations and graphics weeks later without any programmer help.  They’d just export all the new work, look at it in game, and then make adjustments and export the art again.

One of the funny things about our use of Flash for art production and the look and feel of the different parts of the game experience is that the ship boarding action combat sequences look a lot like Flash animations on screen, but these are actually done programmatically using MOAIEaseDriver to move the art assets around.  Our art team really didn’t do much tweening in Flash, so when the gameplay called for a Flash-like experience, we built that into the game programmatically instead.

Multi-layer battlefield and rendering:

The battlefield of air, sea, and undersea is done with just three layers.  Water shimmering effects are done using a combination of a flipbook animation (imported from Flash) and a Moai particle effect attached to the camera.  The submarines are made to look shallow-submerged and deep-submerged through the application of MOAIShaders (partially transparent simple shaders) to the same art assets used when the submarines are at the surface. 

The island terrain is made of four layers altogether.  There’s a cost in runtime performance, as it takes 4 passes to render things and the whole map is stored in memory, but this wasn’t a serious bottleneck.  We thought about moving to a tilemap for the terrain, but decided not to go this route because it worked the way we originally built it and we didn’t have extra time to spare.  Making the change to tilemaps would have reduced the compute time to one pass and may have become necessary if the game had called for extremely large mission maps.

User interface and controls:

At first Crimson: Steam Pirates used a sub-thread to poll for input events.  This was fast to code and is a really useful approach for simple games.  Since Crimson has a mouse-like control system for everything except multi-touch zooming, both mouse clicks and touch events were mapped to the same Lua wrappers and triggered the same gameplay logic in the polling loop. 

Eventually, as the game grew more complex, we changed to using onTouch events provided by Moai.  By that point we had dozens of objects on the screen that could receive input and the new event-based code was much cleaner to work with.

Testing on PCs as well as devices

One of the great things about the Crimson control scheme and Moai’s native hosts for PC and Mac is that from the earliest iterations everyone working on the game could test gameplay on their dev machine (Mac or PC).  We didn’t have to buy a stable of iPads early in development, or a shiny new Mac for each team member.  Plus we saved the 2-3 minutes per developer cycle that would have been spent copying the latest code to the iPad to test over and over again. 

Of course, the iPad was the target release platform for the game, so we put someone on point for game play on the iPad even in the first few weeks.  Toward the end of the development cycle, we were propping builds to iPads 3-8 times each day for thorough testing.

GUI level editor:

Early in the cycle we decided a graphical level editor would save us a lot of time, and my teammate Gorden Lee built a great one using .Net.  Our designers used this tool to create and tweak levels at will, had a ready overview of how each level was put together and didn’t even have to deal with the Lua script.

Using Box2D physics for motion and collisions:

In its earliest iterations, Crimson: Steam Pirates used animation splines for animating the motion of the ships, planes and subs.  But this approach left the game with an unnatural feel for vehicle motion.  Near the end of the project we decided we needed more natural-looking motion, and had to scrap the initial approach.  My colleague, Chris Kohnert, came up with a much better solution by using the Box2D physics engine to move vehicles by impulse instead.  In the final game, all vehicles have polygonal shapes (as do the islands), the motion splines serve as inputs to set impulse and forces on the vehicles, and Box2D handles the collisions.  It was tricky to write the code to figure out the appropriate forces to apply to move the ships along the spline path dictated by the UI, but it works well.  To keep the “board game feel” intact, all the objects are reset to an inert state in the physics engine at the end of each turn and are moved again from scratch the next turn. In order to keep a sense of turn-to-turn momentum based on vehicle motion the previous turn, properties are stored for each object (outside Box 2D) that factor into the UI for setting motion paths and the magnitude of the forces that will be applied for motion in the next turn.

LUA and C++:

We programmed everything in Crimson: Steam Pirates in Lua, except for a bit of C and C++ code to integrate the Facebook and FMOD sound libraries.  Everything else about the way Crimson plays, runs, and looks is Lua code driving the Moai Platform.  We love working in Lua because it’s one of the fastest ways to program new features, and we can get more design cycles completed in the same amount of time. 

A custom Moai host for PC:

Although the reference iOS host was sufficient for the game, we made an enhanced shell for the Mac and Windows PC Moai hosts to let team members snap gameplay screenshots for easy inclusion in the bug tracking system.  This was a minor extension, but it was super useful for team communication around gameplay issues.

Extending the Moai particle system:

We started using particle effects to animate nice-looking aft wakes behind the ships in the game, but the built-in Moai particle effects supported only a single rotation, and we needed a base rotation and an offset rotation from that baseline.  So we changed the source code in the Moai particle system to make this extension.  In the final version of Crimson, all the ships and surfaced submarines have nicely particle-effect-animated aft wakes that render in relation to their motion.

Open source contributions

In addition to the updated particle system, we also extended Moai for easier debugging in the final weeks of game polish and testing.  The new debugging features included memory tracking and diagnostics for Lua and texture use, Lua object dumps and leak detection.  The epic win of open source is that we got to make the game just the way we wanted to and create the tools we needed to work efficiently on our own timeline.  Now, every other Moai game developer has a richer particle system and debugging feature set due to these contributions.  We’re looking forward to making use of extensions made by other developers on future titles.

Picking the right partners

Bungie Aerospace Logo

A final big reason we were able to develop Crimson as fast as we did and have it succeed to such an extent in the marketplace was our partnership with Bungie and their Aerospace publishing arm.  Bungie did sound design for the game, tons of testing, and they provided lots of mission and design feedback throughout the process. They were great to work with throughout development and launch, and we really appreciate their support.

Thanks for reading.  Feel free to post questions or comments here and I’ll answer them as best I can.

-AJ