Allen Ma, the associate at Ngmoco who managed Topple 2, says that his team tried to stick to an age-old game-developer rule of thumb, brought to the company by Ngmoco's other founder, Neil Young. Young, who was previously the general manager of Electronic Arts' Los Angeles office, brought with him the rule of thirds: "When you're doing a sequel," Ma says, "one third is new, one third is improved, and one third is the same." The goal, he says, is altering just the right amount of the game experience. "It's about adding enough to the game to make it different, but yet still keep the overall feel, so that the existing player-base will still appreciate the game," Ma says. But that requires parsing a game into discrete parts, and asking a lot of nebulous questions. What exactly makes the game "feel" the way it does? What's boring? What's outdated? What's the most fun?

Ma says that Ngmoco believed they knew what had made Topple 1 a success, and the team used it as a diving rod for the rest of Topple 2's features. "We wanted to keep it a short, immersive experience," he says. That immersive experience is part of what brought the Apple Design judges to their decision: all told, Topple 2 makes use of UIKit, OpenGL ES, Bonjour, CFNetwork, email, Twitter, and Facebook, to say nothing of the accelerometer and multi-touch. "We fully engage you with the device; it really does feel like you're stacking blocks," says Ma.

But that immersion is what requires so much respect for players' time, says Stevenson, who moved to California after growing up outside Edinburgh, Scotland, to make games. "You need to be making games as services. People need to be able to pop in and pop out of your game fast," he says. The less cognitive load for the player, the more likely your game will end up the go-to game out of dozens of others on the player's phone. "It means more quality and more intensity," Stevenson says. As of this writing, Ngmoco is in the midst of developing a first-person shooter game that allows players to battle opponents over a 3G connection. Stevenson says his team has designed the game to revolve around hyperactive three-minute sessions of play, because anything longer probably isn't realistic on an iPhone OS device. Ma has a more technical definition of the concept. "We talk about peoples' time in terms of 'free cycles.' So you're using your device for all these other things, but then every once and a while, you have this free cycle," he says. "So we want to create a game where someone enjoys it and can play it really quickly, so when they do have a free cycle, our game is on the top of their mind." The free-cycle approach has led Ngmoco to design its games with a three-minute window of playability in mind; if gamers can't get some kind of satisfaction in within three minutes, they might lose out to another game the next time a user gets a free cycle. "We want you to fill that time with Topple 2," Ma says.

In Topple 1, the "feeling" of stacking blocks was enough to gin up players' enthusiasm, but Topple 2 needed more. "With Topple 2, we sort of tried to create more of a universe around the game, because before, in Topple 1, there was just sort of an interface," Ma says. They did that by adding a narrative structure: who were these perverse-looking blocks, and what else could they do? "We wanted to make you feel like you were progressing through a world, this Topple World, where there are all these different zones, and all these Topple blocks behave in different ways," Ma says. Topple 1 was immersion in a physical experience: touching the blocks, watching them list from side to side. Topple 2 became more of a mental immersion, with several new modes of play. "We had a core game experience that was basically stacking blocks upward," Ma says, "and we were trying to add to that by creating games that you'd do in real life. You don't just stack things straight up in real life. You build things."

And when you build things, you make progress. While it's good to be a fast, convenient game-as-service, ultimately the real fun derives from beating whatever challenge is presented, and moving forward into new territory. Without the promise of progress, there's not the compulsion to go back into the game again and again. "We discussed how Topple 1 didn't feel like there was any progression, since the [level] interface was just a bunch of level buttons that unlocked," says Ma. At meetings, Ma brought up iconic games like World of Goo and Super Mario Brothers 3, which had guides to players' progress in the form of otherworldly maps. "We thought that style of map would convey a lot," he says. Stevenson worked with Ghostbot, a San Francisco art and graphics house with plenty of games and feature animated films to their credit. Ma says Stevenson "sketched out the idea in his head," deciding that he wanted a map that rose upward as new levels were unlocked. Ghostbot came up with the world pictured in Figure 3-2.

Figure 3.2. Stevenson worked with Ghostbot to produce the first sketches for the Topple 2 world.

The push for a Topple universe also led to new modes of play. In Rescue Mode, pictured in Figure 3-4, an egg drops from the top of the screen onto your stack of blocks, which you have to rearrange to slowly bring the egg down to the ground without breaking. Another mode, Balancer, presents you with a lever-like scale that only awards points when perfectly balanced. Questioning the orientation of gameplay also led to rethinking the physical behavior of the blocks: the blocks feel heavy in regular gameplay, but what if they were made of Styrofoam and meant to float? Experimentation led to the underwater level, an early mockup of which is seen in Figure 3-3. This level, Ma says, "fit very well with our anti-gravity idea, as it was easy to relay to the users that the blocks were lighter than water and wanted to float to the surface."

Figure 3.3. The sketch for the underwater level, right, and the final product.

New ways to play with blocks might seem like superficial add-ons at first, but they did something else: they brought Topple even deeper into the iPhone's philosophical fold. Nearly symmetrical from top to bottom and left to right, both iPod Touch and iPhone were meant to be devices with flexible and fungible orientations. Once the Topple team unlocked that same flexibility in the game, gameplay became vastly more creative.

Topple 1 was a great game; Topple 2 is a better one. Sounds simple, but it takes a lot of technical grafts to make it happen. "The design challenge for trying to refresh and enhance a game you've previously made is very different from coming up with a complete unique idea," says Stevenson, who has a background in art and design and began designing games for the Commodore 64. That's especially true if your codebase wasn't built to be modular and which was already pushing the limits of the iPhone's memory, as with Topple.

Figure 3.4. Topple's rescue mode requires you to use blocks to keep a golden egg from breaking.

At first, Topple 2 was going to be an incremental improvement: a few new levels, and new menus. "We were working off the codebase of a single player game," says Ryan Evans, vice president of Muteki Corporation, which Ngmoco hired to develop Topple 2, and one of two coders that worked on the project. "The original design specs called for some updates to a single player game, and then the multiplayer [idea] comes along," says Evans, who is based in Emeryville, CA. "And then challenge mode comes along. And then, well, you get the idea." Evans and the other Muteki engineer, Jason Young, threw hundreds of hours at the project. "It was a real bear to wrangle some of those features in to code that simply wasn't designed for it," he says.

One of those features: Challenge Mode, which allows players to throw down the gauntlet with a friend by sending them a challenge via Facebook or Twitter. Connectivity was one of the features that won Topple 2 its ADA, so it's worth taking a look at how the app interacts with the two services. Here's how Topple issues its challenges.

It uses one of the iPhone's most ingenious sharing conduits: the ability for an app to send information, even when offline, by generating an URL and sending it in Mail.

"It's a pretty useful hack, and is a great way to get challenge functionality working on social platforms like Twitter that don't really offer much in the way of attaching additional information to a post," says Evans. "I also think it's a great method for smaller shops who can't necessarily afford a full infrastructure."

The data-URL functions in several ways for Topple 2. Firstly, it allows players to send and receive challenges even when they weren't around a cellular or WiFi connection; if a player issues a challenge while, say, on a subway, it simply gets stored in the Mail outbox until it can be delivered. During development, it also kept Topple 2's engineers from having to dedicate a server to mediating challenges, or from having to build establish an interface with Apple's servers to deliver Push notifications. (Figure 3-5: Twitter challenges in a public stream.)

"Challenge data" in the URL, refers to a series of block-height samples taken during a player's "free play" mode, which denotes simple block stacking.

Per Apple's instructions, the formulae for Topple's URLs look like this:

topple2://<base 64 encoded challenge data>:<base 64 encoded challenge info block>

"Interpolating between these gave a nice smooth 'ghost' that felt snappy and alive," says Evans.

The "challenge info" block was a later addition, he says, and includes information about the challenger (their Twitter or Facebook name, for example) as well as the vector through which the player received the challenge. "That let us be a bit more intelligent with the 're-challenge' functionality, automatically defaulting the re-challenge to the posting method of the original challenge," Evans says.

Figure 3.5. Twitter challenges appear in a public timeline inside Topple 2.

Generating the data-URL could be done as illustrated in this sample project:

- (NSURL *)URLWithParameters:(NSDictionary *)parameters
{
  BOOL isFirstParam = YES;
  NSMutableString *urlString =
  [NSMutableString stringWithString:@"yourgamescheme://domain.com/"];

  for (id key in parameters)
  {
    NSString *value = [parameters objectForKey:key];
    [urlString appendFormat:@"%@%@=%@", (isFirstParam ? @"?" : @"&"), key, value];
    isFirstParam = NO;
  }
  return [NSURL URLWithString:
  [urlString stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding]];
}

// Build a dictionary with named parameters
NSDictionary *parameters = [NSDictionary dictionaryWithObjectsAndKeys:
@"Garry Kasparov", @"challenger",

[NSDate date], @"date",
[NSNumber numberWithInt:1], @"opponent-color", nil];

NSLog (@"url = %@", [self URLWithParameters:parameters]);

The log statement prints out:
url = yourgamescheme://domain.com/?challenger=Garry%20Kasparov&opponent-color=1&date=2009-10-02%2014:22:46%20+0200

Disseminating a challenge is one thing, but there's a lot more at work behind Topple 2's challenges. The app interfaces with Twitter and Facebook to allow players to hit up friends and followers for gameplay. Here's how it checks for challenges issues, and acts on them.

//
//  FacebookTwitterDemoAppDelegate.m
//  FacebookTwitterDemo
//
//  Created by Ryan Evans on 9/1/09.
//  Copyright Muteki Corporation 2009. All rights reserved.
//

#import "FacebookTwitterDemoAppDelegate.h"
#import "FacebookTwitterDemoViewController.h"

@implementation FacebookTwitterDemoAppDelegate

@synthesize window;
@synthesize viewController;

- (BOOL)application:(UIApplication *)application
didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {

    // Override point for customization after app launch
    [window addSubview:viewController.view];
    [window makeKeyAndVisible];
             NGChallengeStrings* strings = [[NGChallengeStrings alloc] init];
             strings.twitterSearch = @"http://search.twitter.com/search.json?q=%23FacebookTwitterDemo+tinyurl.com&rpp=10";
             strings.tinyURLFormat = @"http://tinyurl.com/api-create.php?url=%@";
             strings.eMailMsg = @"This is a message for a challenge, you should click here: %@";
             strings.eMailRechallengeMsg = @"This is a message for a re-challenge, you should click here: %@";
             strings.eMailRechallengeSubj = @"FacebookTwitterDemo Rechallenge!";
             strings.eMailSubj = @"FacebookTwitterDemo Challenge!";
             strings.facebookPost = @"Can you beat my FacebookTwitterDemo challenge? Click here: %@";
             strings.facebookRechallenge = @"I smoked your FacebookTwitterDemo challenge, can you beat mine? %@";
             strings.gameURLFormat = @"facebooktwitterdemo://a/?q=%s";
             strings.urlHeader = @"facebooktwitterdemo://a/?q=";

             [NGChallengeSystem getInstance].localizedStrings = strings;
             [NGChallengeSystem getInstance].window = window;
             [NGChallengeSystem getInstance].delegate = self;
               [strings release];

// If this statement is omitted, memory will leak.

             if([launchOptions objectForKey:UIApplicationLaunchOptionsURLKey] != nil) {
                          NSURL* toHandle = [launchOptions objectForKey:UIApplicationLaunchOptionsURLKey];
                          NSLog(@"Opened with URL, need to parse it!");
                          [[NGChallengeSystem getInstance] parseChallengeURL:[toHandle absoluteString]];
                          return YES;
             }

             return NO;
}

- (void)dealloc {
    [viewController release];
    [window release];
    [super dealloc];
}


- (void)receivedTwitterChallengeFromUser:(NSString*)user withData:(NSData*)data {
        // In this method you would do something with the challenge data to load up your challenge and play it.
             // For now we just create a string and print it out to validate the data was accurate
             NSString* string = [[NSString alloc] initWithData:data encoding:NSUTF8StringEncoding];
             NSLog(@"Got a twitter challenge with string contents %@ from player: %@", string, user);
               [string release];
}
             // If this statement is omitted, memory will leak.

- (void)receivedFacebookChallengeFromUser:(NSString*)user withData:(NSData*)data andFBUID:(FBUID)challengerUID {
             // In this method you would do something with the challenge data to load up your challenge and play it.
             // For now we just create a string and print it out to validate the data was accurate
             NSString* string = [[NSString alloc] initWithData:data encoding:NSUTF8StringEncoding];
             NSLog(@"Got a twitter challenge with string contents %@ from uid %lld | player: %@", string, challengerUID, user);
               [string release];
}
             // If this statement is omitted, memory will leak.

@end

The data-URL hack also had another benefit for Topple 2 players: it allowed challenge mode to be just as effectual on an iPod Touch as on the iPhone. "It hadn't occurred to us how influential the iPod Touch was going to be," says Stevenson. "It effectively doubled the market." When Topple 1 entered the App Store in October of 2008, the iPhone was its natural milieu—but when Topple 2 entered the App Store five months later there were tens of millions of iPhone OS devices sold and almost half of them iPods. That created some complications: for Topple 2, they'd have to add features and functionality, and yet appeal to a lower common denominator. "You have to design for the iPod Touch upwards," Stevenson says.

But 70 million users presents another design quandary: deciding on a target audience. "Who is the market? The market is everyone," Stevenson says. "The next question becomes: who do you focus on? It can be tricky, depending on the game," he adds. "Our stance is that our marketing is aimed at ages 12 to 19," he says, "and to adults that feel like they're 12 to 19."

Though Stevenson says he didn't think much about his market in 2008, Topple's trademark block-faces were drawn with both kids and adults in mind. "I thought, let's try and make this look a little bit nicer than people would expect on a phone," he says. "Rather than just blocks, is there a way to give them personality?" For art, Stevenson approached Ghostbot. "They weren't sure what kind of company we were, so at first they drew really friendly unthreatening faces that were almost like kids' cartoons," he says. "So I drew one sort of face with a malevolent smile which ended up being the face of the game. It's not meant to be dark, but I said, 'What if this family of blocks was dysfunctional? I thought, there's going to be a lot of adults playing this. Kids will just find it cool that there are faces, but for adults you want something else. You don't want it to feel like Dante's Inferno, but the notion that they look like they have a tiny bit of personality I don't think ended up hurting the look of the game." In short, he says, the key is personality with unspecific appeal. "It's about great design, plus a mass market idea. That's the kind of design that we're trying to create."

The market may yet grow. With persistent rumors swirling of an Apple tablet running a modified iPhone OS, Apple's handheld following may expand even further to include enterprise, small business, and digital arts customers. Finding a way to pull them in for a short, immersive experience—and having a code-base ready for modification—may make mass-market even more important among an ever-growing field of competitors.

"The size of the market is great, but the amount of product in the market can make it really difficult to have a healthy ecosystem where people can find each other's products, Stevenson says. "We guessed that would be the case, that's why we set ourselves up as a game publisher rather than a developer." Though Ngmoco employs a staff of around 15, it farms actual development out to contractors around the world. Stevenson says he anticipated that with Apple offering 70 cents on the dollar for apps, the best developers might not concede to working in-house when they could go get rich on their own. The way Apple has it set up, everyone should do it, and everyone did do it," Stevenson says. Instead of hiring on a big staff, Ngmoco relies on talented, self-sufficient coders. "These guys can really do it all themselves—maybe they need some art, but they're really into design and really into programming. They tend to do it as a lifestyle, they're not in it for the money, so they're strongly opinionated, but really good design shops," he says.

Sourcing engineering also keeps stress levels low for everyone involved. Stevenson calls in-house development a "a quite draining type of activity." "You tend to become one big dysfunctional family," he says. "The entire organization becomes defined by the endeavor they're working on. We thought, we'll come up with ideas, but we'll also listen to really good ideas, or buy projects, or contract teams so that they're autonomous."

Another facet of the lean-company strategy is super-fast development. He chose independent game developer Chris DeLeon for Topple 1, who he says was perfect for the project, and set a project timeline of eight weeks. "At the end of game Chris said, 'I'll never do an eight-week project again, it's just too long,'" says Stevenson. "That's funny coming from my traditional experience—the longest game I ever worked on was three years. And this young guy in his mid-twenties was like, 'I can't believe you took me on this death march of eight weeks.'" By moving fast and using independent, self-sufficient talent, Ngmoco may have avoided much of the infighting and friction that is anathema to building something fun. "It was a simple, powerful idea: let's make this quick, let's make it successful, and let's make it fun," says Stevenson.

"We had a lot of memory issues with Topple 2 throughout the course of development," says Evans. Some, he says, were inherited from Topple 1, but others got bigger as the list of changes grew. One problem: not having a comprehensive caching system in place for textures.

A good example of this, according to Evans: "The original code was using [UIImage imageNamed:] to load the UIImage* objects for a texture. It's a nice call, because it's very simple to use, but the flipside is that imageNamed creates its own cache of images in memory." That was causing the phone to keep lots of extra copies of image data wasting memory while that method was still being used. "When we switched to one of the alternate image loading methods, our memory usage dropped dramatically," he says.

Another texture issue that the team didn't get to resolve: the use of PNG files. "Everything I've seen says that PVRTC will give you loads more memory to work with, since you can pass the images compressed directly to OpenGL ES," Evans says, "but we were never able to get the Topple 2 assets sufficiently good looking in PVRTC to make the jump over." He says that future games, whether Topple offspring or otherwise, will make use of the PVRTC format.

Stevenson's mantra of respect for the user extends to memory management as well. "The iPhone seems to be pretty good at writing small blocks of data quickly, so we tried to keep the overall size of the save data low," Evans says. "Partially this is out of respect to the user and not taking up a gigantic amount of space on their device, and partially because the less data there is, the faster saving and loading can go."

While Topple 2 didn't make use of PVRTC, more memory-hungry apps might necessitate it—especially on 2G and 3G iPhones without benefit of the 256MB of RAM in the 3GS. So what is it? PVRTC (or PowerVR Texture Compression) is a format you can use to compress textures and save memory during expensive operations. OpenGL ES 2.0 supports the format by implementing an extension called GL_IMG_texture_compression_pvrtc. There are two levels of PVRTC compression: 4 and 2 bits per channel, which respectively offer a 8:1 and 16:1 compression ratio over the uncompressed (32-bit) texture. Image quality is a legitimate concern, especially in apps like Topple 2, which pride themselves on art. But for most applications, the 3–bit compression level still allows for decent-looking results, and apps that make heavy use of PVRTC compression (like AccuTerra, also profiled in this book) are living proof. Apple claims that using this format frequently saves more memory than reducing image size.

The iPhone SDK includes a tool called Texturetool that allows you to convert PNGs into this special compression format. Texturetool gives you flexibility to find a balance between image quality and size. The tool is located at the directory /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/texturetool (provided the iPhone SDK is installed in the default location.)

As always, a downside of using special file formats is the potential for obsolescence. Because future iPhones and iPods might not use the Imagination Technologies's PowerVR MBX SDK for OpenGL ES processing, take care to preserve all textures somewhere in the app as uncompressed PNGs, so that future devices can still load the images even without PVRTC support. To ensure that the app doesn't end up floundering on some future iPhone because of this issue, be sure to include the following simple boolean expression in its code to check for the proper OpenGL extensions for PVRTC.

BOOL CheckForExtension(NSString *searchName)
{
// For best results, extensionsNames should be stored in your renderer so that it does not
// need to be recreated on each invocation.
    NSString *extensionsString = [NSString stringWithCString:glGetString(GL_EXTENSIONS) encoding: NSASCIIStringEncoding];
    NSArray *extensionsNames = [extensionsString componentsSeparatedByString:@" "];
    return [extensionsNames containsObject: searchName];
}

If an app is unable to use compressed images, there are other best practices for speeding through OpenGL ES. Some options: use lower-precision color formats like RGB565, RGBA5551, or RGBA4444. Also ensure that the app is using appropriately small dimensions in its images, is loading them at initialization and not during runtime, and that it avoids changing OpenGL ES state as much as possible.

To achieve the latter, try combining smaller textures into a single "texture atlas," which the system can pick from to find certain textures within the atlas. As Apple's documentation states: "A texture atlas allows multiple models to be drawn without changing the bound texture and may also allow multiple glDrawElements calls to be collapsed into a single call."

Using mimaps for all appropriate textures can also cut down on the number of texels being fetched from texture memory, which saves on memory bandwidth. The GL_LINEAR_MIPMAP_LINEAR filter mode provide the best quality when texturing, but is less miserly than the GL_LINEAR_MIPMAP_NEAREST filter mode instead, which will spare even more bandwidth but may cause quality to suffer.

In keeping with minimizing state-changes, it might also be a good idea to instruct an app to perform multiple steps of an algorithm on each pass of the app's geometry. Called "multitexturing," the practice involves calling both of OpenGL ES's available texture units with the call glGetIntegerv with GL_MAX_TEXTURE_UNITS as the parameter.

Though Stevenson and his team have decades of gaming experience between them—as artists, developers, and enthusiasts—most of it was on at-home consoles like the PC or Xbox. "The mobile game business before the iPhone was something that would never have interested us at all," he says. At the time the Apple device was announced, Stevenson was CEO and co-founder at Project Moon Studios in San Francisco, where he oversaw successful titles like Smartypants for the Nintendo Wii and Citizen Kabuto for the PC. "Having worked on practically ever single console ever created I was intrigued to see how powerful the phone would be," he says. "No one had any idea until someone build the first game, and then we realized: oh, we can really make games on this."

At the time, his future co-founder, Neil Young, was managing the LA branch of mega-gamemaker EA. Young approached Stevenson and suggested they think about what kind of company could be built around the iPhone. "By the time we finished our business plan, I flew back to spend time with my dad, who is an old-school businessman and doesn't really suffer any bad ideas," Stevenson says. "And we kicked ideas around for what we thought this business would be, and we came to the conclusion that we thought this would be a revolution."

Why? "Because it was the answer to a lot of things that we saw on the horizon and beforehand," he says. "We were really interested in the notion that the computer was moving towards people instead of people moving towards the computer. And we thought that would fundamentally change the way they spend their time, and therefore how they played games. So before the game aspect of the phone was unlocked, we knew the phone had an accelerometer, so you could move the device and control it, and we knew it was connected—it has all your friends, all your mail, it's a personal device. And it's a phone. It's got a microphone and a camera built in," says Stevenson, who has also developed for Sony's PSP. "You also have what is essentially four finger touch—all those things combined make you realize that it's an interesting palette to work with."

Before departing Project Moon to start Ngmoco, which is backed by the joint-venture Apple/Kleiner Perkins iFund, Stevenson was fresh of the success of Smartypants, a quiz game for the Wii. Its broad age appeal and single-purpose concept would pave the way for his iPhone thinking. "The distinctive thing about Smartypants was that it was a very simple idea for a very specific audience—we were trying to build a game to play with our kids, and that didn't exist," he says. His company partnered with Young's Electronic Arts—their first close collaboration after an 18-year friendship. "We built the game in six months for less than a million bucks and it made a lot of money," he says. The game presented players with Trivial Pursuit-style question rounds, with each question tailored to the age of the player. That meant that adult could play with a 16-year-old and an 8-year-old and not be bored. Fast build time was an obvious lesson: after releasing Armed and Dangerous for the Xbox a few years earlier and seeing a tepid consumer response, Stevenson thought, "I'd really like to make faster and cheaper games, so we've got less risk—so we're not spending two years on something that's costing 5 to 10 million dollars, and then finding out in one weekend whether it's going to be successful." But the more significant lesson was in the way that Stevenson thought about his market. Instead of envisioning a target consumer, he and his team had envisioned a playing scenario: parents and kids, together in front of a Wii. The concept of the three-minute "free cycle" that inspired Topple's gameplay harkens back to just that kind of thinking: with iPhone OS gaming, the setting and the players are no longer a foregone conclusion.

Ma, Topple 2's associate and overseer, is perhaps the Topple 2 team's most dedicated gameplayer—though he had never worked on a game before being hired away from a job as a web developer at Yahoo. He says he favors first-person shooters and real-time strategy games, and spends most of his time on Steam.

"These days, I wish I was back in the old days of high school or college, where you had lots of time to play games—you could really get into a deep, immersive experience," he says. "I still feel strongly about the deep experience, but now I'm focused on the immersive experience that comes really quickly, and ends kind of quickly, too. I like that I get that accomplishment of finishing the game without having to take forty to eighty hours on the game." He says that making games relatively easy to beat also encourages players to come back and start all over. "Short games like Call of Duty: Modern Warfare are set up to play out like a movie; it's something like four or five hours long, but it was extremely rewarding, and every level was done really well," he says, citing one example. "And I actually played that game three times through—not in a row, but I've gone back so much because it's such a short experience and it was so enjoyable to do it again, much in the same way you would like pick up a DVD and watch it again."

While other iPhone developers—in this book and elsewhere—have reported confusing experiences with Apple's app approval process, Stevenson says that dealing with Apple was actually pleasant in comparison with some other console-makers, who primarily cater to large game publishers. "If you're an independent developer like we were, you really have to work hard at your relationships with these [game] companies, because the process can get bureaucratic really easily," says Stevenson. "In particular with Sony. We switched the company over to the PSP, and we were passionate about making something interesting for it. But we found that the help given by Sony at the time was just nonexistent." Compared to Sony, Apple has done "a really great job," says Stevenson. "When we went through the [Sony] approval process, they were so unwelcoming—and I knew some really senior people. I used to have to kind of call in a favor now and then and say 'can you write a message to these [approval] guys and tell them we're not trying to do something bad here?' That we're actually trying to make something good for their platform, and that they should lighten up?" Stevenson recalls. "It was almost like going through customs."

Sony's indifference, Stevenson says, isn't any inherent fault in the company; it's just the laziness that came with the success of the PS2. "Whoever's at number one doesn't usually try hard with the developers," he says. As Apple's dominance of the smartphone app market grows, developers may come to an inflection point at which Android, BlackBerry, or webOS development become more personable and gratifying. That, Stevenson says, was exactly the scenario that he found himself in as an Xbox developer. "Sony existed in contrast with Microsoft, which for a company with their reputation was unbelievably helpful," he says. "They were supportive; they'd send people down to help you with your code, they had an entire team of people that would spend time at the end of a project optimizing your project, so that your game would look better—and they did it for free," Stevenson says. Though Apple has treated Ngmoco well, smaller, less serious shops might find the iPhone to be more hostile terrain. "We were funded quite quickly, so we hired phenomenal staff and engineers, and so we really had a good relationship with Apple because we were treating their device and their market seriously," Stevenson says. "I'd say we've had a slightly different experience than the one or two developers in the bedroom." As of this writing, Ngmoco has no plans to expand to other platforms.

But being bigger than a one-man show takes planning, especially for game publishers, who need to orchestrate art and engineering. "Making sure that you're conveying the technical specifications for the art is really, really helpful to the artist," says Ma. "We had art come in [for Topple 2] and when we put it in the game we needed to stretch it out—it was too small. Unfortunately, the artist was in a time crunch, so he didn't think to start with something bigger and shrink it down," he says. "So then he had to go and start over, and basically recreate it again." Even more crucial to gameplay, Ma says, is music choice. "Working at Ngmoco really made me start appreciating audio, effects and music on levels that I never had in games before," he says. "When you first work on a game there's no music or sound effects yet," he says, "and then suddenly you add them, and it's like a completely different game." For Topple 1, the team added what Ma calls a "Danny Elfman kind of experience": a kind of grand, orchestral techno type of sound. "But you know, for Topple 2 we ended up on this like Law & Order kind of feel. And, yeah, it totally changed the way you felt about the. The music was huge."

One of the features that sets Topple 2, and other Ngmoco games, apart from their competitors is the way it uses analytics. Those "awesomes" the company monitored in Mazefinger weren't just fanciful indicators of the game's popularity – they were real tools that Stevenson and his team used to make sure the game was at its optimal playability. "From day one we were building a network," Stevenson says. "It was important that we had real-time analytics in all our games, so that we could make them better." In Stevenson's mind, 'real-time' didn't just apply to the downstream data; he wanted real-time game improvement, too. "With Topple and Mazefinger, we could see how far people were getting in the game, and change the skill level on some of the later levels to make sure that people could get through the game."

Though Topple 1 and Mazefinger were treated the same, they were conceived for different purposes. "We released one for free and one paid, because we wanted to understand how the economics worked," says Stevenson. "We thought they were both really good games, and we wanted to see what happens when one goes in free." Both of them shot into the top five games within a day, but because Mazefinger was free, it had ten times as much traffic. "It broke our network," says Stevenson.

It taught Stevenson a valuable lesson. Originally, he had assumed Ngmoco could charge $9.99 for its games, but the success of Mazefinger suggested that the road to profit on the iPhone isn't sales—it's marketshare. "Free games get so much more attention," he says, and in the world of iPhone gaming, attention is the name of the game. Since gaming is the only major genre that Apple itself has stayed out of, no one developer has any technical advantage; it's the freest of the App Store's competitive markets. The result has been explosive growth, fueled in part by Apple's game-centric iPod Touch advertisements. To rise above the rabble, Ngmoco has a plan: "In the future, we are going to be releasing DS-quality games for free," says Stevenson. "This is going to cause a minor freak-out in the industry.

Ngmoco's games will still be sold for money, but they'll also have completely free versions designated "Plus+" that users can download for free. Plus+ (pronounced "plus-plus") is a network that Ngmoco hopes will keep players tied into its games, and more amenable to playing new ones. It requires signing up for a free Plus+ account, which pulls you into a network of other Plus+ gamers that you can compete with. There, you create an avatar, compete on the leaderboards, challenge other players, and broadcast your high scores on Twitter and Facebook. (The Plus+ leaderboard, Figure 3-6.)

Figure 3.6. The Plus+ leaderboard tracks a player's progress in all Plus+ games combined.

The Plus+ network isn't just limited to Ngmoco; the company has also developed an SDK for other game-makers that want to join up. At first, the company will accept Plus+ partners on a case-by-case basis, but later the SDK will become open and available to any game developer that wants to join. Not only will small-time developers get access to Ngmoco's network of points, challenges and playability, they'll also be able to use the company's metrics and promotions engines.

But building the Plus+ network come at a substantial risk. Already, millions of people have paid money for games that have since been made free—a textbook way to make otherwise enthusiastic customers bitter. Asking players to sign up and divulge information is another hurdle. Still, by building a network, Ngmoco will reduce the App Store's already-low friction between downloading, playing, and making in-app purchases—one of the company's planned conduits for revenue. Stevenson says he envisions more future games that are downloadable and playable for free, but that give players the option of buying additional features in-game to change the experience, much like the buying experience inside other social games.

Despite all the potential for market share and upside, the Ngmoco team is still possessed of a humble impulsion. "I feel like from a really young age when I started playing games, I realized I wanted to change the rules," says Ma. "I found a lot of enjoyment not only from playing games but from also creating a different kind of game for other people, and just having other people be happy felt great. That's why I think I always wanted to be a game maker."