I've written a lot of games, but Rebuild was the first I actually finished. It's since spawned a sequel and ports to mobile devices, all written with Adobe Flash and AIR.
Inspired by my husband Colin's success with Fantastic Contraption (also his first published game), I finally quit my game programming job at Three Rings Design. We sold everything but our laptops and started on a journey of world travel and indie game development (see Figure 1).
Our first stop was Istanbul, Turkey. I was looking for a simple first project that I could design, program, and "art" on my own in a few months. I went through my folder of game ideas and dusted off "post-apocalyptic Sim City", an idea for a real-time multiplayer Facebook game where you team up with your friends to liberate a city from the undead. After yanking out the real-time, the multiplayer, and the Facebook (I wanted to get this done in three months, after all), I slammed out a rough prototype with a map, fort, survivors, and the ever-advancing zombie horde.
Flash was a good fit because it'd make it easy to get my first game in front of a lot of players and get feedback on it. I usually start by laying out my interface in Flash Pro, then create a mirrored set of AS3 classes that connect up and control the GUI elements. After two days, my proof of concept was playable (if ugly; see Figure 2) and, dare I say it: fun.
1. Manage feature creep: planning for the sequel
Two months later we were in Malta. The plan was to live cheap and work part-time, so I'd do three months of work during the first six months. The list of ideas I wanted to put in the game kept growing and growing, but the art was so time-consuming that I knew I couldn't do everything. I split my list into three parts: "to do", "maybe to do", and "for the sequel". As I slowly shuffled features down the list, things like equipment and narrative plotlines didn't make the cut.
This allowed me to let go of some things and focus on getting the core game finished. I realized one of the problems I'd had with finishing earlier games was that they became bloated with unnecessary features. Planning the sequel from the start helped me manage this and also turned out to be pretty lucrative (see Figure 3). Players love sequels. So do Flash sponsors.
2. Happiness: the missing resource
We were in Honduras, five months into our travels, when Colin came up with a theory that the best games were made up of simple systems that "multiplied" well with each other, creating complexity with their interactions. Rebuild had the systems of survivors, food, and defense. You need more survivors to defend against the zombies, and more food to feed the survivors, and you're constantly having to choose between those three resources.
But the game didn't feel deep enough. Adding more random events (like needing hospitals, or researching pesticides) increased the number of things you had to think about, but didn't really interact with those other systems. I considered my husband's theory and came up with the happiness meter. Your fort's happiness goes down when you starve (food) or if zombies kill someone (defense), and affects the effectiveness of missions (survivors). It has a gradual downward curve and becomes a problem right around the time you think you've finally stabilized your fort, bringing interest to the late game. It felt like the last puzzle piece falling into place.
3. FlashGameLicense.com: getting paid for making a free game
I wasn't sure how Flash sponsors were going to react to Rebuild, seeing as it was wordier and more thoughtful than most Flash games and takes far longer to play (average time: 45 minutes, according to Playtomic). I didn't know who to contact or how sponsorship worked, so FlashGameLicense.com helped immeasurably to get my game in front of the right people.
Within the first day of bidding, I succeeded in my humble goal of earning minimum wage. Whenever bidding stalled, I emailed the runners-up and gave them some piece of press or new feature (for instance, that I would implement the Kongregate API, or Rebuild was being reviewed by JayIsGames), then I'd tell them the exact amount they needed to bid. I built relationships with the sponsors, and though it was hard work and tempting to end the bidding early, I kept it going for the full month.
In the end I accepted an exclusive contract, which meant I couldn't sell custom versions to other portals, but I could post the game to major sites like Kongregate.com under my own account. In my experience this is the best way to go. Rebuild shot to the top of the Kongregate.com charts, winning contests and earning an extra $5k in ad revenue.
We moved on to Costa Rica and I wrote another game, but with Rebuild getting millions of plays around the net, I knew I should capitalize on that with a sequel.
4. EvilKris: working with an artist remotely
Working on Rebuild 1, I discovered a game art secret: it takes for-frigging-ever to produce. Even my sad little stick men took days to make, so if I wanted to up the realism and quality of the sequel, I needed help. I found EvilKris on the FlashGameLicense forums, and loved the gruesome and gritty art from his Insanity games. We spent most of our time on opposite sides of the world (me in San Francisco, him in Japan), but it was easy to cut the work up and we never had a bottleneck where one of us had to wait for the other.
I defined the assets with rough descriptions, then Kris shared rough sketches through Box.net, where we discussed them (see Figure 4). Next, he sent the finished pieces in raw format that I tweaked and put in place. It helped that I was able to do some chump touchup work myself rather than going back and forth repeatedly with Kris.
Some requirements changed during development, and assets needed to be modified and repurposed. For example, the zombie on the main menu was originally in one of the ending animations, and there were only 11 big panels for the attack animations before I sliced them into 19 smaller ones.
5. Porting: yes, you can make money on iOS
Once Rebuild 2 was in sponsor bidding, we headed for the Philippines, and I started porting the game to the iPad (see Figure 5) using Adobe's AIR for mobile devices. I'm glad I did, because the game's iOS revenue just recently surpassed the Flash sponsorship and advertising earnings.
It's hard to get noticed on the iOS market unless you're one of the top 10 apps repeatedly shoved in player's faces. Rebuild was never featured by Apple, so its momentum in the app store came from outside links and reviews by people who'd already enjoyed the Flash version. Plugging it from inside the original Flash game was important. It turns out players will pay for a free web-based game if you port it to other platforms.
I also ported the game to Android and the BlackBerry PlayBook. If you use AIR mobile, you might as well do all of them, because it's so little effort to package your app for another device. The PlayBook port took me two days and shot right to the top ten, getting featured in its second week.
1. Difficulty scaling: this is a game you can lose
I mentioned that Rebuild was originally going to be a Facebook game, and for a long time the design included one very casual-play element: the game would scale depending on how the player was doing. It affected a lot of subtle variables but basically, if the zombies were kicking your butt, there would be less in the next wave. You could still lose, but it was a more gradual and sometimes painful process.
My husband (and often only tester) Colin and I argued about this until I agreed he was right, that Rebuild was a game of skill, and a game you could lose. Subsequently "easy" difficulty became a cakewalk, and neither of us has ever beaten the game on "nightmare".
2. Playtest results: ignore them
Before putting Rebuild 1 up for bidding, I sent it out to everyone I knew. I also ordered up some First Impressions from FlashGameLicense.com, which are anonymous testers who will play and review your game for a buck apiece. It's useful if you're in a little fishing village in Costa Rica where most people don't speak English or own computers.
The results, however, were devastating. Most friends and family didn't play it, didn't get it, or had nothing to say about it. The First Impressions were terrible, with feedback like "Fun: 1/10—waste of time," and "Parting Thoughts: People don't want to read so much."
For just a moment I was tempted to pull all the text out and add a minigame where you point-and-click to shoot the zombies. But I knew my audience: me, and knew I'd love the game exactly the way it was. I did spend a little longer on the tutorial in the hopes that some of people just needed it explained better, but didn't change a thing about the game play based on testing.
I try to make it clear that Rebuild is a turn-based strategy game. If players don't know what that is or think it sounds boring, I'd rather they didn't buy and downvote it.
3. Fan feedback: listen to them
I did testing differently for Rebuild 2. I recruited fans of the first game and invited them to a private beta version. I collected playthrough stats (average food per day, average fort size, average days played, and so on) and sent out a short survey to which I got some very thorough answers. What I discovered was: I'd made some great improvements to the UI and made the game prettier and more accessible, but that wasn't what they wanted.
Most fans wanted more content. Vast levels with countless new building types, hundreds of random events, and cities you could play for hours at a time. Other fans complained that it wasn't different enough. Rebuild 2 was the game I'd wanted to make in the first place, with all the features I had to leave out of Rebuild 1. It took longer to write but wasn't significantly all that different (see Figure 6).
I wish I'd suppressed my instinct to improve things that bugged me about the first game. I spent days endlessly tweaking the zombie attack algorithms and fiddling with the scollbars and preloader, instead of focusing more on making the game different for fans of the original.
4. Optimization: it's never too late
Though I intended to release Rebuild 2 (rebranded as simply "Rebuild") on mobile devices, I didn't consider optimization while I was writing the Flash version. When it came time to put the first AIR build on an iPad, I was greeted with horrific initial performance.
Scrolling the map around was incredibly slow, there were long pauses when opening menus, and it would occasionally max out the system's RAM and crash (technically, I think it was force-closed by the OS). The easiest way to improve map-dragging performance was to convert more vectors to bitmaps, but that increased the amount of memory it used, and thus the likelihood of crashing.
Of course, I was doing some ridiculous things in the Flash version, like creating a list of living survivors hundreds of times in a single frame, or embedding the same fort-wall graphics in the art for every type of building. It never mattered on even the slowest PC, but just watch that memory climb up on an iPad 1 with its feeble 256MB of ram.
With help from the Flash Builder profiler and many useful tutorials, I eventually got the game running smoothly on newer mobile devices. It took about 300 hours, nearly half the time it took to write Rebuild 2 in the first place. Most of those hours were spent learning new tricks and concepts that I'll be applying to games from the start from now on.
5. Releasing: its not over when its done
My biggest regret for Rebuild 2 is that I didn't take the mobile release seriously enough. I hadn't expected it to do very well at all, and I was so focused on the Flash sponsorship that I didn't consider trying to time the iOS release to coincide with Hallowe'en. If I'd pushed to get it finished a month earlier, it might have gotten featured in Apple's October lineup.
Also, Rebuild was initially released only for the iPad 2 because I didn't think it was worth the trouble to improve performance for iPad 1 or iPhones. Turns out I was wrong. I didn't even advertise it to iOS review sites until a friend convinced me to—good thing he did! I wasn't planning to put it on Android or other devices, but I'm starting to see a pattern here. Who knows if my next game will be a hit, so it's worth making a little effort to get Rebuild out there and in front of players.
Although all this sequeling and porting and optimizing has made me pretty sick of Rebuild and zombies in general, it's hard to deny that another Rebuild game would make financial sense. Part of me would love to see a fully-featured PC-downloadable version (AIR, of course).
But first, I'm working on my husband Colin's game Incredipede, in which you build and control a strange creature on a journey of self-discovery. Then I'll finish the mobile version of my game Word Up Dog (see Figure 7) which combines adorable animals and hip-hop lingo. No zombies whatsoever!
- Developer: Sarah Northway
- In-Browser Flash
- Blackberry PlayBook
- Release dates:
- Rebuild 1: January 2011
- Rebuild 2: October 2011
- iOS: November 2011
- PlayBook: March 2012
- Android: April 2012
- Length of development:
- Rebuild 1: 3 months (over 6 months elapsed time)
- Rebuild 2: 4 months (over 7 months elapsed time)
- iOS port: 1 month
- PlayBook port: 2 days
- Android port: 2 weeks
- Team size at the beginning of the project: 1 person (Sarah)
- Number of people hired: 1 part-time artist for Rebuild 2
- Total team size at the end of the project: 1 person (Sarah)
- Links to the game: